fix(ai): use Azure Foundry 1.05M context window for GPT-6 models (#11781)

Azure's OpenAI models are copied from the direct `openai` provider. That
provider caps the GPT-6 family at 272K so requests stay in OpenAI's
short-context pricing tier.

The Azure provider overrides this cap through
`CONTEXT_WINDOW_OVERRIDES`, but that list only covered gpt-5.4, gpt-5.5
and gpt-5.6. As a result, `azure/gpt-6-astra`, `gpt-6-luna`,
`gpt-6-sol`, `gpt-6.1-sol` and `gpt-6.1-terra` showed a 272K context
window, and pi compacted sessions far earlier than needed. Azure Foundry
deploys these models with a 1,050,000-token context window.

This change adds the five models to the Azure override list.
OpenAI-direct is unchanged.

Testing:
- Added a test in `packages/ai/test/supports-xhigh.test.ts` that checks
each of these Azure models has a 1,050,000 context window. It fails on
all five models without the override (5 failed) and passes with it.
- After regenerating the model data, the generated Azure catalog lists
all five models at 1050000. Before the change they were at 272000.
- `npm run check` passes.

Fixes #11742

Requested by @badlogic

Co-authored-by: triagent <triagent@localhost>
This commit is contained in:
robopipi[bot] 2026-11-04 09:34:35 +01:00 • committed by GitHub
parent 37b38e9f65
commit b317575fd1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 13 additions and 0 deletions

View file

@ -12,6 +12,7 @@
- Fixed OpenCode Go Claude Haiku 5.5 failing with a 400 (`Invalid signature in thinking block ... bound to a different conversation`) after the tool list, system prompt, or earlier history changed, which left the session failing on every retry. OpenCode Go and Zen Claude 5.5 models, Opus 5, and Fable 5.1 now use per-message effort and send `thinking.block_binding: drop_block`, like the Anthropic provider ([#10954](https://github.com/earendil-works/pi/issues/10954))
- Fixed Anthropic non-strict tool schemas dropping root `$defs` and `definitions`, which left property `$ref`s pointing at nothing. Claude then produced wrong arguments for such tools (common in MCP servers), for example a JSON string instead of an object, and some Anthropic-compatible gateways rejected the request outright ([#9557](https://github.com/earendil-works/pi/issues/9557))
- Fixed OpenRouter rejecting requests with a 400 (`This endpoint's maximum context length is ...`) for models whose output limit is close to the context window, such as DeepSeek flash. OpenRouter counts the input with its own tokenizer, which can be several percent higher than the provider's count, and pi left only 4,096 tokens spare. pi then treated the 400 as a context overflow and compacted the session, even at around 20% of the window. The default output limit now leaves 15% of the estimated input unused, and near a full window at most 32,768 output tokens are requested ([#10497](https://github.com/earendil-works/pi/issues/10497))
- Fixed Azure GPT-6 Astra, Luna, Sol, GPT-6.1 Sol, and GPT-6.1 Terra using a 272K context window instead of the 1,050,000 tokens Azure Foundry deploys them with ([#11742](https://github.com/earendil-works/pi/issues/11742))
## [1.5.0] - 2026-11-02

View file

@ -10,6 +10,11 @@ const CONTEXT_WINDOW_OVERRIDES: Record<string, number> = {
"gpt-5.6-luna": 1050000,
"gpt-5.6-sol": 1050000,
"gpt-5.6-terra": 1050000,
"gpt-6-astra": 1050000,
"gpt-6-luna": 1050000,
"gpt-6-sol": 1050000,
"gpt-6.1-sol": 1050000,
"gpt-6.1-terra": 1050000,
};
// Azure resells DeepSeek at its own rates. US data zone, checked 2026-09-16.

View file

@ -169,6 +169,13 @@ describe("getSupportedThinkingLevels", () => {
}
});
it.each(["gpt-6-astra", "gpt-6-luna", "gpt-6-sol", "gpt-6.1-sol", "gpt-6.1-terra"] as const)(
"uses the Azure Foundry 1.05M context window for %s",
(modelId) => {
expect(getModel("azure", modelId)?.contextWindow).toBe(1050000);
},
);
it("includes only medium/high/xhigh for OpenAI GPT-5.5 Pro", () => {
const model = getModel("openai", "gpt-5.5-pro");
expect(model).toBeDefined();