Everyone Removed the Off Switch: What I Learned Reading the GPT-6.1 Sol, Sonnet 5.5 and Gemini 3.8 Flash Migration Guides

Here is the whole argument up front. Between September 2 and September 29, 2026, Google, Anthropic and OpenAI each shipped a mid-tier model, and each one removed the same three things from its API. You can no longer turn thinking off: Gemini 3.8 Flash rejects minimal, Sonnet 5.5 rejects disabled, and GPT-6.1 Sol rejects none S6S10S2. You can no longer set temperature, top_p or top_k without an error or a silent strip S7S2S10. And you can no longer force the model's hand: Anthropic rejects forced tool choice and prefill, Google removes prefilled model turns, and OpenAI will not run tools at all on Chat Completions S6S10S3. What the three vendors left behind is the same shape, an effort enum with a cache that survives effort changes only if you ask nicely, and that shape is what a request builder should be written against. The prices happen to line up too, at $2 and $10 for two of the three, so the line that decides the bill is the one none of the launch posts lead with: what a cached token costs, and on Gemini, what it costs per hour to keep it cached.

I started this as the third post in a series. The first built an escalation ladder between Opus 5.5 and Fable 5.1 S25; the second showed the ladder cannot reach down to Sonnet 5.5 S24. The obvious next step was a router across three vendors, and I assumed the hard part would be the benchmarks. It was not. The hard part was that a request that worked on all three mid-tier models in August fails on all three in October, for three different reasons that turn out to be the same reason. This is that research, including the cache number I got wrong first.

FIG. 01 · One month, four launches, three vendors · what each release removed from a working request S2S6S10S14

What did each vendor take away, and in what order?

Google went first, and quietly. Gemini 3.8 Flash shipped on September 2, the third Flash release in six weeks, at the same $0.75 and $3.75 introductory prices as 3.7 Flash S12S21. Its migration checklist reads like a list of things you used to be allowed to do: strip temperature, top_p and top_k; replace the numeric thinking_budget with the thinking_level string enum, where minimal is no longer supported and returns an error; remove candidate_count; standardise multi-turn conversations on a server-side previous_interaction_id; and remove prefilled model turns S10. The page also says the quiet part out loud: 3.8 Flash can use more tokens on longer tasks, by design, because it takes smaller reasoning steps, calls tools iteratively and verifies its work along the way S10.

Anthropic went next, twice. Opus 5.5 on September 22 made thinking impossible to disable and turned forced tool use into an error S14. Sonnet 5.5 on September 28 followed with five breaking changes of its own: disabled returns a 400 and the lowest setting is now between_tools, forced tool choice returns a 400, thinking blocks are bound to the model and the conversation, the old computer use tool is rejected, and the advisor tool rejects three older advisors S6. Code coming from Sonnet 4.6 or earlier also loses thinking budgets, sampling parameters and assistant prefill, all with 400 errors rather than warnings S7.

OpenAI closed the month. GPT-6.1 Sol arrived at DevDay on September 29, one week after GPT-6 Sol, at the same $2 and $10 prices but with cached input cut in half to $0.10 S1S19. It arrived alone: the GPT-6.1 Astra that had been expected alongside it did not ship, which The Next Web attributes to failed safety tests S19S27. The model page is short and firm: none and minimal reasoning efforts are not supported, tool calling requires the Responses API, and Chat Completions is supported only without tools S3. That matters because GPT-6 Sol, seven days older, still supports none, and still allows function calling on Chat Completions if and only if effort is none S4. One week separated a model you could use as a cheap non-reasoning function caller from one you cannot S18. The migration guide adds the sampling line: when effort is not none, and on 6.1 Sol it never is, remove temperature, top_p and top_logprobs, and on Chat Completions remove logprobs too S2.

FIG. 02 · The same three knobs, removed three ways · error, strip, or endpoint change, per vendor S2S3S6S7S10

Why is "thinking off" gone everywhere at once?

The three vendors give three different reasons, and they add up to one.

Anthropic's is architectural. Every Sonnet 5.5 thinking block is signed over the conversation before it, bound to the model that produced it and to the account that produced it, and the API checks that binding on every replay S6. A model that sometimes does not think is a model whose conversation history sometimes has no signature to check. between_tools is the compromise: no up-front thinking, but the short progress notes the model writes between tool calls still come back as signed thinking blocks, and the setting only works at low, medium and high effort, never at xhigh or max, and never with a per-message effort change S6S7.

