add provider name before indicate model

[Phosphate5429]

like here. ok it's GLM 4.6, but from what provider? kilocode? openrouter? chutes? someone else? it's change for pricing etc.

need be indicate : Chutes.ai > Z.ai > KLM 4.6 Turbo something like that.

[Phosphate5429]

Summary

Currently, only the model name is shown across the app (selector, status bar, chat header, etc.).
It would be very helpful to also show the provider (and optionally the “via” aggregator like OpenRouter or Ollama).

Proposed solution (simple & robust)

Instead of refactoring every display component, we can save the provider info when a model is selected — and reuse it everywhere.

At model selection time, store this structure in the app state:

{
  providerTop: 'anthropic' | 'openai' | 'kilocode' | 'local' | ...,
  via?: 'openrouter' | 'ollama' | 'lmstudio' | ...,
  modelId: 'claude-3-7-sonnet',
  displayName?: 'Claude 3.7 Sonnet'
}

Then, use a shared label formatter:

formatModelLabel(sel) ➜
  "Kilo Code → OpenRouter → GLM 4.6 Turbo"
  "Anthropic → Claude 3.7 Sonnet"
  "Local → Ollama → llama3.1:8b"

Why this approach?

• ✅ Fastest to implement (only one change in selection handler + small store update)
• ✅ No schema migration
• ✅ No new network calls
• ✅ Single source of truth (activeModel state)
• ✅ Consistent UI across all views

Affected areas

• Model selector (display current choice)
• Status bar (show active model)
• Chat/Orchestrator header
• Toasts or logs that display model info

Implementation sketch

1. Extend the store with activeModel.
2. Save providerTop + via when user selects a model.
3. Add utility formatModelLabel(activeModel).
4. Replace current raw labels by the formatted one.
5. Add minimal tests (unit + snapshot).

Expected result

• The UI now shows clear model origin:

  • Kilo Code → OpenRouter → GLM 4.6 Turbo
  • Anthropic → Claude 3.7 Sonnet
  • Local → Ollama → llama3.1:8b

• Users instantly know which provider they’re using (affecting quotas & pricing).

• Zero breaking change.

Optional future improvements

• Tooltip with provider base URL (for custom endpoints)
• “Pricing info” button (OpenRouter / Kilo)
• Analytics on model/provider usage (if history is desired later)

---

💡 Example screenshots (to add later)

Add screenshots showing the label in:

• Model selector dropdown
• Status bar
• Chat header

---

---

---

✅ Summary: map → save → reuse

The simplest and fastest way to show Provider → (via) → Model everywhere.

---

1️⃣ Map (infer the provider chain)

Create a small utility that figures out which provider(s) are involved when a model is selected.

// inferProviderChainFromContext.ts
export function inferProviderChain(ctx: any) {
  if (ctx.runtime === 'local')
    return { providerTop: 'local', via: ctx.provider }; // ollama / lmstudio

  if (/openrouter/i.test(ctx.baseUrl || ''))
    return { providerTop: 'kilocode', via: 'openrouter' };

  if (/litelmm|lite-?llm/i.test(ctx.baseUrl || ''))
    return { providerTop: 'kilocode', via: 'litelmm' };

  // direct vendor (Anthropic, OpenAI, etc.)
  return { providerTop: ctx.provider || 'kilocode' };
}

---

2️⃣ Save (when the user selects a model)

Store the provider info together with the model in your app state.

// modelSelectionStore.ts (Redux or Zustand)
type ActiveModel = {
  providerTop: string;
  via?: string;
  modelId: string;
  displayName?: string;
};

// Example handler
function onModelSelected({
  modelId,
  displayName,
  context,
}: {
  modelId: string;
  displayName?: string;
  context: any;
}) {
  const { providerTop, via } = inferProviderChain(context);
  setActiveModel({ providerTop, via, modelId, displayName });
}

Now you have a single source of truth (activeModel) with both provider and model info.

---

3️⃣ Reuse everywhere (with one formatter)

Create one display function for a consistent label across the whole UI.

