GPT-6 Makes Reasoning Effort the New Unit of AI Economics

A customer support manager may need a model to extract a refund request from a form in seconds. A financial analyst may need one to reconcile conflicting documents, test assumptions and prepare a board-ready narrative. Both are AI tasks. But giving both the same model, the same time budget and the same appetite for internal deliberation is like sending every package by overnight courier.

That is the economic logic behind the GPT-6 family. OpenAI’s launch announcement said Astra remains its top model, while Sol and Luna are designed to bring related advances to faster, cheaper tiers. OpenAI also said it cut Sol and Luna API prices by 50% compared with GPT-5.6 promotional pricing, citing improvements in inference and caching.

The headline price cut matters. The deeper change is that model selection now has three variables: baseline capability, reasoning effort and unit cost. For companies building AI into repeated workflows, the third variable increasingly depends on the second.

The real product is a decision about how long to think

Reasoning effort is best understood as a budget for extra work before the visible answer arrives. It is not merely a setting for making prose longer. A reasoning model can use that budget to decompose a request, test a strategy, inspect an apparent contradiction, decide whether to call a tool, assess the tool’s result and revise its plan.

OpenAI’s October 2026 safety documentation explains that its reasoning models are trained through reinforcement learning to think before answering, refine strategies and recognize mistakes. The company also distinguishes between testing models at their lowest reasoning settings for many safety evaluations and testing maximum effort to establish an upper bound for capabilities.

“Astra gives us a significant advantage in both capability and efficiency. It successfully executes our most complex creative workflows while using up to 20% fewer tokens than other models we've tested. Most importantly, for our customers, it means higher quality output.”

That distinction has operational consequences. A low-effort model invocation may answer directly from the prompt and supplied context. A higher-effort invocation can spend more internal tokens exploring alternatives before composing an answer. If it is working through a multi-step task, it may also loop through tools such as search, code execution or a company database.

More effort can be valuable when a task contains uncertainty that is expensive to miss. Consider an agent asked to identify why revenue figures differ across three spreadsheets. A quick response may spot an obvious formatting difference. More deliberation may lead the agent to compare date ranges, trace formulas, locate an excluded subsidiary and flag the one conclusion it cannot verify. The extra computation is only worthwhile if it improves the final business decision enough to justify slower completion and higher cost.

This is why “use the best model” is becoming incomplete advice. There are cases where Luna with high effort is more appropriate than a stronger model used casually, and cases where Astra at low effort is right because preserving nuance matters more than generating a large internal search process.

OpenAI’s model-selection guidance says Luna is intended for scoped tasks, triage and frequent automations; GPT-6.1 Sol is for complex work where teams need to manage time and cost; and Astra is for ambiguous problems, deep analysis and ambitious deliverables. The same guidance recommends that teams compare models and reasoning settings on representative inputs, then keep the lightest setting that meets their quality bar.

That last phrase should become a procurement principle. The winning configuration is not the one that produces the most impressive demonstration. It is the least expensive configuration that reliably completes the actual job.

Why invisible tokens change the bill

The hidden arithmetic of reasoning starts with tokens. Tokens are pieces of text processed by a model. A model invocation may involve the user’s prompt, instructions, previous messages, documents and tool results as input, plus internally generated reasoning tokens and the visible answer as output. The answer the user sees is only one part of the work.

A model with a larger reasoning budget can consume more tokens before it produces its visible output. It may generate candidate plans, reject weak ones, check constraints and rehearse a tool call. This can improve performance on tasks that require searching through possibilities, following detailed rules or catching contradictions. It can also magnify cost and latency if the task was simple enough to answer correctly without those steps.

The economics become sharper in agentic systems. An agent that reads a customer record, checks a policy database, drafts a response, notices an exception and rechecks its work can create several rounds of inference. Each round has a cost. Each may add more context for the next.

A useful mental model is cost per successful task, not cost per token. A cheap response that must be repaired by an employee is not cheap. Nor is an expensive response automatically wasteful if it prevents a high-cost mistake. The measurement must combine model spending, elapsed time, error rate, tool expenses and human review.

OpenAI’s pricing table offers a clear example of the first layer of savings. Its stated input price for GPT-6 Sol is $2 per million tokens, down from $4 for GPT-5.6 Sol promotional pricing. Output pricing is $10, down from $20. For Luna, input pricing falls from $0.20 to $0.10, and output pricing from $1.20 to $0.50, all per million tokens.

