GPT-6.1 Terra's unit price is halved, but does it make fixing bugs cheaper?

OpenAI is once again starting a price war.

The standard API price for GPT-6.1 Terra is $1 per million input tokens and $5 per million output tokens, which is 50% lower than the previous generation. But a cheaper unit price does not mean cheaper completed tasks. When selecting a model, you should compare the cost per accepted task, i.e., model fees plus manual remediation, divided by the number of accepted tasks. A low-priced model with a low pass rate and many retries can easily end up more expensive in total.

After Terra's release, the price became the focus of discussion. The price is cut in half, so does that mean the cost of writing code and fixing bugs can also be halved? This article uses examples to show what the facts are.

What kind of model is GPT-6.1 Terra

GPT-6.1 Terra is a fast, efficient model from OpenAI, positioned to balance visual reasoning, computer operation, and writing performance. It is an upgrade of GPT-5.6 Terra, aimed at everyday communication and computer tasks such as drafting proposals, interpreting technical drawings, filling out forms, and editing videos.

The official positioning is to strike a new balance among speed, capability, and cost. The typical scenarios cited in the announcement are large-scale automation, such as reading incoming invoices and entering detailed information into accounting software.

Price and availability

The API call name is gpt-6.1-terra. Standard API pricing is $1 per million input tokens, $0.05 per million cached input tokens, and $5 per million output tokens. The standard API price is 50% lower than GPT-5.6 Terra and GPT-6.1 Sol.

Plus, Pro, Enterprise, and Edu users can use it in ChatGPT Work and Codex, and developers can call it via the OpenAI API. The official announcement also mentions that in ChatGPT Work and Codex, the same usage allowance can accomplish more tasks than with GPT-5.6 Terra.

Capability benchmarks

The following are all benchmark data published by OpenAI.

• Computer operation: On Agents' Last Exam, at medium reasoning effort, the score is 15 percentage points higher than GPT-5.6 Terra, at roughly one-third the cost. On OSWorld 2.1, medium reasoning effort already surpasses GPT-5.6 Terra's best result.
• Visual reasoning: On MMMU-Pro, it outperforms GPT-5.6 Terra under all reasoning settings.
• Factual accuracy: In OpenAI's internal test consisting of prompts prone to inducing errors, the error rate drops from 53.6% to 16.7% at low reasoning effort, and to 4.3% at the highest reasoning effort.
• Software engineering: On Terminal-Bench 4.0, which tests command-line programming ability, at the highest reasoning effort it solves 50.3% of tasks; GPT-5.6 Terra's published result is 21.5%.
• Speed: It completes tasks more than three times faster than GPT-6 Astra and GPT-6.1 Sol.

The official announcement also states that for the most complex programming tasks, GPT-6.1 Sol and GPT-6 Astra remain better choices. This boundary is the basis for the task selection rules discussed later.

Safety and alignment

The official announcement says Terra's cybersecurity capability reaches the Critical level threshold specified by the Preparedness Framework and retains the safety measures developed for GPT-6 Astra. In alignment evaluations, Terra is more likely than GPT-5.6 Terra to stay within the scope of the task and honestly state its limitations. In prompt injection tests, it also shows strong resistance to malicious instructions. See the official system card for details.

The one-tenth and one-ninth comparisons: what exactly are they comparing

The most common claim in discussions is one-tenth, and there are two similar statements in the announcement, but they compare different things.

First, on Agents' Last Exam, Terra's performance is comparable to GPT-6 Astra, while its per-token price is only one-tenth of the latter. This compares token unit price, against Astra, on computer operation tasks.

Second, at the highest reasoning effort, Terra's token usage efficiency is more than three times that of Claude Opus 5.5, and its per-token price is one-fourth, so the per-task cost is roughly one-ninth.

Neither of these means that fixing a bug can be one-tenth cheaper. The second one already uses the per-task cost metric, indicating that OpenAI itself does not equate unit price with total cost.

Why a lower unit price does not mean a lower total bill

Comparing only the per-million-token unit price misses three costs.

1. A task usually involves more than one attempt. If the first fix fails tests, you need another round with the error message; each additional round incurs more input and output charges.

2. Failed attempts are still billed. If a patch is wrong, tokens have already been consumed and the cost is not refunded.

3. After failure, a human has to clean up. An engineer spending 15 minutes debugging what the model broke can cost more than dozens of API calls.

So a low unit price is only a necessary condition. A cheap model with a significantly lower pass rate may have a higher total cost. When pass rates are comparable, the lower unit price does translate into real savings.

In addition, some public discussions use a single example to prove that the cheaper model is more economical, such as building a small game in a few minutes for a couple of dollars. These examples are intuitive but lack uniform acceptance criteria; they do not state whether the finished product passed tests or required rework, making it hard to convert into a per-accepted-task cost. The quoted examples in this article are unverified and serve only as background for the discussion.

What components make up a bill

According to official rates, the cost of a single call is the sum of three parts.

Input includes code files, error logs, and prompts, billed at $1 per million tokens. Cached input is the repeated context in multi-round retries, billed at $0.05 per million tokens, which is only one-twentieth the regular input price. Output includes patches, explanations, and reasoning content, billed at $5 per million tokens, which is 5 times the input unit price.

In retry scenarios, caching is especially significant. Code files and historical context recur across multiple rounds; when the cache is hit, the marginal cost of each additional round drops noticeably. But whether the cache hits depends on conditions such as prefix consistency; specific rules and validity periods follow official documentation. When designing prompts, put fixed parts like project descriptions and file contents at the front, and variable parts like the current round's error message at the back, to increase the chance of cache hits.

Since output is more expensive, raising the reasoning effort increases the per-call cost as output grows.

Five-step extrapolation from unit price to total bill