OpenAI's is about the endpoint. The Responses API is where persisted reasoning, configuration_update items, async tool calling and mid-turn steering live; Chat Completions has none of them S2. GPT-6 Sol kept a back door open, function calling on Chat Completions with effort none, and GPT-6.1 Sol closed it by removing none S3S4. This is not a new direction so much as the end of one: developers hit the same wall on GPT-5.6 Sol, where the API started rejecting function tools with any non-none effort on Chat Completions, and one of them wrote on OpenAI's own forum that developers should not need to be babysat with denials and that Chat Completions should stay a mainline API S17. Seven months later it is a text-only endpoint for the newest mid-tier model.

Google's is about quality. Its 3.8 Flash page says the model works harder on purpose, and the earlier 3.5 Flash notes explain why minimal was always a soft promise: it matched the no-thinking setting for most queries but did not guarantee thinking was off, and the model could still reason on complex tasks S10S13. Removing minimal on 3.8 Flash turns a setting that sometimes thought into a floor, low, that always does.

Put the three together and the reason is the same. Every one of these models now carries reasoning state between turns, signed or persisted or preserved, and the vendors want that state present on every request so the model can be steered, cached and audited. A request with thinking off is a request with no state to carry. The off switch did not get removed because it was unpopular. It got removed because the thing it switched off became the thing everything else depends on.

What does the effort ladder look like when you line all three up?

This is the figure I wish I had drawn before I tried to write a single effort parameter for three vendors.

FIG. 03 · Effort levels, defaults and the rungs that now return errors · Sonnet 5.5, GPT-6.1 Sol, Gemini 3.8 Flash S2S8S9S10

Read it bottom to top. Sonnet 5.5 has six rungs if you count between_tools, which is not an effort level but a thinking mode that caps effort at high; its API default is high and its Claude Code default is medium S8S9. GPT-6.1 Sol has five rungs, low through max, with none and minimal gone and medium as the default S2S3. Gemini 3.8 Flash has three, low, medium and high, with minimal gone and medium as the default S10.

Two things follow. First, the word medium means three different amounts of thinking. Anthropic says its levels are recalibrated from Sonnet 5 and tells you to re-run your sweep rather than carry a setting over S6. OpenAI says to preserve your current effective effort and to start none users at low and compare S2. Google recommends medium for complex code and agentic use and low for latency-critical work S10. A builder that maps medium to medium across vendors is not mapping anything.

Second, the only rung that exists on all three is the range low to high. Xhigh and max exist on two. between_tools exists on one. If the lowest common denominator is the target, the router's effort type has three values, and everything above high is a vendor-specific escape hatch. That is more honest than it sounds: on Sonnet 5.5, max is the setting where cost per task overtakes Opus 5.5 while scoring lower S24, and OpenAI's own factuality numbers show GPT-6.1 Sol's biggest gain over GPT-6 Sol at low effort, where factual errors dropped from 11.4% to 7.7% S1. The interesting rungs are the cheap ones.

Why is the cache line the one that decides the bill?

List prices first, because two of the three are identical.

FIG. 04 · List prices per million tokens, September 2026, with Gemini's January 1, 2027 column · cache read as a share of input in the last row S3S8S11

Sonnet 5.5 and GPT-6.1 Sol both cost $2 per million input tokens and $10 per million output tokens S8S3. Gemini 3.8 Flash costs $0.75 and $3.75 through December 31, 2026, then $1.50 and $7.50 from January 1, 2027 S11. On input and output alone, Gemini is the cheapest by a wide margin and the other two are a coin flip.

The cache line breaks the tie. A Sonnet 5.5 cache read is $0.20, 10% of input, with a five-minute cache write at $2.50 S8. A GPT-6.1 Sol cache read is $0.10, 5% of input, with cache writes billed at 1.25 times the uncached rate, so also $2.50 S1S3. A Gemini 3.8 Flash context-cache read is $0.075, 10% of its input price, and there is no write price S11. There is a storage price instead: $0.50 per million tokens per hour through December 31, and $1.00 per million tokens per hour after that S11.

That storage line is the number I got wrong first. I put $0.075 in the spreadsheet, called it the cheapest cache on the market, and moved on. It is the cheapest cache read on the market. It is also the only one of the three with a meter running while the cache exists, and the only one that requires you to create and expire the cache yourself; Anthropic and OpenAI charge you to write the cache and then let it sit for five or thirty minutes with no storage line S8S2S11. For a short agentic session that reuses a 150-thousand-token prefix for an hour, the storage comes to about seven cents at introductory pricing and about fifteen after January 1, small next to the read savings. For a fleet of long-lived caches that nobody expires, it is a bill that arrives with no tokens attached. The read price is the headline; the storage price is the footnote you find in December.

