feat: support GPT-5.6 model family

[wyuc]

Summary

• add gpt-5.6 (the official GPT-5.6 Sol alias), gpt-5.6-terra, and gpt-5.6-luna to the built-in OpenAI model catalog
• canonicalize explicit gpt-5.6-sol references to gpt-5.6 across model metadata, thinking settings, usage aggregation, toolbar/PBL capability checks, and token-plan hydration while preserving the requested wire model ID
• make managed-provider model filtering alias-aware, including canonical capability inheritance and directional allowlist-safe selection reconciliation
• route the GPT-5.6 family through the Responses API with the official 1,050,000-token context window and 128,000-token output window
• support reasoning efforts from none through max, defaulting to medium
• upgrade @ai-sdk/openai within the existing major version so the runtime schema accepts GPT-5.6 max reasoning effort
• update the supported-model documentation in all six locales

Why

OpenAI introduced the GPT-5.6 family with Sol, Terra, and Luna tiers and added the max reasoning effort. The previous OpenAI SDK version rejected max during provider-option validation, so catalog-only changes would not provide complete support.

The built-in catalog uses only gpt-5.6 for Sol because OpenAI documents it as an alias of gpt-5.6-sol. This avoids duplicate per-model settings and usage tracking for the same tier.

Validation

• full clean-environment test suite: 265 test files, 2,229 tests passed
• real @ai-sdk/openai integration test verifies reasoning.effort: "max" in the Responses API request body
• managed alias regressions verify vision/thinking metadata inheritance and canonical-to-alias allowlist reconciliation
• independent pre-push code review completed with no blocking findings
• pnpm exec tsc --noEmit --incremental false
• ESLint on affected TypeScript files
• Prettier check on all affected files
• git diff --check

[cosarah]

I found one substantive gap and one smaller follow-up item.

1. The regression coverage still does not exercise the real @ai-sdk/openai validation path that this PR is meant to unblock. The version bump is in package.json:29 and pnpm-lock.yaml:17, but tests/ai/llm-thinking-options.test.ts:1 mocks ai.generateText, and tests/ai/openai-provider.test.ts:1 mocks @ai-sdk/openai. That means the new tests verify object construction and routing decisions, but they do not prove that the upgraded SDK now actually accepts reasoningEffort: "max" at runtime. If possible, I would add one integration-style test around the real provider options schema, since that is the core behavior this PR claims to fix.

2. Smaller point: lib/ai/providers.ts:68 and the supported-model docs now expose both gpt-5.6 and gpt-5.6-sol as separate built-in models. If gpt-5.6 is just an alias of gpt-5.6-sol, this will fragment per-model settings and usage tracking because those are keyed by raw model ID (lib/ai/thinking-config.ts:9, lib/store/settings.ts:914, lib/ai/llm.ts:280). If the alias is intentional, it may be worth normalizing one of them internally or documenting the duplication explicitly.

[wyuc]

Addressed both points in 96b6c4d:

1. Added a real @ai-sdk/openai integration test (no SDK or generateText mock) that exercises provider-option validation and asserts the Responses API request contains reasoning: { effort: "max" }.
2. Confirmed from the OpenAI model docs that gpt-5.6 aliases GPT-5.6 Sol. The built-in catalog now exposes only gpt-5.6 with the display name “GPT-5.6 Sol”, so settings and usage tracking are not split across duplicate IDs. The Responses API routing still accepts the official gpt-5.6-sol ID when supplied explicitly.

Validation: 264 test files / 2,216 tests passed in a clean environment, plus TypeScript, ESLint, Prettier, and git diff --check.

[cosarah]

I agree that gpt-5.6 being an alias of gpt-5.6-sol is valid. My concern is narrower: this patch removes explicit built-in support for the official gpt-5.6-sol ID while still accepting that ID at runtime.

Right now lib/ai/providers.ts:68 and lib/ai/model-metadata.ts:241 only register gpt-5.6, gpt-5.6-terra, and gpt-5.6-luna. But lib/ai/providers.ts:1467 still routes any gpt-5.6-* model through the Responses API, and tests/ai/openai-provider.test.ts:104 still explicitly treats gpt-5.6-sol as a valid OpenAI model ID.