The chart is useful because it shows why output-heavy systems deserve special scrutiny. But it should not be read as a complete bill forecast. Reasoning tokens, repeated tool loops, input context and cache performance can reshape the practical cost of a finished task.

Caching turns context from a toll booth into an asset

Long-running agents face a separate problem. They repeatedly carry prior context forward: policy manuals, customer histories, codebase instructions, project plans and prior actions. Reprocessing the same prefix on every request is computationally inefficient.

This is where prompt caching matters. In a transformer-based inference system, the model creates intermediate representations of earlier tokens, often described as key-value state or a KV cache. Reusing that prepared state lets the system avoid doing the same initial computation again when later requests share the same prefix.

The important business point is simple: a stable shared context can become cheaper and faster to reuse than to rebuild.

OpenAI said GPT-6 improves cache hit rates by default and offers a 90% discount on cached input-token reads. It also said developers can change reasoning effort and tool availability without breaking reuse of earlier context, while explicit cache breakpoints provide more control over which prompt prefixes are reused.

That changes how teams should structure prompts. Put durable instructions, repeated documents and stable data early. Keep volatile material, such as the latest user request or tool output, later. Make changes to the reusable prefix deliberately. A minor prompt rewrite may look harmless to a product manager but can cause a cache miss across a high-volume workflow.

Caching does not eliminate the cost of reasoning. It reduces the cost of repeatedly reaching the point where the model starts reasoning about new information. In a customer service agent, that might mean every conversation begins with the same policy framework already prepared. In a coding assistant, it could mean repository conventions and build instructions are reusable across many requests.

The result is an economic system, not a single model call. Better caching can make a more capable workflow viable at scale. Poor cache design can erase much of the apparent advantage of lower token prices.

The router is the new manager

Once a model family includes several capabilities and several effort settings, the most valuable component may be the router. Its job is to decide what the incoming task deserves.

A sensible router does not need mystical intelligence. It can begin with rules: use Luna at low effort for structured extraction; use Luna at higher effort for constrained triage across connected systems; choose Sol for multi-document analysis or work expected to go through revision; send genuinely ambiguous, high-consequence or broad-context tasks to Astra.

Then add escalation. If Luna encounters missing data, conflicting instructions, unusually low confidence or a failed verification check, the system can retry with more effort or route the task to Sol. If Sol cannot resolve the ambiguity, the workflow can require a human decision or use Astra.

This approach is more disciplined than treating escalation as a response to aesthetic dissatisfaction. The trigger should be explicit and measurable. Did the output include every required field? Did a reconciliation sum to zero? Did the code pass tests? Did a record actually save? Did the answer cite the required source material? These are acceptance criteria, not vibes.

OpenAI advises measuring completion time alongside output quality, including the time needed to review or repair results. It also recommends varying reasoning effort while holding the model and inputs fixed. That is the right experimental design because it separates two questions that are often confused: whether a model can complete a task, and whether spending more effort makes it economically preferable.

How to set an adaptive reasoning budget

Teams should begin with a task inventory, not a model preference. List workflows by frequency, consequence of failure, required response time, available verification and human repair cost. A monthly strategic analysis and a million daily classification requests should not share a default.

For each workflow, define a baseline test set from real representative tasks. Run a small matrix: Luna at low and higher effort, Sol at medium and higher effort, then Astra where appropriate. Track success rate, time to verified completion, model cost, tool cost and human intervention. The preferred configuration is the cheapest one that clears a pre-agreed threshold.

Next, build exceptions into the policy. Increase effort when inputs conflict, required data is absent, a tool call fails or the task is externally consequential. Lower effort for routine follow-ups and simple extraction. Do not let a model silently spend an unlimited budget merely because a request sounds complicated.

Finally, preserve a human checkpoint where the cost of a plausible but wrong answer is severe. Reasoning may reduce mistakes, but it does not turn an uncertain system into an accountable decision-maker.

The supplied materials contain detailed company claims and documentation, but no independent favorable reception to balance their framing. That absence matters. OpenAI’s own benchmarks and pricing data are useful evidence about what the company is offering, yet they are not a substitute for each buyer’s evaluation in its own workflow.

GPT-6’s larger lesson is that AI competition is moving from a contest over raw model size toward a contest over resource allocation. The practical advantage will go to companies that can decide, task by task, when extra thought is valuable, when reuse makes context cheap, and when a smaller model is not a compromise but the rational choice.