OpenAI’s GPT-6.1 Sol arrives with a familiar promise—more capability for less money—but the important change is not simply a better point on a benchmark chart. For teams building agents, the model changes the economics of repeated execution. An agent does not answer one prompt and stop. It reads state, calls tools, observes results, revises a plan, and often carries a large working context across many steps. Every loop adds latency and cost, while every failure can force a partial or complete retry.
GPT-6.1 Sol is designed for that operating pattern. OpenAI says it approaches the intelligence of its flagship GPT-6 Astra on agentic coding, computer use, and professional work while charging one-fifth of Astra’s standard input and output token prices. Its API pricing is $2 per million input tokens, $0.10 per million cached input tokens, and $10 per million output tokens. The cached-input rate is especially consequential: it makes stable instructions, repository context, schemas, and other repeated prefixes cheap enough to preserve across long-running workflows rather than aggressively trimming them after every turn.
The central takeaway is straightforward: GPT-6.1 Sol gives agent builders more room to optimize for successful task completion instead of minimizing every model call. That does not eliminate the need for routing, budgets, or safeguards. It does shift where those controls should be applied.
A model aimed at the agent loop
GPT-6.1 Sol accepts text and image input, produces text, and exposes a 1.05-million-token context window with up to 922,000 input tokens and 128,000 output tokens. It supports five reasoning-effort levels—low, medium, high, xhigh, and max—so applications can vary how much computation they spend according to task difficulty. Tool calling requires OpenAI’s Responses API.
The supported tool set covers the major components of a production agent: web and file search, code execution, hosted shell, patch application, computer use, Model Context Protocol connections, skills, and tool discovery. Structured outputs and function calling are supported as well. Taken together, these features position the model as an execution engine rather than a chat-only endpoint.
That distinction matters because agent performance is a system property. A capable model can still fail when a harness provides stale observations, ambiguous tool descriptions, excessive privileges, or no recovery path after a partial action. Conversely, a well-instrumented agent can use a less expensive model effectively by escalating only the difficult steps. GPT-6.1 Sol’s combination of tool support, variable reasoning effort, and lower token prices gives engineering teams a wider design space for that system-level optimization.
The cached-input price is the sleeper feature
OpenAI prices cached GPT-6.1 Sol input at five percent of the uncached input rate. This is not just a discount for conventional prompt reuse. It directly targets one of the most expensive parts of agent workloads: repeatedly sending the same large body of context while only the latest observation changes.
Consider a software-engineering agent working through a repository. Its repeated prefix may include system policies, tool contracts, coding standards, a project map, dependency information, and selected source files. A business-process agent may carry workflow rules, customer constraints, data schemas, and a detailed audit trail. In both cases, repeatedly rebuilding a tiny prompt can save tokens while causing the agent to forget important constraints. Cheap cached input makes the safer option—retaining stable context—more affordable.
There are limits. Prompts above 272,000 input tokens receive long-context pricing: OpenAI says input and cache rates double, while output pricing rises by 50 percent for the full request. Cache writes cost $2.50 per million tokens, or 1.25 times the uncached input rate. These rules reward deliberate prefix design. Teams should separate stable material that is likely to hit the cache from volatile observations that change on every step. A million-token window is capacity, not a recommendation to fill it indiscriminately.
Design the context as an asset
The practical architecture is a layered prompt. Put durable policy, tool definitions, and stable reference material first. Follow them with task-specific state, then append the newest tool result or user instruction. This arrangement improves the chance that the costly stable prefix can be reused while allowing the active tail to evolve.
Teams should measure cache-hit rate alongside token volume. A low hit rate may indicate that timestamps, random identifiers, reordered tool definitions, or other unnecessary changes are invalidating the prefix. The right metric is not merely average input cost. It is the cost of the context required to complete a task correctly.
Benchmarks suggest a new default tier, not a universal winner
OpenAI reports that GPT-6.1 Sol matches GPT-6 Astra on DeepSWE v1.1 at roughly one-fifth the cost and improves on GPT-6 Sol’s best score by 6.4 percentage points. On AutomationBench, it is reported to score 4.8 percentage points above GPT-6 Sol at the same medium reasoning setting. On the offline portion of OSWorld 2.0, it improves by seven percentage points over GPT-6 Sol at maximum reasoning effort while costing less than half as much.
Those results are relevant because they evaluate the kinds of multi-step work agents perform: modifying real codebases, navigating applications, and completing business workflows. They also remain vendor-reported measurements. Teams should treat them as a reason to test, not as a substitute for evaluation on their own repositories, applications, permission boundaries, and failure costs.
The model does not displace Astra everywhere. OpenAI’s own Terminal-Bench Science result gives Astra the highest score among the tested models, while Sol is substantially cheaper per task. That points to a sensible portfolio: use Sol as the default execution tier, then route unusually difficult, high-value, or repeatedly failing work to Astra. The decision should be based on expected task value and completion probability, not on a single per-token ranking.
Reasoning effort becomes a runtime control
Five reasoning-effort settings make model selection only one part of the cost equation. An agent can begin with low or medium effort for routine classification, retrieval, and well-specified tool calls, then increase effort when it encounters ambiguity, conflicting evidence, or a failed verification. This is a more granular control than switching models for every step.
A useful policy is to escalate on evidence rather than intuition. Triggers might include a failed test suite, a tool response that contradicts the plan, an inability to produce a schema-valid result, or two unsuccessful attempts at the same action. The harness should record why an escalation happened and whether it improved the outcome. Without that feedback loop, higher reasoning settings can become an expensive default rather than a targeted intervention.
Latency modes add another dimension. OpenAI documents Fast at twice standard prices and Ultrafast at six times standard, with Batch and Flex at half the standard rate. This lets teams separate interactive steps, where a human is waiting, from asynchronous work such as background analysis or bulk verification. A production router can therefore choose across model, reasoning effort, and service speed—not just model name.
What agent teams should change now
Adopting GPT-6.1 Sol should be an evaluation project, not a string replacement. The model is available through the API as gpt-6.1-sol, and tool calling depends on the Responses API. Teams moving from older chat-style integrations need to validate the execution loop as well as prompts.
- Benchmark complete tasks. Track completion rate, human correction time, tool-call count, retry count, wall-clock latency, and total cost. Per-token price alone hides expensive loops.
- Test at multiple reasoning levels. Find the cheapest setting that reliably handles each task class, then define explicit escalation conditions.
- Structure prompts for caching. Keep stable instructions and tool contracts in a consistent prefix. Move timestamps and changing observations toward the end.
- Recheck long-context economics. Requests above 272,000 input tokens have higher rates. Retrieval and summarization may still beat carrying an entire corpus.
- Validate tool behavior under failure. Simulate unavailable search, malformed tool output, revoked permissions, and interrupted computer-use sessions.
- Keep an escalation model. Route the rare cases that exceed Sol’s reliable envelope to Astra or to a human reviewer.
Safety testing deserves equal weight. OpenAI says GPT-6.1 Sol improves on its predecessor in respecting explicit restrictions, acknowledging broken search tools, and avoiding unauthorized outcomes in agentic tasks. Those are useful properties, but an application still needs least-privilege tools, action-level authorization, idempotency controls, and durable logs. A model’s refusal behavior is one layer of defense, not the boundary protecting production systems.
The bigger shift is from model cost to outcome cost
For single-turn applications, token prices provide a reasonable first-order estimate. For agents, they do not. The relevant unit is the completed task. A cheap model that retries five times can cost more than a stronger one that succeeds once. A fast model that makes an unauthorized change can create remediation costs that dwarf inference spending. A large context window can improve continuity, but only if the agent can identify which details matter.
GPT-6.1 Sol pushes the market toward that outcome-based accounting. Its pricing lowers the penalty for persistent context and multi-step reasoning, while its reported performance narrows the gap between an everyday model and the flagship tier. This makes it practical to reserve the most expensive model for genuinely exceptional cases instead of using it as insurance on every call.
The teams that benefit most will not be those that simply send more tokens. They will be those that pair cheaper repeated context with strong routing, task-level evaluations, and tool-level controls. Sol offers a larger operating envelope for agents. Engineering discipline determines whether that envelope produces more completed work or merely longer loops.
