On September 29, OpenAI introduced GPT-6.1 Sol, replacing GPT-6 Sol just seven days after its release.

The announcement makes an ambitious claim: near-GPT-6 Astra performance at one-fifth of Astra's standard input and output token prices.

Independent evaluations from Artificial Analysis suggest the performance gap is indeed narrow. GPT-6.1 Sol landed just one point behind Astra on the Intelligence Index, while costing less than a quarter as much per evaluated task at maximum reasoning effort.

That's an interesting result for developers building production AI systems.

Until recently, selecting a model for a difficult agentic workflow often meant choosing between a flagship model with expensive reasoning and a smaller model that struggled with complex tasks.

GPT-6.1 Sol offers another option.

But the real question isn't whether Sol is cheaper than Astra. It's whether the difference is large enough to change how we should architect, evaluate, and operate AI agents.

What changed with GPT-6.1 Sol?

GPT-6.1 Sol is a reasoning model designed for software engineering, computer use, professional knowledge work, and multi-step agent workflows.

OpenAI reports improvements over GPT-6 Sol in coding, document understanding, computer-use tasks, and factual accuracy.

The model is available through the OpenAI API as gpt-6.1-sol, including the Responses API.

Its standard pricing is:

Source: OpenAI, Introducing GPT-6.1 Sol.

These are standard rates for prompts within the applicable pricing threshold. Longer prompts, additional services, and other processing tiers can change the bill.

There are two improvements worth separating.

First, the model's capabilities improved. OpenAI reports better performance across complex workflows without moving Sol into Astra's pricing tier.

Second, cached input became cheaper.

GPT-6 Sol offered a 90% discount on cached input relative to its standard input rate. GPT-6.1 Sol increases that discount to 95%.

For agents repeatedly processing the same system instructions, repository context, tool definitions, or reference material, prompt caching can materially reduce input costs.

However, a lower token price alone doesn't tell us whether an agent completes its task efficiently.

Independent benchmarks: how close is Sol to Astra?

Artificial Analysis published its evaluation on September 29, using Intelligence Index version 4.3.2.

Its results place GPT-6.1 Sol one point behind GPT-6 Astra at maximum reasoning effort.

The cost comparison is more striking.

Source: Artificial Analysis, September 29, 2026.

These figures are measured averages across Artificial Analysis's evaluation workload. They are not estimates for an ordinary chat request or a guaranteed cost for a customer application.

Still, they reveal an interesting result.

GPT-6.1 Sol improves the Intelligence Index by four points over GPT-6 Sol while reducing the measured cost per task by approximately 31%.

That is a meaningful combination: better measured performance and lower total task expenditure.

Artificial Analysis also reports:

• A 12-point improvement on Terminal-Bench 4.0.
• A five-point improvement on Humanity's Last Exam.
• A six-point improvement on GDP.pdf, which tests reasoning over professional documents.
• An eight-point improvement in AA-Omniscience accuracy, accompanied by a reduction in the benchmark's hallucination rate from 60% to 54%.

These improvements use the independent evaluator's own benchmark configurations.

The hallucination figures should not be interpreted as everyday application error rates. They measure behavior on a deliberately difficult test set.

An interesting result from the coding evaluation

Artificial Analysis found that GPT-6.1 Sol at xhigh reasoning effort outperformed its own max effort configuration by three points on the Coding Agent Index.

That is a useful reminder that maximum reasoning effort doesn't always produce the best outcome.

Agent performance depends on how the model spends its computation, which tools it uses, and how it interacts with the execution environment.

Increasing reasoning effort can improve some tasks while introducing additional cost or ineffective exploration in others.

For engineering teams, the appropriate effort level should be determined through testing rather than simply selecting the most expensive setting.

What OpenAI's own benchmarks tell us

OpenAI reports that GPT-6.1 Sol matches Astra on DeepSWE v1.1 at approximately one-fifth of the cost.

DeepSWE measures software engineering performance on difficult, long-running tasks in real codebases.

OpenAI also reports that GPT-6.1 Sol exceeds GPT-6 Sol by seven percentage points on the offline subset of OSWorld 2.0 at maximum reasoning effort.

OSWorld tests whether agents can complete computer-use workflows through software interfaces.

These are useful indicators, but they are vendor-reported evaluations.

Differences in agent harnesses, tool availability, prompts, and reasoning settings can change results.

For a production application, I would want to reproduce the comparison using my own workflow before making a migration decision.

The cost question: tokens versus successful outcomes

Consider an AI agent that processes 80,000 uncached input tokens and generates 10,000 output tokens to complete a task.

At standard token rates, the hypothetical cost would be:

Sol is five times cheaper in this example.

But now consider the entire workflow.

Suppose the agent searches a knowledge base, invokes multiple tools, asks for clarification, retries a failed operation, and produces a final answer that requires additional verification.

