Skip to content

feat: Update model list in settings #379

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
google-labs-jules wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat: Update model list in settings #379

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 21 additions & 21 deletions components/settings/components/model-selection-form.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,43 +12,43 @@ import {
import { RadioGroup, RadioGroupItem } from "@/components/ui/radio-group";
import { Card, CardContent } from "@/components/ui/card";
import { Badge } from "@/components/ui/badge";
import { Sparkles, Zap, Rocket, Cpu, Earth } from "lucide-react";
import { Zap, Rocket, Cpu, Sparkles } from "lucide-react";
Copy link

@charliecreates charliecreates bot Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Earth icon import was removed entirely, which is appropriate given that QCX-Terra was deleted, but it also means there is no longer any in-house or geospatial model in the list. If QCX-Terra is part of your product identity or needed for certain use cases, its removal (with no replacement) might be a product/UX regression rather than a purely technical one.

Double-check with product requirements that dropping QCX-Terra from the selectable models is intentional and that any dependent flows (e.g., geospatial-specific features) are either deprecated or mapped to another model.

Suggestion

If QCX-Terra or a similar in-house/geospatial model should remain available, consider keeping it in the list with an updated description and potentially a different badge to de-emphasize it if necessary. For instance:

{
  id: "QCX-Terra",
  name: "QCX-Terra",
  description: "QCX's geospatial foundational model for map and location-heavy tasks.",
  icon: Earth,
  badge: "Geospatial",
  badgeVariant: "secondary" as const,
},

You can also group or visually separate internal vs external models in the UI if that aligns with product goals. Reply with "@CharlieHelps yes please" if you'd like me to add a commit that restores or repositions QCX-Terra (or a renamed successor) in the model list.


interface ModelSelectionFormProps {
form: UseFormReturn<any>;
}

const models = [
{
id: "QCX-Terra",
name: "QCX-Terra",
description: "Geospatial foundational model",
icon: Earth,
badge: "Recommended",
badgeVariant: "default" as const,
},
{
id: "Grok-3",
name: "Grok-3",
description: "Fast and efficient model for most everyday tasks and queries.",
id: "grok-4.1",
name: "Grok 4.1",
Comment on lines +23 to +24
Copy link

@charliecreates charliecreates bot Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The id for the Grok model has been changed from a capitalized Grok-3 style to lowercased with a version ("grok-4.1"). If this id is persisted (e.g., user settings, URLs, backend contracts, or feature flags), this change can silently break existing users' saved preferences or any code that still expects the old identifiers.

It would be safer to either:

  • Confirm that selectedModel never leaves the UI layer and has no backward-compatibility constraints, or
  • Introduce a migration/compat compatibility mapping from old IDs to new ones to avoid breaking existing stored values.
Suggestion

If these model IDs are stored or used across layers, consider adding a mapping layer to translate old IDs to new ones and keep the UI flexible:

// Example mapping for backward compatibility
const MODEL_ID_MAPPINGS: Record<string, string> = {
  "Grok-3": "grok-4.1",
  "claude-4-sonnet": "gpt-5.1",
  "llama-4": "deepseek-4.5",
  // "QCX-Terra" could map to a default or be handled explicitly
};

function normalizeModelId(id: string): string {
  return MODEL_ID_MAPPINGS[id] ?? id;
}

// Wherever `selectedModel` is initialized/loaded:
const normalized = normalizeModelId(savedSelectedModelId);
form.setValue("selectedModel", normalized);

This keeps the new IDs in the UI while not breaking existing users. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion and wire it into the appropriate initialization path.

description: "The latest powerhouse model from xAI.",
icon: Zap,
badge: "Fast",
badge: "New",
badgeVariant: "secondary" as const,
},
{
id: "claude-4-sonnet",
name: "Claude-4-sonnet",
description: "Advanced model with strong reasoning and detailed planetary knowledge.",
id: "gpt-5.1",
name: "GPT 5.1",
description: "The latest iteration of OpenAI's flagship model.",
icon: Sparkles,
badge: "New",
badgeVariant: "default" as const,
},
{
id: "opus-4.5",
name: "Opus 4.5",
description: "The latest high-performance model from Anthropic.",
icon: Rocket,
badge: "Advanced",
badge: "New",
badgeVariant: "outline" as const,
},
{
id: "llama-4",
name: "Llama-4",
description: "Open-source model with good performance for general planetary information.",
id: "deepseek-4.5",
name: "Deepseek 4.5",
description: "The latest from Deepseek, a powerful open-source model.",
icon: Cpu,
badge: "Open Source",
badge: "New",
badgeVariant: "outline" as const,
},
];
Expand Down