A team does not need the same model to label a support ticket and investigate a broken revenue pipeline. Treating both jobs alike wastes money in one direction and invites mistakes in the other. GPT‑6.1 Sol’s launch is a good reason to examine that split.
What changed on September 29
OpenAI introduced GPT‑6.1 Sol on September 29, 2026. Its standard API prices are $2 per million input tokens, $0.10 per million cached input tokens and $10 per million output tokens. The API model identifier is gpt-6.1-sol. At announcement, availability included ChatGPT Work and Codex for eligible paid plans; OpenAI said it was not yet available in Chat. The company reports performance close to Astra on selected coding, computer-use and professional-work benchmarks. Those benchmark results are vendor-reported and should not be read as a guarantee for a particular business workflow. OpenAI’s release announcement.
Route by consequence, not by prestige
My analysis starts with a task inventory. Some requests have a cheap, objective check: extracting a date into a fixed schema, for example. Others require interpretation, multiple sources or a defensible explanation of why a number changed.
For the first group, validate the output automatically and escalate only when validation fails. For the second, define the evidence the model must provide and keep human approval where the result informs a consequential decision. A model’s name should not determine the approval policy.
A useful routing rule considers ambiguity, required context and the consequence of an incorrect answer. It should also have an escape hatch. If the input is outside the expected shape, reject or escalate it instead of letting a low-cost route invent an answer.
Avoid making the routing system itself more expensive than the work it saves. Start with explicit categories and a small number of branches. A complicated classifier is difficult to explain when an important request takes the wrong path.
Cached context needs a boundary
The difference between input and cached-input prices makes repeated context worth examining. Stable instructions, a versioned metric glossary and a fixed output schema are candidates for reuse. A changing dataset or a user-specific document should not be treated as interchangeable context.
Before pursuing savings, decide what information belongs in the request at all. Prefer a compact, relevant slice of data over dumping a warehouse export into a prompt. Keep access controls outside the model; an instruction to ignore private fields is not a substitute for withholding them.
Cache behavior and eligibility depend on implementation. Measure actual billed usage instead of assuming every repeated token qualifies. A cache-friendly design should remain correct when there is no cache hit.
Compare accepted outputs, not attractive invoices
For a hypothetical monthly variance report, track failed drafts, repair requests and reviewer time alongside token spend. Require every numerical claim to reconcile to a supplied table. Ask the reviewer to mark unsupported explanations, even when they sound reasonable.
Run the new route beside the existing one on historical inputs. Do not silently replace the production path after a few good examples. Look for disagreement on the awkward cases and decide which errors are tolerable.
Claude Sonnet 5.5’s efficiency announcement points to the same operational question. The winning model is the one that completes a defined job at an acceptable total cost, with failures you can detect.
Reported facts reflect the September 29, 2026 announcement. Routing examples are proposed engineering practices, not a claim that these models were tested for this article.