Here is the arithmetic on the session shape Anthropic prices in its own cost guide, 2 million cache-read tokens, 200 thousand fresh input tokens and 60 thousand output tokens S15, with Gemini's storage estimated for a 150-thousand-token prefix held for one hour.

FIG. 05 · One illustrative Claude Code session shape priced on four lists · 2M cache reads, 200K fresh input, 60K output, plus Gemini storage for a 150K prefix held one hour S3S8S11S15

Two things in that table surprised me. First, GPT-6.1 Sol undercuts Sonnet 5.5 by 14% on an identical session even though every list price except cache read is identical, and the whole gap is the $0.10 cache read; the Hacker News launch thread saw the same thing and called the cache price the actual big announcement S16. Second, on January 1, Gemini 3.8 Flash at standard pricing lands on exactly $1.20, the same as GPT-6.1 Sol. The cheapest model on the chart becomes a tie in fourteen weeks, and Google publishes the date.

Two caveats travel with the table. The models do not use the same tokens: Google says 3.8 Flash uses more by design S10, and Sonnet 5.5 at max effort used more output tokens per task than any model Artificial Analysis had measured S24. And OpenAI has a surcharge the other two do not: prompts over 272 thousand input tokens are billed at twice the input and cache rates and 1.5 times the output rate for the full request S3. A session that grows past that line stops being $1.20.

FIG. 06 · Gemini 3.8 Flash, introductory versus standard pricing · every line doubles on January 1, 2027, including storage S11

Where do tool calls live now?

The third removed knob is the one that costs the most engineering time, because it is not a parameter. It is an endpoint.

FIG. 07 · Where a tool call has to go on each vendor after September 2026 · one endpoint kept, two endpoints changed S2S3S6S10

Anthropic kept the endpoint and removed the lever. tool_choice of type any or tool returns a 400 on Sonnet 5.5, including on the token-counting endpoint; the replacement is auto with strict: true on the tool so its input matches the schema, plus a sentence in the prompt saying when the tool applies S6S7. Strict tools need additionalProperties: false on every object, a request can carry at most 20 of them, and on Amazon Bedrock strict tools are not available at all, so there you send auto alone and validate the input yourself S7.

OpenAI kept the lever and moved the endpoint. Tool calling on GPT-6.1 Sol requires the Responses API; Chat Completions still works, but only for requests without tools S3. Anyone who used GPT-6 Sol as a cheap function caller on Chat Completions at effort none has a migration to do, and it is not a URL swap: the tool schema, the reasoning items you replay, and the way you change effort mid-conversation all live in different fields on Responses S2S18. A migration guide for Astra warns against moving a Chat Completions tool schema to Responses by changing only the URL, and that warning now applies to the mid-tier too S2.

Google moved the endpoint and the state. The 3.8 Flash checklist standardises multi-turn conversations on a server-side previous_interaction_id through the Interactions API, removes prefilled model turns, and, for anyone still on generateContent, requires every function response to carry a call_id and a name S10. Its notes on pre-tool text warn of Malformed_Function_Call errors when the model writes prose before a call, with a workaround page S10.

The pattern is the same one as the effort ladder. Each vendor is pushing tool calls onto the surface where its reasoning state lives, and off the surfaces where that state cannot be carried. A tool call is no longer a stateless request. It is a turn in a stateful conversation, and the vendors want it on the endpoint that knows the conversation.

What are engineers reporting after day one?

GPT-6.1 Sol is a day old and Sonnet 5.5 is two, so the reports are launch-week reports, and I have weighted the ones that name a breaking change.

The loudest reaction on the OpenAI side was about the cache, not the model. One commenter on the launch thread called the $0.10 cached input the actual big announcement, since a 50% cheaper cache than GPT-6 Sol gets far more mileage in Codex; another reaction, quoted in the same roundup, was relief that GPT-6 Sol is going away, given that its best DeepSWE and OSWorld scores had come in below GPT-5.6 Sol's S16. A third pointed out that ChatGPT plan allowances were cut at the same time, so the best case for Codex subscribers is about 2.5 times cheaper rather than five S26. The speed story is still pending: OpenAI says an Ultrafast tier for 6.1 Sol is coming, at up to 8x its standard generation speed in Codex, and VentureBeat worked the announced multiplier out to roughly $12 and $60 per million tokens if it follows Astra's 6x pricing S1S20.

The quieter reaction is the one that matters for this post. Open-source clients have started filing the migration as a feature request: LibreChat's issue for GPT-6.1 Sol asks to offer low through max, exclude none and minimal, normalise incompatible saved settings when a user switches models, route agent and tool calls through Responses, and strip the sampling parameters that now return errors S22. That is the request builder from this post written as a ticket, and it is a good ticket.