// formatModelLabel.ts
const PRETTY: Record<string, string> = {
  kilocode: 'Kilo Code',
  openai: 'OpenAI',
  anthropic: 'Anthropic',
  google: 'Google',
  openrouter: 'OpenRouter',
  litelmm: 'LiteLLM',
  local: 'Local',
  ollama: 'Ollama',
  lmstudio: 'LM Studio',
};

export function formatModelLabel(sel?: ActiveModel) {
  if (!sel) return '(no model selected)';
  const top = PRETTY[sel.providerTop] ?? sel.providerTop;
  const via = sel.via ? PRETTY[sel.via] ?? sel.via : '';
  const model = sel.displayName || sel.modelId || '(unknown model)';
  return via ? `${top} → ${via} → ${model}` : `${top} → ${model}`;
}

---

4️⃣ Hook it up (UI integration)

Use formatModelLabel(activeModel) everywhere a model name appears:

• Model selector (selected value)
• Status bar / footer
• Chat / Orchestrator header
• Toasts and logs

That ensures a single unified label, e.g.:

Kilo Code → OpenRouter → GLM 4.6 Turbo
Anthropic → Claude 3.7 Sonnet
Local → Ollama → llama3.1:8b

---

5️⃣ Quick tests

• Unit tests:

  • formatModelLabel for top-only, top+via, local, missing fields.
  • inferProviderChain for openrouter / litellm / local / direct.

• Integration test:
  Selecting a model updates activeModel and every UI element displays the same formatted label.

---

🧩 TL;DR

1. Infer provider chain →
2. Save {providerTop, via, modelId} in store when selected →
3. Display it everywhere via formatModelLabel()

✅ Simple
✅ Fast
✅ No breaking changes
✅ Fully consistent across the app

[mcowger]

I'm curious where you think this would be shown/needed?

Reviewing the UI, I only see 2 places where the model slug (glm-4.6 or similar) is shown:

1. In the provider profile selection dropdown. In this case, the user is already choosing the provider, and the model slug is the right thing to show because it is the exact data returned from the provider.

2. In the quick model picker below the chat window. I could see some potential value here, but I would suggest the text proposed is much too long.

In all other locations, we show the user supplied name for the profile, which I think is optimal - if the user chooses to name something, we should respect that.

So I think to address the user experience you mention, I'd recommend naming your profiles in a way that makes sense to you. If you have GLM from multiple sources, you could use my naming schemes:

GLM 4.6 > Synthetic
GLM 4.6 > OpenRouter

That way, you always know what you are using and will show up in the UI pretty much everywhere.

[coder4web]

I think such hint is a good idea, I include provider in profile's title now :)

[Phosphate5429]

I think such hint is a good idea, I include provider in profile's title now :)

really?? you do it coder4web?? so great !! i tried do it myself but don't know typescript and have some difficulties to do it. thx again.

[mcowger]

• yeah that's the quick picker I mentioned above in number 2. That picker ONLY shows models available from the currently selected provider.

FWIW, that's not really the intended way to choose models on a regular basis, but I realize it's confusing (personally I think it should be removed).

But, if you wanted to attempt a more focused change, I think it might be reasonable to add a tooltip to that picker that shows the provider type (openrouter | lmstudio | kilocode etc).

[Phosphate5429]

just for see the provider currently in use, not for change it. like for glm every providers have it with differents prices and can change provider often, like that can see in one second what provider is.

• yeah that's the quick picker I mentioned above in number 2. That picker ONLY shows models available from the currently selected provider.

FWIW, that's not really the intended way to choose models on a regular basis, but I realize it's confusing (personally I think it should be removed).

But, if you wanted to attempt a more focused change, I think it might be reasonable to add a tooltip to that picker that shows the provider type (openrouter | lmstudio | kilocode etc).

[mcowger]

I see. Yeah, you could prepend the quick picker with the provider name pretty easily.

Give it a shot! Happy to help and review.

[LivioGama]

It's more complex than it looks like. First of all, it's weird. Because since it requires passing by the settings to switch, you should know in theory what provider you use. Truth is it's not that simple. But then if you can see what provider you use, then it does not make sense to not provide an affordance there.