feat: add GPT-5.6 OpenAI model support

[byapparov]

Closes#104

Problem

OpenAI's GPT-5.6 Sol, Terra, and Luna models are present in the live registry, but Codex OAuth filters them out and the CLI stops reasoning variants at xhigh.

Behavior

• Adds catalogue metadata for Sol, Terra, and Luna.
• Exposes API efforts from none through max.
• Exposes Codex OAuth efforts through ultra for Sol/Terra and through max for Luna.
• Normalizes ultra to the API's max wire value.
• Applies Codex OAuth context limits and zero subscription cost.
• Bumps @aictrl/cli to 0.4.3.

Scope

Live models.dev metadata remains authoritative. This does not add gateway availability or new multi-agent orchestration behavior.

Rollout and risks

No migration or configuration change is required. Model availability still depends on the upstream registry and OpenAI account access.

Verification

• bun test — 1,370 passed, 7 skipped, 0 failed.
• bun run typecheck — passed.
• bunx prettier --check ... — passed.
• AICTRL_BUILD_SINGLE=true bun run build — passed.
• git diff --check — passed.
• GitHub Actions verify — passed.
• Aictrl AI Review and KG Extract — passed with 0 findings.
• CodeQL actions, JavaScript/TypeScript, and aggregate checks — passed.

Test plan

• Verify API and OAuth effort matrices with provider-transform tests.
• Verify OAuth filtering, limits, costs, and ultra normalization with plugin tests.
• Run the complete CLI test suite and production build.

[github-actions]

Review: feat: add GPT-5.6 OpenAI model support

Overall this looks correct and well-contained. I verified:

• The Codex OAuth fetch wrapper rewrites /v1/responses and /chat/completions requests to the Codex endpoint regardless of the model's registry URL, so the 5.6 models work under OAuth without an api.url override.
• family: "gpt-codex" is only consumed by the new variants branch (no other behavior keys off it), so the mutation in the plugin is safe.
• model.api.id is populated on both registry and config paths (provider.ts:788, provider.ts:934), so the new guard in variants() won't see undefined.
• Extra fixture fields (reasoning_options, description, etc.) are stripped by the non-strict zod schema, so they're documentation-only and harmless.
• The ultra → max wire normalization is covered by tests on both the plugin and transform sides.

Non-blocking observations:

1. Inconsistent ID matching (transform.ts:518): the new GPT-5.6 guard uses exact, case-sensitive matching on model.api.id, while every other branch in variants() matches on the lowercased model.id (id). Registry IDs are lowercase today so this works, but a config-defined model with a non-lowercase api.id would silently fall through to the generic release-date heuristics. Consider reusing id (or lowercasing) for consistency.

2. max and ultra are byte-identical (transform.ts:543): after normalization both variants send reasoningEffort: "max", so model/variant listings will surface two entries with identical behavior. Intentional per the PR description (Codex-only alias), just flagging the UX duplication. Relatedly, the ultra → max rewrite applies to every effort built in the @ai-sdk/openai case — if a future model legitimately exposes ultra as a distinct wire value it would be silently renamed. Scoping the mapping to the GPT-5.6 Codex branch (or a brief comment) would harden that.

3. No fallback injection (codex.ts:409-415): unlike gpt-5.3-codex, if the user's cached models.dev registry predates the 5.6 models, if (!model) continue silently drops them. Fine given the live registry is authoritative; just noting the asymmetry with the 5.3 fallback.

4. Hardcoded limits (codex.ts:413): the 400k/272k/128k limits mirror gpt-5.3-codex for all three models. If Sol/Terra/Luna differ on the Codex backend, this would need per-model values — worth confirming against the upstream docs.

No security concerns: no secrets or injection surface touched; the OAuth header-stripping/rewriting code is unchanged.

Verified statically; could not run bun test in this environment (network-restricted install), but the new tests cover the effort matrices, filtering, limits, cost zeroing, and normalization, and the changes are consistent with existing patterns.

Reviewed SHA: 0e01397

[aictrl-dev]

Code review

Verdict: Looks good. ✅ · 0 findings

Reviewed 7 files · 0 inline · view all 0 findings ↗

---

aictrl · AI code review for fast-moving teams · aictrl.dev