The total cost includes every model call made during that sequence.

A cheaper model might need more calls to reach a correct outcome. A more expensive model might complete the same task in fewer steps.

Or the cheaper model might be better at handling the task and reduce both cost and latency.

Without measuring the completed workflow, we can't determine which outcome applies.

I prefer measuring cost per accepted result, alongside accuracy, latency, and failure rates.

For a coding agent, that might mean the cost of producing a change that passes tests and review.

For a RAG system, it might mean the cost of answering a question correctly with supporting evidence.

For an enterprise workflow, it might mean the cost of completing an authorized business operation without requiring a manual correction.

Those are more useful economic units than the price of a million tokens.

What I learned from optimizing an enterprise agent platform

I encountered this question while working on Auto-RAG and MerlinX at DXWand.

Auto-RAG was a retrieval platform I architected and initially built for enterprise customers, including Gulf-region government ministries. MerlinX extended the retrieval system into an agentic conversational platform supporting tool calls and multi-step workflows.

During a cost investigation, I identified the orchestration model as responsible for approximately 75% of the workflow's model expenditure.

That made it an obvious candidate for optimization.

But switching to a cheaper model without testing would have put answer quality at risk across multiple customers.

I evaluated the replacement using a frozen test suite and a comparison at 95% confidence, then rolled it out with controls and a rollback path.

The result was a 73% reduction in cost per conversation across 840 agents, with no measurable quality loss in the evaluation.

The specific models involved were different from GPT-6.1 Sol. The lesson applies to any model release.

Benchmark results can identify promising replacements. The application's own evaluations should determine whether a change is safe.

A fivefold difference in token price is an opportunity to test, not a guaranteed fivefold saving.

GPT-6.1 Sol also arrives alongside changes to agent development

The September 29 announcements weren't limited to a new model.

OpenAI also expanded its Agents API, originally introduced in public beta on September 10.

Two capabilities deserve attention.

Multi-agent delegation

GPT-6.1 Sol supports multi-agent operation in beta through the Responses API, allowing work to be delegated to subagents.

This creates opportunities for dividing complex work into bounded tasks.

For example, a software engineering agent might delegate test discovery, dependency analysis, and documentation inspection while retaining responsibility for the final proposed changes.

But delegation has costs.

Subagents consume additional tokens and execution resources. They can also return conflicting conclusions or repeat work unnecessarily.

Parallelism should be measured against the overhead of coordination.

Hosted computer use

On September 29, OpenAI added computer-use functionality to the Agents API.

Agents can operate software through an OpenAI-hosted browser, with website-access approvals and sign-in handled through the integrating application.

This is useful when a workflow cannot be completed through conventional APIs.

However, computer-use agents require careful permission design.

An agent that can click buttons, submit forms, and change settings has a different risk profile from one that only reads documents.

The application should explicitly control which actions are permitted, which require approval, and how outcomes are recorded.

A better model reduces some execution errors, but authorization and accountability still belong to the surrounding system.

How I would evaluate GPT-6.1 Sol for production

For an existing AI application, I'd run a controlled comparison against its current model.

My evaluation would cover the following areas.

I'd also test more than one reasoning effort.

The evaluation should use identical business tasks, expected outcomes, and permission boundaries, while documenting any model-specific configuration changes.

For workflows involving data access, I would test failures deliberately: denied permissions, stale records, empty search results, unavailable tools, and contradictory information.

A model that succeeds on ordinary cases but mishandles those situations may be unsuitable for deployment.

Finally, I would introduce the replacement gradually, monitor behavior, and keep a rollback path.

Should production systems migrate to GPT-6.1 Sol?

GPT-6.1 Sol looks like a serious candidate for applications currently using expensive reasoning models.

Its independent benchmark results show performance approaching Astra at substantially lower measured task cost.

The improved cached-input pricing makes it attractive for agents that reuse large prompts or tool definitions.

But the decision depends on what the application actually needs.

An enterprise agent handling regulated data may have different acceptance criteria from a coding assistant or an internal document summarizer.

I would start by identifying the most expensive workflow stages, testing Sol against representative cases, and measuring the impact on completed outcomes.

If it meets the existing acceptance criteria at a lower cost, the case for adoption is straightforward.

If it doesn't, the current model should remain in place until the trade-off becomes acceptable.

The model leaderboard can tell us where to look. Production evaluations tell us what to deploy.

Sources

• OpenAI, Introducing GPT-6.1 Sol, September 29, 2026
• Artificial Analysis, Independent GPT-6.1 Sol evaluation, September 29, 2026
• OpenAI, API changelog
• OpenAI, Introducing the Agents API, September 10, 2026

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise agentic AI, production RAG systems, cloud platforms, and model evaluation.