That means openai:gpt-5.6-sol is now in a half-supported state:

• the request still goes out through Responses, so it may appear to work;
• but it no longer has built-in model info or built-in thinking metadata;
• so lookups that depend on exact catalog/model IDs (for example lib/utils/model-config.ts:17 and lib/ai/llm.ts:138) will not find configurable reasoning support for gpt-5.6-sol.

So the issue is not that aliases should be forbidden. The issue is that aliasing was only applied at the catalog layer, not normalized consistently across capability lookup / settings / thinking-option injection. If the intent is to canonicalize on gpt-5.6, I think we should also normalize gpt-5.6-sol to that canonical ID before those exact-ID lookups. Otherwise I would keep an explicit built-in entry for gpt-5.6-sol as well.

[wyuc]

Addressed in f01a470 by canonicalizing openai:gpt-5.6-sol to openai:gpt-5.6 for local lookups while preserving gpt-5.6-sol as the model ID sent to OpenAI.

The canonicalization now covers:

• catalog/model-info lookup;
• thinking capability lookup and provider-option injection;
• persisted thinking-settings keys;
• current-model configuration fallback;
• usage aggregation keys.

Regression coverage verifies the explicit Sol ID still goes through the Responses API, receives reasoningEffort: "max", resolves canonical model metadata, shares the canonical settings key, and records usage under openai:gpt-5.6.

Validation: 265 test files / 2,223 tests passed in a clean environment, plus TypeScript, ESLint, Prettier, and git diff --check.

[cosarah]

I think there are still two alias-compatibility gaps after the canonicalization patch:

1. components/generation/generation-toolbar.tsx:112 and components/scene-renderers/pbl/v2/submission.tsx:922 still look up the selected model by raw modelId instead of the canonicalized one. For a persisted openai:gpt-5.6-sol selection, that means currentModel / model becomes undefined, which has two user-visible effects:

• the toolbar falls back to the raw ID and loses the inline thinking control (components/generation/generation-toolbar.tsx:751);
• the submission modal treats the model as non-vision and can incorrectly require a caption for image-only submissions (components/scene-renderers/pbl/v2/submission.tsx:1114).

2. lib/config/apply-token-plan.ts:106 still does exact catalog lookup by raw ID. If a token plan ever seeds gpt-5.6-sol, catalogModelFor() misses the built-in OpenAI entry and tokenPlanModelInfo() falls back to a synthetic model with vision: false and no built-in context/output metadata (lib/config/apply-token-plan.ts:131). getCatalogThinkingCapability() is canonicalized now, but the rest of the model metadata in this path still is not.

So the core alias fix looks good, but there are still a few exact-ID UI/config paths that need to use the same canonicalization helper.

[wyuc]

Addressed the remaining alias paths in 00d5c88.

The fix now:

• centralizes alias-aware catalog lookup and applies it to the generation toolbar, PBL image submission, token-plan hydration, model config, and provider model-info paths;
• enriches managed gpt-5.6-sol entries from canonical gpt-5.6 metadata, preserving context/output windows plus vision/thinking capabilities while keeping the server-provided wire ID;
• reconciles selection directionally: an existing alias may use a canonical catalog entry without rewriting its wire ID, while a canonical selection is switched to the alias when the managed allowlist only permits the alias;
• makes the toolbar's managed-model membership check alias-aware.

Regression coverage includes the toolbar/PBL capability paths, token-plan metadata, managed alias metadata inheritance, and the canonical-to-alias allowlist transition.

I also did a repo-wide audit of raw LLM model-ID lookups, then ran an independent pre-push review. That review found the managed metadata and directional allowlist cases; both are now covered, and the final independent pass reported no blocking findings.

Validation: 265 test files / 2,229 tests passed in a clean environment, plus TypeScript, ESLint, Prettier, and git diff --check.

[cosarah]

LGTM