Then there is the gateway problem, which is my second misread. Several gateways document Anthropic's models with the line that reasoning remains opt-in via a reasoning.enabled flag, a claim OpenRouter's Sonnet 5 guide makes and that Sonnet 5.5's own docs now contradict: on the native API, disabled returns a 400, and the only way down is between_tools S23S6. Whether a gateway silently translates enabled: false into between_tools, or silently drops it, or errors, is something each gateway will document on its own schedule. If your requests go through one, the vendor's migration guide is not the only one you have to read.

On the Anthropic side, the day-one reports from my last post still stand: CodeRabbit measured fewer tokens and more issues found per review, GitHub's Copilot team saw fewer steps and tool calls, and the Hacker News thread split between subscribers who no longer see a reason to leave Opus 5.5 and developers who read the cost chart and concluded Sonnet is worse at every point on the curve S24. Nothing in that thread was about between_tools, which tells you how few people run Sonnet with thinking off on purpose. The people who do are the ones running it as a classifier or a formatter at volume, and they are the ones this migration hits.

On the Google side there is a month of use to draw on, and the pattern is the token appetite Google announced up front. The 3.8 Flash page recommends lowering effort for everyday tasks and notes that 3.7 Flash remains fully supported for workflows that prioritise compute efficiency S10. The fact that a vendor keeps the previous Flash alive as the efficient option, three weeks after replacing it, is its own data point.

How would I write one request builder for all three?

No code in this post, so here is the builder as a table. It is the parameter map I would hand to a colleague, and every cell comes from the migration guides.

Three decisions in that table are deliberate.

• The effort type has three values. Quick, default, hard. Each maps to a vendor level, and the map is the thing you re-run when a vendor recalibrates, which all three did this month S2S6S10. Xhigh and max are not in the type; they are a per-vendor override you reach for by hand, for the reasons in the Sonnet post S24.
• Thinking off is not a field. It was a field in August. Keeping it in the builder now means keeping a field that errors on every vendor. between_tools is the closest thing left and it belongs to one vendor, so it lives under the quick effort for Anthropic only.
• Effort changes go through the vendor's cache-preserving path or not at all. On Anthropic, changing the top-level effort between requests invalidates the cache, and per-message effort is the way to keep it S9. On OpenAI, the guide says to keep the request-level effort unchanged and use configuration_update items to preserve the prompt prefix S2. On Gemini I could not find the equivalent, so the builder never changes effort mid-run there. A cache write at 1.25 times input, paid because a router bumped effort, is the most avoidable line on the bill.

One thing the table cannot express is the order of operations for a switch between vendors. Reasoning state does not travel between any of these three; it barely travels between two models from the same vendor S24. A vendor switch is a fresh start with a written summary, not a continuation, and the builder should refuse to append a new vendor's turn to another vendor's history.

What does the side-by-side look like?

Which one should you reach for?

Sonnet 5.5 is the right lane if:

• You already run Claude Code or the Messages API and the task has a spec and a check; the migration from Sonnet 5 is six items long S6.
• You need tool-heavy, latency-sensitive runs with up-front thinking off and can live at high effort or below, which is exactly what between_tools is for S6.
• Your prompts are short: the minimum cacheable prompt dropped to 512 tokens, so system prompts and tool definitions that never cached on Sonnet 5 now do S6S9.

GPT-6.1 Sol is the right lane if:

• Your sessions are cache-heavy: at $0.10 per million cached tokens the same session costs 14% less than on Sonnet 5.5 with every other price identical S1S8.
• You are already on the Responses API. If you are on Chat Completions with tools, budget the migration before the model, not after S3S2.
• You can keep prompts under 272 thousand input tokens, where the surcharge doubles the input and cache rates S3.

Gemini 3.8 Flash is the right lane if:

• You are pricing for the next fourteen weeks, at $0.75 and $3.75, and have a plan for January 1, when every line doubles S11.
• You can manage explicit context caches with a storage meter, creating and expiring them yourself S11.
• Three effort levels are enough, and you have set the lower one for everyday work, because the model spends more tokens by design at the default S10.

None of the three is the fix if:

• Your product depends on thinking being off. That setting no longer exists on any of these models; the older siblings that still allow it, GPT-6 Sol, GPT-6 Luna and Gemini 3.7 Flash, are the honest choice until you re-baseline S2S10.
• Your router changes effort between requests to save money. On two vendors that invalidates the cache unless you use the vendor's specific mechanism, and on the third I could not confirm one S9S2.
• You compare them at defaults. High, medium and medium are three different amounts of thinking, and a comparison at defaults is a comparison of effort levels, not models S8S2S10.

