Replace GPT 5.5 with GPT 5.6 Sol and route OpenAI models through the Responses API

[youknowriad]

Related issues

• N/A

How AI was used in this PR

Entirely built with Claude Code (Fable 5): it made the model swap, then diagnosed the resulting 400 (no body) failure by capturing the CLI's exact request with a local logging proxy and bisecting it against the wpcom AI proxy, and implemented and verified the fix end-to-end (live turns with tool calls through the proxy). Code reviewed by @youknowriad.

Proposed Changes

• Replaces the GPT 5.5 option in the Studio Code model picker with GPT 5.6 Sol, OpenAI's current flagship (same price as GPT 5.5).
• Routes OpenAI models through the proxy's /v1/responses path instead of /v1/chat/completions. This is required for the upgrade: GPT 5.6 Sol rejects function tools on Chat Completions when reasoning is active (the API suggests using /v1/responses or disabling reasoning), and every Studio Code turn attaches the agent's tools — so all GPT 5.6 Sol turns failed with a 400 before this change. The Responses API supports tools with reasoning intact, so users get the model's full capability rather than a reasoning-disabled fallback.
• Sessions that recorded the removed gpt-5.5 id fall back to the default model automatically on their next turn (existing behavior for removed models); no migration needed.
• Side effect worth noting: the old "Chat Completions only" blocker for reasoning-only OpenAI variants (gpt-*-pro, o*) is gone. They stay excluded for now due to proxy/SDK timeout concerns on long reasoning turns.

Testing Instructions

• npm run cli:build && node apps/cli/dist/cli/main.mjs ai
• /model → select GPT 5.6 Sol
• Send a prompt that triggers a tool call (e.g. "List my local sites") — the turn should complete with a tool round-trip instead of failing with 400 status code (no body).
• Also verify a plain-text prompt and a model switch back to Sonnet 5 mid-session.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

🤖 Generated with Claude Code

[wpmobilebot]

📊 Performance Test Results

Comparing f593f9a vs trunk

app-size

Metric	trunk	f593f9a	Diff	Change
App Size (Mac)	1350.33 MB	1411.88 MB	+61.55 MB	🔴 4.6%

site-editor

Metric	trunk	f593f9a	Diff	Change
load	1081 ms	1029 ms	52 ms	🟢 -4.8%

site-startup

Metric	trunk	f593f9a	Diff	Change
siteCreation	6982 ms	6979 ms	3 ms	⚪ 0.0%
siteStartup	2352 ms	2351 ms	1 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[sejas]

I tested it by creating a new site and the result was really good.

I'm also adding the cost for the new model 228029-ghe-Automattic/wpcom

Here's my preview site created with GPT 5.6 https://antoniosejas-mofxg-studio.wp.build/

[sejas]

I got an error: ⏺ OpenAI API error (400): 400 status code (no body). I think it’s related to compacting the conversation. The conversation stopped, and I just said “continue” to complete the site.

[youknowriad]

Debugged the 400 (@sejas's review + a local repro): compaction turned out to be a symptom, not the cause. We declared contextWindow: 200_000 but GPT 5.6 Sol's real window is 1.05M — once a session's estimated context crossed 200K, pi clamped the output budget to max_output_tokens: 1, which OpenAI rejects with a 400 (Expected a value >= 16). The proxy strips error bodies on streaming requests, hence "no body". The post-compaction retry failed the same way because the kept tail still carries the pre-compaction usage record, keeping the estimate above 200K.

Fixed in f593f9a: the model now declares contextWindow: 272_000 (capped at OpenAI's 2× long-context pricing threshold rather than the full 1.05M) and maxTokens: 32_000. Verified by replaying the exact failing request from the broken session — same request succeeds with a sane output budget. Long sessions should now compact normally instead of erroring.

[sejas]

Thanks for finding the issue and implementing the fix. ✨