The `openai` provider still defaulted to `gpt-5.5`. The same default
applies to API-key logins and to "Sign in with ChatGPT", so logging in
through ChatGPT selected `openai/gpt-5.5`. The reporter says that model
no longer works with a ChatGPT subscription. The `openai-codex` and
`github-copilot` providers already default to `gpt-6.1-sol`.
This change sets `defaultModelPerProvider.openai` to `gpt-6.1-sol` in
`packages/coding-agent/src/core/model-resolver.ts`. The new value
applies in three places: the model picked after `/login` when no model
was set, the fallback model at startup, and the default model for
`--provider openai`. API-key users get the new default too.
I did not test against a real ChatGPT account, so the claim that the
subscription rejects `gpt-5.5` is not checked here.
Testing:
- Updated the assertion in `test/model-resolver.test.ts` ("openai
defaults track current models"). It now expects `gpt-6.1-sol`; the
model-resolver tests pass.
- `npm run check` passes.
- `pi --list-models gpt-6.1` still lists `openai/gpt-6.1-sol`, so the
new default is in the catalog.
Fixes#11442
Requested by @badlogic
Co-authored-by: triagent <triagent@localhost>
`--model "<provider>/<id>"` returned "not found" when the provider id
itself contains a `/`. URL-derived ids such as
`llama-server=http://host:10800` are one example.
`splitProviderPrefix()` in `model-resolver.ts` split the reference at
the first `/`, which turned the prefix into `llama-server=http:`. No
provider has that id, so resolution fell through to not-found.
`splitProviderPrefix()` now compares the text against the provider ids
in the catalog. A provider matches when the text starts with its id
followed by `/`, and the longest matching id wins. Ordinary provider ids
resolve exactly as before.
Testing:
- I added two cases to the `resolveModelReference` table in
`test/model-resolver.test.ts`, using a provider
`llama=http://host:10800`: one plain, one with a `:high` thinking
suffix. Both fail without the change and pass with it. The test runs
every case against the catalog in both orders.
- `node ../../node_modules/vitest/dist/cli.js --run
test/model-resolver.test.ts`: 64 passed.
- `npm run check`: passes.
- Before the change, a standalone check of `resolveModelReference` with
the reporter's exact provider and model
(`llama-server=http://host:10800/unsloth/Qwen3.8-27B-GGUF:BF16`)
returned `not-found`. It now returns `resolved`.
- One test, `test/model-runtime-classifiers.test.ts` ("applies provider
compat from models.json to classifier models"), fails in my environment
both with and without this change. It is unrelated to this fix.
Fixes#11394
Requested by @badlogic
Co-authored-by: triagent <triagent@localhost>
* fix(coding-agent): resolve model references through one provider selection policy
Model references from --model, --models/enabledModels, /model, and auth credential printing now share one resolver. It collects every candidate before choosing a provider, so catalog order never decides, a :<thinking> suffix cannot change the provider, and an ambiguous exact match no longer falls through to a fuzzy match.
provider/id still prefers the named provider's exact or fuzzy match. A gateway exposing provider/id as a raw model id is used when the named provider has no match, or lacks credentials while the gateway has them. Several gateways without a unique authenticated one are reported as ambiguous.
fixes#10160
* docs(coding-agent): shorten model selection notes in CLI reference
* docs(coding-agent): condense #10160 changelog entry
* fix(coding-agent): move model reference resolution into model-resolver
* fix(coding-agent): warn when a model scope pattern matches several providers
* docs(coding-agent): trim model resolver comments to the reasons
* fix(coding-agent): build custom model ids from the resolver's not-found target
* feat(ai): support Azure Foundry Chat Completions deployments
The Azure provider only implemented the Responses API, so Foundry
deployments that speak Chat Completions could not be used. On Chat
Completions the deepseek/deepseek-v4-pro model sends `thinking` and
`prompt_cache_key`, both of which Azure rejects with 400.
The provider now dispatches openai-completions alongside
azure-openai-responses. A stream wrapper resolves the Azure endpoint
onto the model first, since the shared openai-completions
implementation reads it off the model.
The request-shape differences are catalog compat rather than api code:
reasoning_effort instead of DeepSeek's thinking field, no prompt cache
parameters, reasoning_content kept on assistant turns so the prefix
Foundry cached stays byte-identical, and effort clamped to the
low/medium/high the deployment accepts.
The provider is renamed from azure-openai-responses to azure, since it
now serves more than the Responses API. The azure-openai-responses api
id is unchanged. Breaking: auth.json and models.json entries keyed on
azure-openai-responses must move to azure, and existing sessions see a
different provider on their next turn.
closes#9645
* feat(ai): apply the Azure deployment name map to Chat Completions
The Responses path already sent the deployment name from
AZURE_OPENAI_DEPLOYMENT_NAME_MAP. The Chat Completions path sent the
catalog model id, so any deployment not named after the model 404'd.
The Azure provider now swaps the deployment name into the request via
onPayload before dispatch, then runs the caller's own onPayload on it.
model.id stays the catalog id. The map helpers move to
azure-openai-config.ts so the provider can share them without
importing the SDK.
* docs(ai,coding-agent): add changelog entries for the Azure provider rename
Breaking: the azure-openai-responses provider is now azure. Users rename
the key in auth.json, models.json, and settings.json; SDK users switch to
getModel("azure", ...) and providers/azure.
Also note Azure Foundry Chat Completions support (DeepSeek V4 Pro).
---------
Co-authored-by: David Brailovsky <davidbrai@gmail.com>
Add gpt-6.1-sol to the OpenAI, Azure OpenAI Responses, and OpenAI Codex
providers with official pricing ($2 input, $0.10 cached input, $2.50
cache writes, $10 output, long-context tier above 272k). The model
rejects reasoning.effort "none", so off is unsupported and clamps to
the lowest effort.
* feat(ai): route xAI models through Responses and default to Grok 4.6
Send built-in xAI catalog models through the Responses API with
store: false and include reasoning.encrypted_content so encrypted
reasoning is requested and replayed, including future models.dev
additions. Thinking levels come from models.dev reasoning_options
(grok-4.6 exposes xhigh); models without verified options
(grok-build-0.1) keep reasoning always on and never send unsupported
"none"/"minimal" efforts. Narrow the xAI provider to the Responses API,
send pi's runtime User-Agent on xAI requests for provider-side
attribution, and make Grok 4.6 the default xAI model.
* fix(ai): drop duplicate xAI encrypted-reasoning tests
Azure already covers the shared replay path; keep the xAI-specific include-without-effort case next to the existing request tests.
---------
Co-authored-by: Jaaneek <Jaaneek@users.noreply.github.com>
Move provider auth and OAuth flows onto pi-ai Models, compose models.json and extension overlays through ModelRuntime, and retain ModelRegistry as an extension compatibility facade.
Update the coding-agent default model picks for ZAI, Cerebras,
and MiniMax so new sessions prefer the current model lineup.
Add the missing MiniMax-M2.1-highspeed direct provider entries
and normalize MiniMax Anthropic-compatible context limits so the
catalog matches the provider's supported model set.
When resolving --model zai/glm-5, the resolver now correctly interprets
'zai' as the provider and 'glm-5' as the model id, rather than matching
a vercel-ai-gateway model whose id is literally 'zai/glm-5'.
If the provider/model split fails to find a match, falls back to raw id
matching to still support OpenRouter-style ids like 'openai/gpt-4o:extended'.
- Fix ai/CHANGELOG.md: add PR link and author attribution
- Add coding-agent/CHANGELOG.md entry for vercel-ai-gateway provider
- Fix model-resolver.test.ts: use anthropic-messages API type to match generated models
- Add vercel-ai-gateway to test suites: tokens, abort, empty, context-overflow, unicode-surrogate, tool-call-without-result, image-tool-result, total-tokens, image-limits
When enabledModels is configured without thinking level suffixes (e.g.,
'claude-opus-4-5' instead of 'claude-opus-4-5:high'), the scoped model's
default 'off' thinking level was overriding defaultThinkingLevel from
settings.
Now thinkingLevel in ScopedModel is optional (undefined means 'not
explicitly specified'). When passing to SDK, undefined values are filled
with defaultThinkingLevel from settings.
Major changes:
- Replace monolithic SessionEvent with reason discriminator with individual
event types: session_start, session_before_switch, session_switch,
session_before_new, session_new, session_before_branch, session_branch,
session_before_compact, session_compact, session_shutdown
- Each event has dedicated result type (SessionBeforeSwitchResult, etc.)
- HookHandler type now allows bare return statements (void in return type)
- HookAPI.on() has proper overloads for each event with correct typing
Additional fixes:
- AgentSession now always subscribes to agent in constructor (was only
subscribing when external subscribe() called, breaking internal handlers)
- Standardize on undefined over null throughout codebase
- HookUIContext methods return undefined instead of null
- SessionManager methods return undefined instead of null
- Simplify hook exports to 'export type * from types.js'
- Add detailed JSDoc for skipConversationRestore vs cancel
- Fix createBranchedSession to rebuild index in persist mode
- newSession() now returns the session file path
Updated all example hooks, tests, and emission sites to use new event types.