What would I do differently next time?

Three things, in the order I would do them.

First, I would read the pricing page for the storage line before the read line. I found Gemini's $0.075 cache read in a launch article and its $0.50 per million per hour storage price two hours later in the pricing table S11. The read price is what a comparison post prints. The storage price is what a finance team prints.

Second, I would diff the model pages, not the announcements. The single most consequential sentence in this research is on OpenAI's GPT-6 Sol model page, not its GPT-6.1 Sol announcement: Chat Completions supports function calling only with reasoning effort set to none S4. Read next to the 6.1 Sol page, which drops none, that sentence is the migration. The announcement never mentions it.

Third, I would treat a gateway's parameter docs as a second migration guide with its own release schedule. My builder assumed a reasoning.enabled flag existed on Anthropic models because a gateway said so, and the native API disagrees S23S6. When three vendors change their request shape in one month, every abstraction layer between you and them is a place where an August request can still look valid in October.

Sources

1. S1OpenAI, "Introducing GPT-6.1 Sol," September 29, 2026, openai.com
2. S2OpenAI Developers, "Using GPT-6" (GPT-6 family guide and migration quickstart), developers.openai.com
3. S3OpenAI Developers, "GPT-6.1 Sol" model page, developers.openai.com
4. S4OpenAI Developers, "GPT-6 Sol" model page, developers.openai.com
5. S5Anthropic, "Introducing Claude Sonnet 5.5," September 28, 2026, anthropic.com
6. S6Claude Platform Docs, "What's new in Claude Sonnet 5.5," platform.claude.com
7. S7Claude Platform Docs, "Migrating to Claude Sonnet 5.5," platform.claude.com
8. S8Claude Platform Docs, "Claude Sonnet 5.5" model overview, platform.claude.com
9. S9Addy Osmani, "Building with Claude Sonnet 5.5," claude.dev, September 28, 2026, claude.dev
10. S10Google AI for Developers, "What's new in Gemini 3.8 Flash," updated September 23, 2026, ai.google.dev
11. S11Google AI for Developers, "Gemini Developer API pricing," accessed September 30, 2026, ai.google.dev
12. S12Google, "Introducing Gemini 3.8 Flash and 3.8 Flash Cyber," The Keyword, September 2, 2026, blog.google
13. S13Google AI for Developers, "What's new in Gemini 3.5 Flash" (thinking levels and thought preservation), ai.google.dev
14. S14Claude Platform Docs, "What's new in Claude Opus 5.5," platform.claude.com
15. S15Addy Osmani, "What a task costs on Opus 5.5," claude.dev, September 25, 2026, claude.dev
16. S16Jake Handy, "Model Drop: GPT-6.1 Sol," Handy AI, September 29, 2026, handyai.substack.com
17. S17OpenAI Developer Community, "Gpt-5.6 chat completion reasoning effort [bug / behavior change]," 2026, community.openai.com
18. S18DataCamp, "GPT-6.1 Sol: Features, Benchmarks, Pricing, and Access," September 29, 2026, datacamp.com
19. S19TechCrunch, "OpenAI launches GPT-6.1 Sol, says it nearly matches GPT-6 Astra and costs less," September 29, 2026, techcrunch.com
20. S20VentureBeat, "OpenAI's GPT-6.1 Sol offers Astra-like performance at 1/5th price. A new Ultrafast tier clocks at 300 tokens per second," September 29, 2026, venturebeat.com
21. S21Thurrott, "Google Releases Gemini 3.8 Flash and Cyber Variant," September 2, 2026, thurrott.com
22. S22LibreChat, issue #16527, "Add GPT-6.1 Sol (gpt-6.1-sol) support," September 29, 2026, github.com
23. S23OpenRouter, "Claude 5 Sonnet Migration Guide" (gateway parameter mapping), openrouter.ai
24. S24Syed Moinuddin, "Not a Ladder, a Fork: What I Learned Researching Claude Sonnet 5.5 vs Opus 5.5," September 29, 2026, syedmoinuddin.com
25. S25Syed Moinuddin, "Not a Winner, a Routing Rule: What I Learned Researching Claude Opus 5.5 vs Fable 5.1," September 27, 2026, syedmoinuddin.com
26. S26eesel AI, "GPT-6.1 Sol: what's new, pricing, and when it beats Astra," September 30, 2026, eesel.ai
27. S27The Next Web, "OpenAI releases GPT-6.1 Sol at a fifth of GPT-6 Astra's token prices," September 29, 2026, thenextweb.com

---

Written by

Syed Moinuddin

Full Stack Engineer.

Notes on AI tooling, agentic systems, and building things that survive contact with production.