1. Unit price: Check official rates, distinguishing input, cached input, and output.

2. Number of attempts: Record how many rounds each task actually uses and how many tokens each round consumes.

3. Acceptance: Write acceptance criteria in advance, including all specified tests passing, no regressions in existing tests, and no modifying test files.

4. Manual remediation: Record the minutes a human spends after model failure, converted at a unified hourly rate.

5. Total bill: Apply the following formula.

cost per accepted task = (total model cost + manual remediation cost) / number of accepted tasks

Here, "accepted" includes tasks that pass after manual remediation; otherwise the formula would omit the cost of failures. If you want to isolate the model's own performance, you can also separately calculate the proportion that passes without manual intervention.

Calculation example: unit price half, total bill more than ten times higher

The following is a calculation example; all parameters are hypothetical and do not represent the actual pass rate of Terra or any other model.

Assumptions:

• Each attempt consumes 10,000 uncached input tokens, 30,000 cached input tokens, and 8,000 output tokens.
• Each task allows at most 3 attempts, stopping when it passes.
• If all 3 attempts fail, manual remediation takes 15 minutes, valued at $60 per hour, i.e., $15.
• Model A uses Terra rates, with a per-attempt pass rate of 40%.
• Model B costs 2 times Terra's unit price, with a per-attempt pass rate of 80%.

Under Terra rates, a single attempt costs $0.01 for input, $0.0015 for cached input, and $0.04 for output, totalling $0.0515.

The following Python code reproduces all the numbers.

def cost_per_accepted_task(p, price_mult, cap=3, manual_fix=15.0):
    # Single attempt cost (USD), based on the Terra standard rates in this example
    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 manual remediation cost after 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: 2x unit price

Results:

Item	Model A (1x price, 40% pass rate)	Model B (2x price, 80% pass rate)
Cost per attempt	$0.0515	$0.103
Expected attempts	1.96	1.24
Model cost	$0.101	$0.128
Probability all fail	21.6%	0.8%
Expected manual cost	$3.24	$0.12
Cost per accepted task	~$3.34	~$0.25

Under these assumptions, Model A with half the unit price costs about 13 times more per accepted task than Model B, and manual remediation dominates. Looking only at model cost, A costs $0.101 per task and B costs $0.128, so A is actually slightly cheaper.

The reverse also holds. If A's pass rate increases to near B's, manual remediation cost shrinks quickly, and the price advantage appears. So the key is not the unit price but the pass rate and how much human effort is needed after failure.

How to design a reproducible experiment

To verify in your own project, you can design it the following way.

• Task selection. Pick a bug that reproduces reliably, with a failing test case, a public repository, and a corresponding commit. Choose medium difficulty, not something that passes on the first try, but not something completely unsolvable.

• Acceptance criteria. All specified tests pass, existing tests do not regress, and modifying test files to achieve a pass is not allowed.

• Control variables. Use the same prompt, the same code snapshot, and the same retry limit. The billing channel must also be consistent; do not mix API and subscription plan numbers. Run each model multiple times because single results are affected significantly by randomness.

• Record fields. It is recommended to record the following for each attempt; the token counts can be taken directly from the usage fields in the API response.

Field	Description
task_id	Task number
model	Model name, e.g., gpt-6.1-terra
reasoning_effort	Reasoning effort
attempts	Actual number of attempts
input_tokens	Uncached input tokens
cached_tokens	Cached input tokens
output_tokens	Output tokens
accepted	Whether acceptance passed
manual_minutes	Manual remediation minutes
total_cost_usd	Model cost plus manual cost

Task selection rules

The official announcement also states that for the most complex programming tasks, GPT-6.1 Sol or GPT-6 Astra is still recommended. Combined with the ledger approach above, you can start with an initial allocation and then correct the division using your own data.

For small fixes with clear scope and test coverage, try Terra first. These tasks usually have a higher pass rate, fewer retries, and the low unit price advantage is easier to realize. For batch, repetitive processing tasks, Terra is also a good first choice; once the total volume is large, the unit-price difference is amplified.

For cross-module refactoring or changes with complex dependency relationships, evaluate a stronger model first. Once such tasks fail, manual remediation costs are high, and the small savings per call are not worth the cleanup.

For tasks with unclear requirements or missing tests, add tests first and then choose a model. Without acceptance criteria, you cannot calculate the cost per accepted task, and any model choice is just guessing.

This division is only a starting point. A more reliable basis is your own task data. Run a batch of tasks, calculate the cost per accepted task, and then decide which model to use for which class of tasks.

Use ServBay to fix the acceptance environment

When comparing costs, environment differences can interfere with results. The same bug may yield different test outcomes when the language version or database version changes. When a model fails the first time, sometimes the code is wrong, sometimes the dependency version is inconsistent; these two kinds of failures should not be counted together.

ServBay can fix PHP, Node.js, Python and other language versions on your local machine, and also fix database and site configurations. Once the acceptance environment is fixed, each model's attempts run under the same conditions, making attempt counts and pass rates comparable.

Moreover, ServBay AI Gateway is suitable as a unified local entry point: virtual keys are used for calls, while real keys stay on the gateway side; usage, cost, and latency can be aggregated, and Claude Code, Codex, etc. can be switched to the same local entry. OpenAI / Anthropic / Gemini compatible protocols all have corresponding paths.

Summary

Terra pushes price, speed, and programming capability forward simultaneously; that is clear from official data. But official data comes from specific benchmarks; whether your own tasks save money must be answered with your own acceptance criteria.

Model competition is shifting from comparing benchmark scores to comparing how much money and time it takes to complete a task and whether it can be delivered reliably. For developers, the more practical approach is to take a reproducible bug, record tokens and human time for each attempt, calculate the cost per accepted task, and then decide which model to use.