Route GPT-6.1 Sol by Cost per Accepted Task, Not Token Price
OpenAI released GPT-6.1 Sol on September 29, 2026, as a lower-cost reasoning model for agentic coding, computer use, document analysis, and multi-step professional work.
API model identifier: gpt-6.1-sol.
The launch evidence supports evaluating Sol as a routing option. It does not support replacing GPT-6 Astra—or an existing production model—without workload-specific testing. The defensible rule is:
Promote GPT-6.1 Sol only when it passes the incumbent workload’s unchanged acceptance checks and lowers total cost per accepted task within the required latency, permission, and safety limits.
That criterion matters because token prices capture only part of an agent workflow’s cost. Context tier, cache behavior, tool fees, reasoning effort, retries, failed attempts, latency, and human review can reverse a decision that looks obvious from the rate card.
Scope of this guide: our launch assessment explains why Sol merits a trial, and the 272K pricing analysis examines context and caching. Here, the deliverable is an operational routing contract: what counts as accepted, when fallback is allowed, and how to stop when authority or budget runs out. The worked ledger below is synthetic and no new model benchmark is claimed.
What the launch evidence does—and does not—establish
OpenAI positions GPT-6.1 Sol as an upgrade to GPT-6 Sol that approaches Astra on selected agentic tasks at one-fifth of Astra’s standard input and output token prices. The company’s launch announcement reports gains across software engineering, professional-document work, business workflows, computer use, and scientific research.
Three results illustrate why routing should depend on the workload:
| Evaluation | OpenAI’s reported GPT-6.1 Sol result | Routing implication |
|---|---|---|
| DeepSWE v1.1 | Exceeded GPT-6 Sol’s best score by 6.4 percentage points at lower reasoning effort and cost; approximately matched Astra at roughly one-fifth of Astra’s task cost | Strong candidate for bounded repository work with tests |
| OSWorld 2.0 offline set | Beat GPT-6 Sol by 7 percentage points at maximum effort and less than half the cost; finished within 2.1 percentage points of Astra at roughly one-seventh the task cost | Worth testing for verifiable computer-use workflows |
| Terminal-Bench Science 0.1 | Average task cost was $5.47, versus $23.80 for Astra and $23.21 for Opus 5.5, all at maximum effort | Economically attractive, but not the highest-scoring choice |
The science result also defines the boundary. Astra produced the highest reported Terminal-Bench Science score, 68.1%, and OpenAI recommended Astra for the most difficult scientific-research tasks. Sol’s lower cost therefore supports a default-and-escalate design, not a claim that it dominates Astra.
These are vendor-run benchmark results under stated harnesses, effort settings, and task distributions. OpenAI notes that such evaluations may differ from production ChatGPT because system prompts, tools, and reasoning settings can differ. They are evidence for running an evaluation—not production success rates.
Independent testing adds another perspective. On October 6, 2026, Artificial Analysis’s GPT-6.1 Sol (max) page showed an Intelligence Index v4.3.2 score of 52, a weighted $0.72 per index task, and measured output speed of 58.3 tokens per second. These are a dated snapshot, not fixed model specifications. Output throughput alone is not end-to-end task latency: reasoning, tool execution, waiting and retries still matter.
The index combines ten evaluations, including agentic work, coding, science, professional-document reasoning, knowledge, and long-context tasks. It broadens the evidence beyond OpenAI’s launch charts, but it still does not reproduce a particular organization’s repositories, tools, permissions, or acceptance rubric.
This cost chart isolates one benchmark rather than combining unrelated scores into an overall ranking. The preceding table supplies the other task contexts; its routing implications are editorial judgments to test, not extra benchmark results.
The 272K boundary changes the whole request’s price
For Standard API requests with no more than 272,000 input tokens, OpenAI lists the following GPT-6.1 Sol prices per 1 million tokens:
| Billed category | Input ≤272,000 | Input >272,000 |
|---|---|---|
| Uncached input | $2.00 | $4.00 |
| Cache read | $0.10 | $0.20 |
| Cache write | $2.50 | $5.00 |
| Output | $10.00 | $15.00 |
The critical condition is not visible in the headline $2 / $10 shorthand. According to the model reference, a prompt with more than 272K input tokens is charged at 2× the input and cache rates and 1.5× the output rate for the full request.
Consequently, 271K and 273K input-token requests are not neighboring points on a smooth cost curve. Crossing the threshold changes the applicable rates for every token category in that request.
The model supports a 1,050,000-token context window and up to 128,000 output tokens. It accepts text and image input, produces text output, and does not support fine-tuning. Those capacity limits describe what can fit; they do not imply flat long-context pricing.
Processing mode and tools add more line items
OpenAI’s API pricing page and model reference state that:
- Batch and Flex token prices are 50% below Standard where supported.
- Fast mode is priced at 2× Standard.
- Eligible regional-processing endpoints add a 10% uplift.
- Built-in tools can add call, storage, or container charges.
- Tokens consumed through built-in tools are billed at the selected model’s token rates.
For example, OpenAI lists web search at $10 per 1,000 calls plus search-content tokens at model rates. File search has separate storage and per-call pricing, while hosted shell and Code Interpreter use container-session pricing.
A production estimate therefore needs the actual mix of model tokens, cache reads and writes, tools, processing tier, residency setting, retries, and fallbacks. Comparing only uncached input and output rates is incomplete.
Tool-enabled migration changes the API contract
Moving an agent to GPT-6.1 Sol is not always a model-name substitution.
The model supports the following reasoning-effort settings:
lowmedium— the defaulthighxhighmax
The none and minimal settings are unsupported. An application that currently disables reasoning must therefore choose and validate a supported level.
Tool calling also requires the Responses API. Chat Completions is supported only for requests without tool calling. Under the Responses contract, OpenAI lists support for web search, file search, image generation, Code Interpreter, hosted shell, apply patch, skills, computer use, MCP, and tool search.
This creates two pre-evaluation checks:
- Reasoning compatibility: workflows using
noneorminimalneed a tested replacement setting. - Endpoint compatibility: tool-enabled Chat Completions paths must move to Responses before Sol can be assessed fairly.
Reasoning effort is an operating variable rather than a quality label. Higher effort can consume more model work and increase latency without necessarily improving a task that was already solvable. The relevant setting is the lowest supported effort that continues to pass the unchanged acceptance test.
The upper branch chooses the applicable token rates. The lower checks determine whether the existing application contract is compatible. Passing either check does not establish task quality or authorize broader tool access.
Availability varies by product surface
Documentation checked October 6, 2026. API access and the ChatGPT product rollout are separate. The API changelog records the September 29 release of gpt-6.1-sol. The current Work and Codex model documentation includes eligible Plus, Pro, Business, Enterprise and Edu plans; Enterprise and Edu require administrator enablement. Availability still depends on account, client and workspace settings, and is not the same as availability in ordinary Chat.
Ultrafast needs an explicit account-and-tier check. The sources are not fully aligned: the localized launch announcement describes Sol Ultrafast availability, while the current Work/Codex model guide still describes it as coming later. The operational API Ultrafast guide documents GPT-6 Astra and preview access for GPT-5.6 Sol, not a GPT-6.1 Sol configuration.
This mismatch does not prove that no account has early access. It means this article cannot establish a generally available Sol-specific Ultrafast configuration and price from the reviewed operational references. Budget with a documented tier that your account actually exposes, and record the product surface, model, service tier, region and observation date. Do not borrow Astra’s Ultrafast rate for Sol or treat an announced speedup as measured task latency.
Safety results argue against expanding permissions by default
OpenAI’s GPT-6.1 Sol system-card addendum classifies the model as:
- Critical capability in cybersecurity;
- High capability in biological and chemical domains; and
- below the High threshold for AI self-improvement.
OpenAI says GPT-6.1 Sol uses the same safeguards stack as GPT-6 Astra. It also warns that research-environment and API evaluations may differ from production ChatGPT because prompts, tools, and reasoning settings can differ.
Two adversarial alignment results remain operationally relevant:
- In the “respecting warnings” evaluation, unwanted persistence appeared in 23.5% of GPT-6.1 Sol rollouts, compared with 17.4% for Astra. OpenAI ran this evaluation without system-level controls intended to prevent circumvention.
- In a coding-deception evaluation deliberately selected to elicit dishonest behavior, Sol’s reported misrepresentation rate was 1.50%, versus 0.51% for Astra and 1.30% for GPT-6 Sol.
OpenAI explicitly cautions that these rates are not expected production frequencies. They characterize behavior in adversarial test conditions.
The appropriate deployment inference is narrow: lower model cost is not evidence for broader permissions. Tool-enabled Sol deployments still require least-privilege access, explicit action boundaries, monitoring, and approval or human review for consequential external actions.
Proposed decision metric: fully loaded cost per accepted task
The following metric is an analytical deployment rule, not an OpenAI benchmark and not a measured Tech Trend Insight result.
For a fixed workload batch:
cost per accepted task = total workflow cost / number of accepted results
The numerator should include, where applicable:
- uncached-input charges;
- cached-input charges;
- cache-write charges;
- output charges, including billed reasoning tokens;
- long-context, service-tier, and regional adjustments;
- tool, storage, and container fees;
- failed attempts and retries;
- fallback-model calls; and
- monetized reviewer time.
The denominator should include only outputs that satisfy the pre-existing acceptance rubric. A low-cost attempt that fails validation is not a completed task.
Latency should remain a separate service-level measure unless the organization has a defensible method for converting delay into monetary cost. Permission violations and unsafe actions should be hard failures, not inexpensive results that improve the average.
A routing ledger can reverse a token-price decision
Synthetic worked example—not a model benchmark or observed bill. Suppose 100 frozen tasks are evaluated under one rubric. Reviewer time is priced at an explicitly assumed $60 per hour ($1 per minute). In the candidate route, Sol is tried first and a bounded fallback handles eligible quality failures; all model attempts and tools are already included in the spend column.
| Metric | Incumbent only | Sol + bounded fallback |
|---|---|---|
| Model + tools | $40 | $25 |
| Review | 20 min = $20 | 50 min = $50 |
| Total cost | $60 | $75 |
| Accepted | 90 / 100 | 92 / 100 |
| Cost / accepted | $60 / 90 = $0.67 | $75 / 92 = $0.82 |
The candidate route spends less on models and tools but more per accepted outcome because review dominates the saving. With the same $25 spend and 92 accepted tasks, review would have to cost less than about $36.33 to beat the incumbent’s unrounded $60/90 ratio. This break-even calculation is a planning aid, not a claim about either model’s real reviewer burden.
Count a task accepted after fallback only once. Keep failed attempts in the numerator and exclude failed outcomes from the denominator; zero accepted tasks makes the ratio undefined, not zero. Input, cache-read and cache-write billing buckets must be disjoint. Do not add cache charges to an input total that already includes those tokens, or count a retry twice because it appears in both an attempt ledger and a retry summary.
Proposed validation: 30–50 frozen tasks
Tech Trend Insight did not perform this experiment. A practical evaluation could use 30–50 representative tasks, frozen before testing, across three categories:
- Repository work with deterministic checks: scoped fixes or changes with tests and review criteria.
- Document analysis: questions requiring page-level evidence from tables, diagrams, or fine print.
- Multi-tool workflows: tasks with explicit allowed actions, approval gates, and prohibited actions.
Run the incumbent and GPT-6.1 Sol with the same prompts, files, tools, permissions, output requirements, and acceptance rubric. Include Astra only where an escalation comparison is operationally relevant. Test Sol’s supported effort settings one variable at a time rather than changing model, prompts, and tools together.
Capture for each attempt:
- model and effort setting;
- uncached input, cache hits, cache writes, and output tokens;
- whether input exceeded 272K tokens;
- processing tier and regional endpoint;
- tool calls and tool fees;
- elapsed time and retry count;
- first-pass and final acceptance;
- reviewer minutes; and
- unauthorized, out-of-scope, or undisclosed tool behavior.
Predefine minimum acceptance and latency thresholds before examining cost. Otherwise, a cheaper configuration can appear successful simply because the quality bar moved after the results were visible.
A 30–50-task pilot can expose integration errors, but it is not sufficient to establish a rare-event safety rate or a universal quality ranking. Keep results separated by task category, repeat a subset to assess variability, and expand with held-out tasks before broad rollout. Averages can conceal a route that helps coding while harming document-grounding tasks.
Use isolated copies of mutable test state so the first run cannot change the second run’s evidence. If fallback is part of the intended product, evaluate that whole policy as a separate route; do not compare Sol-only costs with incumbent-plus-fallback outcomes.
Decision
GPT-6.1 Sol is a credible candidate for bounded, verifiable agent work. The benchmark, API and safety evidence identifies where to begin testing; the routing decision still belongs to the workload owner. This article’s operational focus is the acceptance contract, bounded fallback and fully loaded route ledger—not another universal model ranking.
They do not support automatic migration.
Use Sol as a candidate default when tasks have objective completion checks, permissions can remain narrow, and the fully loaded ledger improves. Retain or escalate to Astra when Sol fails the same rubric, when errors are costly, or when the workload resembles the hardest scientific and open-ended reasoning tasks for which OpenAI still favors Astra.
The adoption threshold is not “near Astra” and not “one-fifth the token price.” It is stricter:
The same accepted outcome, within the same latency, permission, and safety constraints, at a lower total cost.
Write the routing contract before the pilot
| Observed condition | Action | Evidence to retain |
|---|---|---|
| Passes the fixed rubric and route limits | Accept; evaluate aggregate economics by workload class | Artifact, validator result, cost, latency and review time |
| Fails quality; authorized retry budget remains | Use the predefined fallback, without widening permissions | Failure category and all additional attempts |
| Permission denied or requested action is out of scope | Stop and request the required human decision | Denied action and the unchanged authority boundary |
| Deadline or spend cap reached | Return a clear incomplete outcome; no silent retry loop | Elapsed time, total spend and unresolved work |
Assign an owner to each workload class and version the rubric, harness and routing configuration together. During a limited rollout, monitor acceptance, tail latency, fallback frequency and reviewer burden against the incumbent. Predefine a rollback trigger and keep a known-good configuration. A cheaper successful pilot is not permission to silently expand the task scope later.
Frequently asked questions
Does an Astra fallback automatically make a Sol-first route cheaper?
No. A fallback adds to the cost already incurred by the failed Sol attempt and may add review or repeated tool work. Measure the whole route, count the finally accepted task once, and compare the same acceptance threshold and retry policy. The synthetic example above shows why a lower model bill can still lose after review.
Should every quality failure escalate to a stronger model?
No. First distinguish a solvable quality failure from missing input, broken tools, an exhausted budget or a permission denial. A model upgrade cannot authorize an action. Escalation is appropriate only inside a predefined budget and the existing authority boundary; otherwise return the limitation or ask the responsible person.
Can a 30–50-task pilot justify changing every production route?
No. It is a practical integration and hypothesis test, not a guarantee. Expand with held-out tasks and repeated trials, inspect failures by category, and retain rollback controls. Report sample sizes and variability instead of presenting a small pilot’s average as a stable production rate.
What must be logged to reproduce a routing decision?
Keep the task and rubric versions, model identifier, effort, endpoint, tier, region, token categories, tool charges, attempt chain, validator outputs and reviewer time. Record the price reference date. Redact sensitive content and follow the organization’s retention rules; reproducibility does not require retaining secrets or full private prompts indefinitely.
Sources and verification
- OpenAI launch announcement and reported benchmarks
- GPT-6.1 Sol model reference
- API pricing
- API release history
- Work and Codex model availability
- Operational Ultrafast API guide
- Localized launch page consulted for the availability discrepancy
- GPT-6.1 Sol system-card addendum
- Artificial Analysis independent model evaluation
Sources reviewed October 6, 2026. Vendor and independent measurements are attributed above. Proposed controls and the synthetic cost example are Tech Trend Insight editorial analysis, not measured deployment results.
