Does GPT-6.1 Sol make AI work cheaper? Count successful tasks, not just tokens
OpenAI's 29 September release reports stronger performance at lower task costs in selected evaluations. The useful comparison for buyers is the cost of checked, completed work in their own setting.
The short version
- What happened
- Selected vendor tests suggest improved capability; local total-cost testing is still needed.
- Who it affects
- Staff time spent correcting results belongs in any claimed productivity saving.
- What remains unproven
- The launch's selected factuality comparison does not report its sample size beside the headline.
Keep in mind
The launch's selected factuality comparison does not report its sample size beside the headline.
Research settings and production systems can behave differently.
Source analysis · 2 linked sources. Primary analysed source date: 29 September 2026.
Read the full report · 4 min The evidence, methods, implications and limitations
What OpenAI released
OpenAI announced GPT-6.1 Sol on 29 September 2026 for ChatGPT Work, Codex and its API. The launch reports improvements on software, professional-document and computer-use evaluations. Standard API pricing is listed at $2 per million input tokens, $0.10 for cached input and $10 for output. Those prices describe consumption, not the complete cost of delivering a business result.
One concrete comparison concerns factual errors on deliberately difficult conversations selected because users had flagged an earlier model's mistake. At low reasoning effort, OpenAI reports a reduction from 11.4% for GPT-6 Sol to 7.7% for GPT-6.1 Sol. The denominator is evaluated answers in that selected test, not all everyday user queries. The launch does not supply the sample size alongside that headline comparison. These results are vendor-reported and should not be presented as an independently measured error rate for ordinary work.[1]
What the safety documentation adds
The accompanying system-card addendum is also dated 29 September. OpenAI classifies the model as Critical for cybersecurity capability and High for biological and chemical capability under its own framework, applying the GPT-6 Astra safeguards stack. Those labels concern assessed capability; they are not probabilities of a harmful event. The document warns that research or API evaluations may differ from production behaviour because prompts, tools and reasoning settings differ.
Our assessment is that performance and permissions should be evaluated together. A system that finishes more tasks can still create avoidable costs if its output requires correction, if it acts beyond scope or if it does not disclose a failed information search. A business choosing a cheaper model should therefore retain the checks appropriate to the action. Price does not establish trustworthiness, and a model upgrade does not automatically validate the workflow around it.[2]
How to compare the cost of useful work
For a document-processing pilot, a team could select a representative batch before seeing either model's answers. Include awkward tables, missing attachments and questions that cannot be answered from the documents. Define which mistakes would make a result unusable. Then record accepted outputs, human review minutes, retries and escalations. The relevant denominator is the number of correctly completed cases. Counting all attempted cases as productivity would reward a system for generating work that somebody must redo.
The comparison should also keep task difficulty and tool access consistent. If one configuration can use a search service or a larger context window while another cannot, the experiment is comparing systems rather than only models. That can be a legitimate purchasing question, but it should be described honestly. Record the configuration and date, because changing a prompt or enabling an additional tool may alter the result more than a headline model ranking suggests.
Why the conclusion remains local
For staff, a lower operating cost could make assistance available for more routine tasks. It could also encourage organisations to process more work without increasing the capacity to review exceptions. Our recommendation is to set a review budget before expanding volume, and to preserve a route for workers to challenge an apparently confident answer. Those organisational choices determine whether cheaper inference reduces effort or creates a larger checking queue.
The launch is relevant internationally, but document languages, local terminology and professional rules vary. A result on a shared benchmark cannot establish equivalent performance on every country's records. Our assessment would change with independent, reproducible comparisons that include total cost and consequential errors across those settings. Buyers can already test a bounded workflow, but should report their own sample and acceptance criteria rather than borrowing a vendor's percentage as a guarantee.