BYOK custom providers cannot expose context-window tiers (no `supported_context_tiers`)

Feature summary

Let BYOK (custom Model Provider) models declare their supported context-window tiers, so the model picker can offer the context-tier toggle for them.

What problem are you trying to solve?

Built-in Copilot models can be switched between a default and a long-context tier (e.g. claude-opus-5 at 264k vs ~1M). Models supplied by a custom Model Provider never show that control, even when the underlying model genuinely supports both tiers.

In my case the same Anthropic and OpenAI models are reachable two ways — through built-in Copilot, and through a corporate gateway configured as a BYOK provider. The built-in entry offers the tier toggle; the BYOK entry does not, despite being backed by a model that serves 1M tokens.

Tracing it, this looks structural rather than like a bug. From the shipped SDK schema (copilot-sdk/generated/rpc.d.ts, on Model.supportedContextTiers):

Context-window tiers this model offers, when the provider advertises them independently of tiered token pricing. Copilot models carry their tiers in billing.tokenPrices; a provider that has no pricing to publish (an agent host reached over AHP, for example) declares them here instead, so the model picker can still offer the tier toggle.

That mechanism appears unreachable for BYOK:

• ProviderModelConfig (types.d.ts, rpc.d.ts) exposes maxPromptTokens, maxContextWindowTokens and maxOutputTokens — but no tier field.
• provider_models has no tier column. context_tier exists only on sessions and workflows.
• supported_context_tiers does not appear anywhere in the app binary.

So there is no place to record which tiers a user-supplied model accepts, and the toggle can't render.

This is precisely the gap the app already closed one level down, for reasoning effort — quoted verbatim from the shipped migration:

-- github/app#2735: custom Model Provider models could not expose a reasoning
-- effort control because the app had no place to record which effort levels a
-- user-supplied model accepts. Providers are BYOK, so the capability can't be
-- known at build time and has to live alongside the rest of the per-model
-- configuration.
--
-- Stored as a JSON array of effort strings (e.g. '["low","medium","high"]').
-- NULL (the default for every existing row) means "no reasoning effort", which
-- is exactly today's behaviour, so non-reasoning models are unaffected.
ALTER TABLE provider_models ADD COLUMN supported_reasoning_efforts TEXT;

Every word of that rationale applies to context tiers.

Proposed solution

Mirror the supported_reasoning_efforts design exactly:

1. Add a nullable column, e.g.

   ALTER TABLE provider_models ADD COLUMN supported_context_tiers TEXT;
   

   storing a JSON array such as '["default","long_context"]'. NULL keeps today's behaviour, so existing providers are unaffected.

2. Add the matching optional field to ProviderModelConfig (supportedContextTiers?: ContextTier[]), alongside the maxPromptTokens / maxContextWindowTokens / maxOutputTokens fields already there.

3. Gate the picker's tier toggle on that column when modelSource is a provider, the same way supported_reasoning_efforts gates the effort control.

4. Ideally surface it in the BYOK provider UI. Reasoning effort currently has no UI field either, which forces users to write to data.db by hand — worth not repeating.

A smaller, independent improvement: provider_models has max_prompt_tokens and max_output_tokens, but no max_context_window_tokens, even though ProviderModelConfig can express it. Adding that column would let a provider state its true window without inferring it from prompt + output.

Workflow impact

Anyone pointing Copilot at a gateway, proxy, or self-hosted endpoint — which for enterprise users is often the only sanctioned route to these models. We can't use built-in Copilot models directly; everything goes through an approved internal gateway.

Concretely, on my setup the same underlying models are capped well below their real capability:

Model (via BYOK)	Real prompt limit	Tier toggle
claude-opus-5	872,000	not offered
claude-sonnet-5	872,000	not offered
gpt-5.6-sol	922,000	not offered
gemini-3.7-flash	1,048,576	not offered

Those limits were measured against the live gateway, not assumed — each request was grown until the upstream returned its own ceiling verbatim (e.g. Input tokens exceed the configured limit of 922000 tokens, prompt is too long: 1038732 tokens > 1000000 maximum).

Installation context

GitHub Copilot desktop app 1.1.15 on Windows 11 (26100); bundled CLI 1.0.83-5. Custom Model Provider, wire API completions, pointed at a local OpenAI-compatible proxy in front of a corporate GenAI gateway.

Additional context

Workaround, for anyone hitting the related token-budget half of this. BYOK models otherwise default to a hardcoded 128,000 prompt budget, because the app synthesizes them from provider_models — where max_prompt_tokens is NULL for custom providers — and never reads limits from the provider's /v1/models response. Writing the column directly does work:

UPDATE provider_models
   SET max_prompt_tokens = 872000, max_output_tokens = 128000
 WHERE model_id LIKE 'claude-%';

Verified 2026-09-07: a new session on a BYOK claude-opus-5 was budgeted 872000 / 128000, against 128000 before the edit, and the values survived an app restart. Caveats: the app must be fully quit (it rewrites data.db on exit), rows are created lazily so a model never opened in the picker has no row to update, and editing the model in the BYOK UI can reset the column to NULL.

Two related observations while verifying:

• Sessions snapshot their limits at creation, so only new sessions reflect a change.
• The picker's context indicator can keep showing the old figure, because the cached catalogue (app_state.copilot-available-models-v2) carries no capabilities.limits for BYOK entries. sessions.context_input_token_limit is the reliable signal. Same shape of confusion as the reasoning-effort label before #2735.

That workaround covers the token budget only. It cannot produce a tier selector, which is what this request is about.

I'd be glad to test a build.

Inizia dalla migrazione esistente di supported_reasoning_efforts e dalle definizioni di ProviderModelConfig in types.d.ts e rpc.d.ts, quindi traccia il percorso dei dati di provider_models fino al selettore dei modelli. Il lavoro è completato quando i livelli di contesto supportati nullable vengono persistiti per i modelli BYOK, il selettore offre il toggle del livello quando configurato e le righe dei provider esistenti mantengono il comportamento attuale.