OpenAI cut the standard API price of GPT-6.1 Terra to $1 per million input tokens and $5 per million output tokens, roughly 50% lower than the previous generation. That number travels well. It also answers a narrower question than the one engineering teams actually ask, which is whether a finished, accepted bug fix now costs less.
The two questions are not the same. A per-token price is an input to a task, not the price of one. Everything below works through the gap between them, with the arithmetic spelled out.
Cost per accepted task as the unit of comparison
Why the token price decides nothing on its own
Three costs sit outside a per-million-token figure, and each one shows up on the same bill.
- A task is rarely a single attempt. When the first patch fails the test suite, the retry carries the error log with it, and every extra round bills input and output again.
- Failed attempts still bill. A wrong patch spends tokens like a right one, and the spend is not refunded.
- Failures need a person. Fifteen minutes of engineer time spent unwinding a bad model change can cost more than dozens of API calls.
A low unit price is a necessary condition for a cheaper task, not a sufficient one. When two models have similar pass rates, the cheaper unit price turns into real savings. When pass rates diverge, the saving can invert.
The formula
Cost per accepted task = (total model spend + human cleanup cost) / number of accepted tasks
Model spend here counts successful and failed attempts together. Accepted tasks include the ones that only passed after a person stepped in. Otherwise the formula quietly hides the cost of failure. Teams that want to judge the model in isolation should also track the share of tasks that passed with no human help at all.
What public case studies leave out
Discussion threads like to settle the argument with one anecdote, such as a small game finished in a few minutes for a dollar or two. Those stories are vivid and thin. Without a shared acceptance bar, and without saying whether the deliverable passed tests or needed rework, they cannot be converted into cost per accepted task. Case studies retold in this article were not independently verified and serve only as background.
What GPT-6.1 Terra is, and what it costs
Positioning
OpenAI describes GPT-6.1 Terra as a fast, efficient model and positions it as a new balance of speed, capability and cost. The scenario highlighted in the launch material is high-volume automation, such as reading incoming invoices and entering the details into accounting software.
Pricing and availability
The API model name is gpt-6.1-terra. Standard API pricing runs at $1 per million input tokens, $0.05 per million cached input tokens and $5 per million output tokens. That standard API price is 50% lower than GPT-5.6 Terra and GPT-6.1 Sol.
Plus, Pro, Enterprise and Edu users can reach it inside ChatGPT Work and Codex. Developers can call it through the OpenAI API. OpenAI also notes that within the same usage quota in ChatGPT Work and Codex, more tasks can be completed than with GPT-5.6 Terra.
Published benchmark results
The figures below are OpenAI's own published numbers, not independent measurements.
- Computer use. On Agents' Last Exam at medium reasoning effort, scores land about 15 percentage points above GPT-5.6 Terra at roughly one-third the cost. On OSWorld 2.1, medium reasoning already beats GPT-5.6 Terra's best result.
- Visual reasoning. On MMMU-Pro it beats GPT-5.6 Terra at every reasoning setting.
- Factual accuracy. On an internal OpenAI test built from prompts that tend to trigger errors, the error rate at low reasoning effort fell from 53.6% to 16.7%, and to 4.3% at maximum reasoning effort.
- Software engineering. On Terminal-Bench 4.0, a command-line coding benchmark, it solved 50.3% of tasks at maximum reasoning effort. GPT-5.6 Terra's published score was 21.5%.
- Speed. Task completion is more than 3× faster than GPT-6 Astra and GPT-6.1 Sol.
OpenAI also states that for the most complex coding work, GPT-6.1 Sol and GPT-6 Astra remain the better choices. That boundary drives the task-splitting rules further down.
Safety and alignment notes
OpenAI says Terra's cybersecurity capability reaches the Critical risk level in its Preparedness Framework, and that it keeps the protections built for GPT-6 Astra. In alignment evaluations Terra is more likely than GPT-5.6 Terra to stay inside the task scope and to state its own limits accurately. Prompt-injection tests show strong resistance to malicious instructions. The official system card carries the detail.
Reading the one-tenth and one-ninth claims
Two statements, two different comparison targets
The claim circulating most widely is one-tenth. The launch material contains two statements that sit close together but measure different things.
The first compares Terra with GPT-6 Astra on Agents' Last Exam, where performance is comparable while each token costs about one-tenth as much. That is a token unit price comparison, against Astra, on computer-use tasks.
The second runs at maximum reasoning effort, where Terra's token efficiency is more than 3× Claude Opus 5.5's while each token costs about one-fourth as much, putting cost per task at roughly one-ninth.
What neither statement covers
Neither claim says a bug fix costs one-tenth as much. The second at least frames the comparison per task, and OpenAI itself does not equate unit price with total cost. Anyone quoting the headline figure as a fix-your-backlog discount is stretching it past what was published.
Anatomy of one billed call
The three components
At the official rates, the cost of a single call is the sum of three parts.
Input covers code files, error logs and the prompt, billed at $1 per million tokens. Cached input covers context that repeats across retries, billed at $0.05 per million tokens, one-twentieth of ordinary input. Output covers patches, explanations and reasoning tokens, billed at $5 per million tokens, five times the input unit price.
Cache is the lever on retries
Cache matters most during retries. Code and prior context reappear round after round, and when the cache hits, the marginal cost of another round drops sharply. Whether it hits depends on prefix consistency and other conditions. Exact rules and TTL follow OpenAI's documentation.
Prompt structure decides a lot here. Put stable project notes and file contents first, and place this round's error text last, so the repeated prefix stays stable across attempts.
Output is the expensive component, so raising reasoning effort pushes up per-call cost as output grows.
Five steps from unit price to total bill
- Unit price. Look up the official rates for input, cached input and output.
- Attempts. Record how many rounds each task took and how many tokens each round consumed.
- Acceptance. Write the pass criteria before the run. Named tests all pass, no regression on existing tests, no editing test files to force a pass.
- Human cleanup. Record the minutes of human intervention after a model failure, converted at a single hourly rate.
- Total. Apply the formula above.
Step three is the one teams skip. Without written criteria, there is no denominator, and the whole ledger collapses back into a feeling about which model writes nicer code.
A worked example where half the unit price costs about 13 times more
Assumptions
Every parameter below is assumed. None of it represents real pass rates for Terra or for any other model.
- Each attempt uses 10,000 uncached input tokens, 30,000 cached input tokens and 8,000 output tokens.
- At most 3 attempts per task, stopping on success.
- If all 3 attempts fail, human cleanup takes 15 minutes at $60 per hour, so $15.
- Model A uses Terra rates with a 40% per-attempt pass probability.
- Model B costs twice Terra's unit price with an 80% per-attempt pass probability.
- At Terra rates, one attempt costs $0.01 input + $0.0015 cached + $0.04 output = $0.0515.
Python that reproduces every figure
def cost_per_accepted_task(p, price_mult, cap=3, manual_fix=15.0):
# Per-attempt cost (USD) at the example Terra standard rates
per_attempt = (10_000 * 1 + 30_000 * 0.05 + 8_000 * 5) / 1_000_000 * price_mult
fail_all = (1 - p) ** cap # probability all attempts fail
expected_attempts = sum((1 - p) ** i for i in range(cap)) # expected number of attempts
model_cost = expected_attempts * per_attempt
manual_cost = fail_all * manual_fix # expected human cleanup after total failure
return per_attempt, expected_attempts, fail_all, model_cost, manual_cost, model_cost + manual_cost
print(cost_per_accepted_task(0.4, 1)) # Model A: Terra rates
print(cost_per_accepted_task(0.8, 2)) # Model B: 2× unit price
Results
| Item | Model A (1× price, 40% pass) | Model B (2× price, 80% pass) |
|---|---|---|
| Cost per attempt | $0.0515 | $0.103 |
| Expected attempts | 1.96 | 1.24 |
| Model spend | $0.101 | $0.128 |
| Probability all fail | 21.6% | 0.8% |
| Expected human cleanup | $3.24 | $0.12 |
| Cost per accepted task | ~$3.34 | ~$0.25 |
Under these assumptions Model A, at half the unit price, carries about 13 times Model B's total cost, and human cleanup dominates the difference. Look only at model spend and the ranking flips. A runs $0.101 per task against B's $0.128, so A looks slightly cheaper right up until a person has to open the editor.
The reverse holds too. Push A's pass rate toward B's and human cleanup shrinks fast, at which point the price edge becomes visible. The hinge is not the unit price. It is the pass rate, multiplied by what an hour of human failure costs.
Running the same comparison on a real repository
Controls to hold fixed
Pick a stably reproducible bug with a failing test, a public repo and a fixed commit. Medium difficulty works best, meaning not solvable in one shot and not hopeless.
Hold the prompt, the code snapshot and the retry cap identical across models. Keep billing channels consistent as well, and avoid mixing API figures with subscription quotas in one table. Run each model several times, because a single run is noisy enough to reverse a verdict.
Fields to log per attempt
Record attempt index, pass or fail, and token counts read from the API usage fields. Log human minutes whenever a failure needed intervention. The acceptance criteria should travel with the data, so a later reader knows what passed meant on the day of the run.
Matching task types to models
Work that suits Terra first
Scoped fixes with existing test coverage are the natural starting point. Pass rates tend to be higher, retries fewer, and the low unit price shows through. High-volume repetitive jobs fit the same profile, since unit-price gaps get amplified at scale.
Work that still belongs on a stronger model
Cross-module refactors and tangled dependency changes are better evaluated on a stronger model first. OpenAI itself points to GPT-6.1 Sol and GPT-6 Astra for the most complex coding work. When those tasks fail, the cleanup is expensive, and the money saved on a single call does not come close to covering it.
When the requirements are fuzzy
If tests are missing, add tests before picking a model. Without acceptance criteria there is no way to compute cost per accepted task, and any model choice defaults to taste.
This split is a starting point, not a policy. The stronger evidence is your own task data. Run a batch, compute cost per accepted task, then move work between models based on what the ledger says.
Holding the acceptance environment steady
Why environment drift contaminates the ledger
The same bug behaves differently across language and database versions. A model's first failure may come from bad code, or from mismatched dependencies, and those two failures should never share a ledger. If the runtime moves between runs, attempt counts and pass rates stop being comparable and the whole comparison loses its denominator.
ServBay, a one-stop AI development management tool, keeps PHP, Node.js, Python and other runtimes pinned on the machine alongside database and site configuration. Fix the acceptance environment once and every model attempt runs under identical conditions.
Using one endpoint for the comparison
ServBay AI Gateway also works as a single local entry point for this kind of test. Calls go out with virtual keys while the real upstream keys stay on the gateway side, encrypted locally and never uploaded. OpenAI, Anthropic and Gemini compatible paths are available, so a model swap does not require rewriting client code, and Claude Code, Codex and similar CLI tools can be pointed at the same endpoint from the interface.
Usage and cost for each run land in one place, which is what a per-task ledger needs. Per-project virtual keys keep an experiment from bleeding into production traffic, and they can be revoked when the run ends.
FAQ
Does a lower unit price always save money?
No. Unit price is one component of total cost. With low pass rates, many retries and heavy human cleanup, a cheap model can still cost more. Cost per accepted task is the metric that settles it.
How is cost per accepted task computed?
Add total model spend to human cleanup cost, then divide by the number of accepted tasks. Model spend has to include failed attempts, not just successful ones.
What is GPT-6.1 Terra's API price?
Per the launch announcement, standard API pricing is $1 per million input tokens, $0.05 per million cached input tokens and $5 per million output tokens. Prices change, so check OpenAI's official pricing page before budgeting.
Is Terra a fit for complex coding tasks?
On Terminal-Bench 4.0 at maximum reasoning effort it solved 50.3% of tasks, a clear jump over the previous generation. OpenAI still names GPT-6.1 Sol and GPT-6 Astra as the better fit for the most complex coding work.
Can cache hits distort a cost comparison?
Yes. Tasks with high cache hit rates cost less than estimates built on ordinary input prices. Record cached token counts for each model and keep prompt structure consistent across runs.
Is Copilot billed the same as the API?
No. The launch announcement does not spell out Copilot billing. Check GitHub's official billing documentation and do not apply API token unit prices to it directly.
What to take away
Terra moves price, speed and coding ability forward at the same time, and OpenAI's published numbers support that on the specific benchmarks listed above. Whether a given codebase gets cheaper is a separate question that only its own acceptance criteria can answer.
Model selection is drifting away from leaderboard position and toward how much money and time one finished task consumes, plus whether delivery holds up. The practical move is small. Take one reproducible bug, log tokens and human minutes per attempt, compute cost per accepted task, and let that number decide which work goes to which model.
Top comments (0)