GPT-6.1 Sol is a strong default for small-business automations that need serious reasoning, coding, browser work, computer use, or document analysis without paying Astra rates. For API requests with no more than 272,000 input tokens, Standard processing costs $2 per million input tokens, $0.10 per million cached input tokens, $2.50 per million cache-write tokens, and $10 per million output tokens. That headline is accurate, but it is not a workflow budget.
Real cost depends on reasoning effort, output length, cache reuse, tool calls, containers, processing tier, and whether any single request crosses 272,000 input tokens. A repeated document workflow can cost pennies when its stable prefix is cached. A browser agent can cost dollars because it repeatedly carries screenshots, page history, tool results, and reasoning across many steps. Start with Standard or Flex, measure complete workflows, and reserve Fast or Ultrafast for latency that actually changes a business outcome.
Methodology: vendor-document verification, not hands-on testing. Prices, model IDs, limits, tool charges, and product availability were checked against current OpenAI documentation on October 12, 2026. No Google Search Console or GA4 evidence was available. Worked costs below are transparent planning examples, not invoice forecasts.
A useful cost model follows the whole workflow: input, cache writes and reads, reasoning output, tools, containers, retries, and approval steps.
What does GPT-6.1 Sol cost?
Standard short-context GPT-6.1 Sol costs $2 input, $0.10 cached input, $2.50 cache writes, and $10 output per million tokens. OpenAI defines short context as a request with no more than 272,000 input tokens. The model ID is gpt-6.1-sol.
| Processing tier | Short input | Cached input | Cache write | Short output | Typical use |
|---|---|---|---|---|---|
| Standard | $2.00 | $0.10 | $2.50 | $10.00 | Default interactive automation |
| Batch | $1.00 | $0.05 | $1.25 | $5.00 | Asynchronous work that can wait |
| Flex | $1.00 | $0.05 | $1.25 | $5.00 | Lower-cost work that tolerates variable latency or resource unavailability |
| Fast | $4.00 | $0.20 | $5.00 | $20.00 | User-facing work where latency matters |
| Ultrafast | $12.00 | $0.60 | $15.00 | $60.00 | The narrowest latency-sensitive paths |
All token prices are per one million tokens. Batch and Flex are 50% below Standard, Fast is 2x Standard, and Ultrafast is 6x Standard. OpenAI renamed Priority processing to Fast; service_tier: "priority" remains accepted as an alias, but new implementations should use fast.
Regional processing adds 10% where available. Apply that uplift after the tier and context rates. A $100 global-processing bill becomes $110 under an eligible regional endpoint before taxes or unrelated product charges.
Why the 272,000-token threshold can change the whole bill
If a request contains more than 272,000 input tokens, the long-context multiplier applies to the full request—not only the tokens above the threshold. Input, cached input, and cache writes double; output becomes 1.5x the short-context output rate.
For Standard GPT-6.1 Sol, long-context rates are $4 input, $0.20 cached input, $5 cache writes, and $15 output per million tokens. The same multipliers apply to the other processing tiers.
Example: one Standard request with 300,000 uncached input tokens and 10,000 output tokens costs:
- Input: 0.30 × $4 = $1.20
- Output: 0.01 × $15 = $0.15
- Total: $1.35
Pricing it as 272,000 tokens at the short rate plus only the remainder at the long rate would be wrong. The cliff is request-wide. For large contracts, knowledge bases, code repositories, or browser histories, compacting below the threshold can be more valuable than shaving a few thousand tokens from the output.
Long-context pricing applies to every token in a request once input exceeds 272,000 tokens.
How caching changes the economics
Caching is the biggest controllable cost lever for repeated GPT-6.1 Sol workflows. A cached prefix costs 5% of ordinary input, while writing that prefix costs 1.25x ordinary input. The first request can therefore cost slightly more; later matching requests can cost much less.
GPT-6.1 Sol can cache a visible prefix of at least 1,024 tokens. For GPT-5.6 and later, the current cache lifetime is at least 30 minutes after the latest write or reuse, using prompt_cache_options.ttl: "30m". Reuse refreshes the lifetime without another cache-write charge. Cache hits still depend on a stable matching prefix.
Put stable material first:
- Developer instructions and policies
- Tool definitions and schemas
- Stable reference documents
- Reused examples and output formats
- Earlier conversation and tool history that has not been rewritten
Put changing material later. Timestamps, user-specific facts, newly fetched records, and the current task should not disturb the reusable prefix. Appending new messages usually protects cache reuse better than repeatedly summarizing or rewriting earlier history.
Worked document-analysis example
Assume 2,000 monthly document runs, each with a 20,000-token stable policy/schema prefix, 5,000 new document tokens, and 1,000 output tokens.
- First cached run: 20K cache write + 5K input + 1K output = about $0.07
- Later run: 20K cached input + 5K input + 1K output = about $0.022
- Approximate month after the initial write: about $44
- Same 2,000 runs with all 25K input uncached: about $120
This example assumes the cached prefix remains eligible and requests stay below the long-context threshold. Inspect usage.input_tokens_details.cached_tokens and cache_write_tokens; do not assume a cache hit because two prompts looked similar to a human.
What do tools and containers add?
Model tokens are only one line of an agent bill. OpenAI currently charges web search at $10 per 1,000 calls, plus search-content tokens at the selected model’s rates. File search costs $2.50 per 1,000 tool calls, with storage at $0.10 per GB per day after the first free GB.
Hosted Shell and Code Interpreter use container pricing. Current 20-minute session prices are:
| Container memory | Price per 20-minute session |
|---|---|
| 1 GB | $0.03 |
| 4 GB | $0.12 |
| 16 GB | $0.48 |
| 64 GB | $1.92 |
Eligible sessions are billed by the minute with a five-minute minimum. Built-in tool tokens are also billed at model token rates. Function calls to your own systems do not have a separate OpenAI tool-call line item, but the arguments, outputs, and follow-up reasoning still consume tokens—and the third-party system may charge its own fees.
Computer use is supported by GPT-6.1 Sol through the Responses API. Price it as a sequence, not a single click: screenshots and page state enter context, the model reasons, a tool action runs, the result returns, and the loop repeats. Retries, login failures, approval pauses, and changing page layouts increase both token and operational cost.
What does a browser workflow cost in practice?
A realistic browser-agent estimate should total every model turn and tool call in one completed workflow. Consider a 30-step research-and-entry workflow with 900,000 aggregate input tokens across many sub-272K requests, 75% cache reads, 50,000 output tokens, 30 web searches, and one 1 GB container session.
- 675K cached input: $0.0675
- 225K uncached input: $0.45
- 50K output: $0.50
- 30 web searches: $0.30
- 1 GB container: $0.03
- Illustrative total: about $1.35 per completed workflow
At 300 completed workflows per month, that is about $405 before retries, regional uplift, third-party browser infrastructure, or human-review labour. The useful metric is cost per accepted outcome, not cost per API request.
OpenAI’s October 2026 Asana/StackAI customer story is instructive but not a universal benchmark. It reports a 144-run browser-agent study in which an optimized GPT-6.1 Sol workflow averaged $0.47 in estimated model cost and roughly four minutes per run. OpenAI says the improvement involved longer retained history, better caching, and less-frequent screenshot removal. That is vendor-published evidence about one controlled workflow—not proof that another company will achieve the same cost, speed, accuracy, or ROI.
Standard, Batch, Flex, Fast, or Ultrafast?
Use the cheapest tier that still meets the workflow’s business deadline. Faster output is valuable only when waiting costs more than the speed premium.
- Standard: default for live internal workflows, interactive document work, and initial pilots.
- Batch: best for large asynchronous queues such as overnight classification, enrichment, or evaluation jobs.
- Flex: best for non-urgent workloads that can tolerate variable latency and occasional resource unavailability while using Batch-level token prices.
- Fast: reasonable for customer-facing assistants, coding loops, and operator-in-the-loop automation where latency blocks a person.
- Ultrafast: reserve for genuinely latency-sensitive paths. It costs 6x Standard, works through the Responses API, and has separate rate limits.
Default GPT-6.1 Sol API limits are 5,000 RPM and 1 million TPM at Build, 10,000 RPM and 4 million TPM at Launch, and 15,000 RPM and 40 million TPM at Grow. Ultrafast currently has separate default TPM limits of 1 million, 4 million, and 40 million for those same tiers. Check the organization’s actual limits before launch; a model’s context window is not a promise that every account can push that many tokens at the required concurrency.
Where is GPT-6.1 Sol available?
GPT-6.1 Sol is available in the API, Codex, and ChatGPT Work, but not ordinary Chat. In the API, select gpt-6.1-sol. OpenAI currently requires the Responses API for tool calling; Chat Completions supports the model only without tool calling.
The model accepts text and image input, produces text output, has a 1,050,000-token context window, and supports up to 128,000 output tokens. Reasoning effort supports low, medium (default), high, xhigh, and max; none and minimal are not supported.
OpenAI’s current rollout includes Plus, Pro, Business, Enterprise, and Edu users in Codex on desktop and CLI, plus ChatGPT Work on web and mobile. Enterprise and Edu administrators must enable it because it is off by default. Free and Go are not included at launch. Plan, client, rollout, and workspace controls can still affect what an individual user sees.
Do not confuse ChatGPT plan usage with API pricing. ChatGPT Work and Codex can consume plan credits under their own product rules. The $2/$10 API table does not directly price a ChatGPT Work session.
For a plan-level budget rather than an API-token budget, our ChatGPT Work pricing and use-case guide explains the separate seat and agentic-usage model.
When should a small business use Luna, Sol, or Astra?
Route by task difficulty and consequence instead of sending everything to one model. Luna is the efficiency route, GPT-6.1 Sol is the balanced workhorse, and Astra is the escalation path for the hardest work.
| Route | Use it for | Avoid using it as the default when |
|---|---|---|
| GPT-6 Luna | Extraction, classification, triage, short summaries, focused coding, high-volume repeatable steps | The workflow must reconcile conflicting evidence or coordinate a complex multi-step deliverable |
| GPT-6.1 Sol | Document analysis, browser work, coding, computer use, and multi-step automations where quality and cost both matter | The step is simple enough for Luna, or the consequence justifies Astra’s stronger judgment |
| GPT-6 Astra | Ambiguous investigations, high-stakes planning, difficult exception handling, and final review of consequential work | The task is frequent, repeatable, and already meets the quality bar on Sol or Luna |
A practical router escalates by ambiguity, consequence, and failed evaluation—not by prestige.
A good small-team pattern is Luna for intake and triage, Sol for the main workflow, and Astra only for exceptions or final review. OpenAI’s own model-selection guidance says to compare models on the same task and keep the lightest setting that meets the quality bar. Vendor benchmarks can narrow the shortlist; your acceptance tests make the buying decision.
A monthly SMB cost scenario
A mixed workload can stay below four figures, but browser loops and verbose outputs dominate faster than simple extraction. Consider an illustrative month:
| Workload | Volume | Planning cost per completed item | Monthly estimate |
|---|---|---|---|
| Cached document extraction | 5,000 | $0.022 | $110 |
| Browser research and data entry | 200 | $1.35 | $270 |
| Coding or spreadsheet automation | 300 | $0.35 | $105 |
| Illustrative total | $485 |
This is not a quote. A workflow with higher reasoning effort, longer output, failed runs, more screenshots, regional processing, or repeated cache misses will cost more. Add human review separately. If an employee spends two minutes approving each of 5,000 low-value outputs, the human-review cost can dwarf the API bill.
Track these fields per completed workflow: model, reasoning effort, service tier, input tokens, cached tokens, cache-write tokens, output tokens, tool calls, container minutes, retries, completion status, human-review time, and accepted/rejected outcome.
Caching and context-management checklist
The goal is a stable reusable prefix and a small changing tail. Before production:
- Keep fixed instructions, tool schemas, and reference material at the beginning.
- Put current records, timestamps, and user-specific data after the stable prefix.
- Preserve prior messages and tool results when they remain useful; avoid rewriting history every turn.
- Use explicit cache breakpoints where a stable prefix ends and changing content begins.
- Confirm the reusable prefix exceeds the 1,024-token minimum.
- Read actual cached-token and cache-write usage from responses.
- Alert when any request approaches 272,000 input tokens.
- Compact or retrieve only relevant source sections instead of dumping entire repositories or file rooms into every call.
- Keep screenshots until their facts are no longer needed, but remove them in planned batches rather than mutating history every step.
- Separate tenant or customer cache accounting when needed; do not put secrets or cross-customer material into shared application prompts.
- Re-run cost tests after changing reasoning effort, tool definitions, response schemas, or context policy.
Which actions require human approval?
Keep humans at irreversible, external, financial, legal, and security boundaries. A useful agent can prepare work without receiving blanket authority to finish every action.
Require approval before:
- Sending customer, employee, vendor, or public messages
- Paying, refunding, transferring, purchasing, or changing billing
- Deleting records, files, accounts, or production data
- Signing, accepting, or submitting contracts, legal forms, tax filings, or regulated records
- Changing credentials, permissions, security settings, or integration scopes
- Deploying to production, merging protected code, or modifying live infrastructure
- Updating a system of record when the change affects money, employment, compliance, inventory, or customer entitlement
- Acting after the agent reports low confidence, conflicting evidence, or an unexpected page state
Read-only lookup, drafting, classification, calculation, and staging are better first automation targets. Log every external action with the source inputs, model route, approval identity, and result.
How to run a measured migration pilot
Pilot one bounded workflow for two weeks before routing a department through GPT-6.1 Sol. Use a production-like sample, but keep consequences reversible.
- Choose one workflow. Define the start event, required inputs, permitted tools, expected output, and stop conditions.
- Build an evaluation set. Include normal cases, messy documents, missing data, authentication failures, ambiguous instructions, and malicious or irrelevant content.
- Establish a baseline. Record current human time, error/rework rate, completion time, and cost without pretending those measurements transfer to other workflows.
- Test Luna, Sol, and Astra. Use the same inputs and acceptance rubric. Start Sol at medium reasoning, then adjust only where failures justify it.
- Measure complete-run economics. Include cache writes and reads, tools, containers, retries, failures, and approval time.
- Set routing and approval rules. Use Luna for safe repetitive steps, Sol for the main flow, and Astra or a person for exceptions.
- Run shadow mode. Let the agent prepare results while humans continue the current process. Compare outputs before enabling writes.
- Release gradually. Start with a small percentage of eligible work, monitor cost per accepted outcome, and keep a manual fallback.
The go/no-go decision should be boring: the pilot passes its accuracy, safety, latency, and cost thresholds, or it does not. “The demo looked futuristic” is not an implementation metric.
Final verdict
GPT-6.1 Sol is the sensible middle route for small teams building serious automation. Its Standard short-context rates are competitive, its 5% cache-read price rewards stable agent history, and its 1.05M context supports large work. The traps are equally clear: cache writes cost more than ordinary input, the 272K threshold reprices the full request, tools and containers add separate charges, higher reasoning creates more output tokens, and Fast or Ultrafast can multiply a weak workflow’s cost without fixing it.
Use gpt-6.1-sol through the Responses API, start with Standard or Flex, instrument every completed workflow, and route simple work to Luna. Escalate to Astra when the task—not the org chart—demands it.
FAQ
What is the GPT-6.1 Sol API model ID?
The current model ID is gpt-6.1-sol.
Does GPT-6.1 Sol support tool calling in Chat Completions?
No. OpenAI says to use the Responses API for GPT-6.1 Sol tool calling. Chat Completions is supported without tool calling.
Does reasoning effort change the listed token price?
The per-token rate stays tied to the model and processing tier, but higher reasoning effort can generate more reasoning and output tokens and take longer. The workflow bill can therefore rise even though the rate card does not change.
Is cached input always cheaper?
Cache reads are much cheaper, but the prefix must first be written at 1.25x the input rate and later requests must match an eligible stable prefix. One-off prompts or frequently rewritten histories may not recover the write cost.
Is GPT-6.1 Sol available in normal ChatGPT chats?
No. OpenAI’s current model documentation says GPT-6.1 Sol is available in ChatGPT Work and Codex, not ordinary Chat. Availability still varies by plan, client, rollout, and workspace settings.
Is Ultrafast worth 6x Standard pricing?
Only when lower latency materially affects conversion, operator time, or an interactive product experience. Use Standard, Batch, or Flex for back-office work that can wait.