GPT-6.1 Terra and the Real Metric for Computer-Use Agents: Cost per Task, Not Price per Token

OpenAI released GPT-6.1 Terra on October 26, 2026: a fast, mid-range model aimed at computer use (reading screens, clicking through apps, filling in forms) plus visual reasoning and coding. The headline is a price cut. The more useful lesson for anyone building agents is hidden in how OpenAI chose to describe it: cost per task, not price per token.

This post covers what was announced, why per-token price is the wrong number for agent workloads, and how I'd evaluate a model like Terra before routing real work to it.

All benchmark figures below are OpenAI's own reported numbers. Treat them as claims until independent evals land.

What was announced

• Model: gpt-6.1-terra in the OpenAI API, and in ChatGPT Work and Codex for Plus, Pro, Enterprise and Edu users.
• Pricing: $1 per million input tokens, $0.05 per million cached input tokens, and $5 per million output tokens. OpenAI says standard API prices are 50% lower than GPT-5.6 Terra and GPT-6.1 Sol. (DailyAI lists GPT-5.6 Terra at $2 input / $12 output per million.)
• Computer use (Agents' Last Exam): at medium reasoning effort, 15 percentage points higher than GPT-5.6 Terra at about one-third the cost, and on par with GPT-6 Astra at one-tenth its price per token.
• Versus Claude Opus 5.5 at max effort: over 3x more token efficient and one-fourth the price per token, which OpenAI says works out to a ~9x lower cost per task.
• Speed: completes tasks over three times faster than GPT-6 Astra and GPT-6.1 Sol.
• Factuality: on OpenAI's internal error-inducing prompts, the error rate at low effort fell from 53.6% (GPT-5.6 Terra) to 16.7%; at max effort it fell by 18 points to 4.3%.
• Coding: Terminal-Bench 4.0 at max effort, 50.3% vs GPT-5.6 Terra's 21.5%. OpenAI itself says GPT-6.1 Sol and GPT-6 Astra remain the better choice for the most complex coding tasks.
• Safety: meets the Critical cybersecurity threshold under OpenAI's Preparedness Framework, keeps the protections built for GPT-6 Astra, and showed strong resistance in OpenAI's prompt-injection tests.

Why price per token misleads you on agent workloads

A chat completion is one call. A computer-use task is a loop: look at the screen, decide, click, look again, recover from a wrong click, and so on. The bill for that task is roughly:

cost per task = (tokens per step x steps per task x price per token)
                / success rate

Every term matters:

1. Price per token is the only term on the pricing page.
2. Tokens per step depends on how much the model "thinks" and how verbose it is. OpenAI's claim that Terra is 3x more token efficient than Opus 5.5 is about this term.
3. Steps per task depends on how often the model clicks the wrong thing and has to recover.
4. Success rate is the big one. A cheap model that fails half the time costs twice as much per finished task, plus the cost of a human cleaning up.

That's why the "~9x lower cost per task" line is the interesting one: it multiplies the 4x price gap by the 3x token-efficiency gap. Neither number alone tells you what the work costs.

Speed is a cost too

"Three times faster" sounds like a UX metric, but for agents it's operational. Long-running browser or desktop tasks hold sessions, VMs and sandboxes open. A task that finishes in a third of the time ties up a third of the infrastructure, and a user waiting on an agent is far more likely to abandon a slow one.

Factuality matters more when the model acts

A chat model that hallucinates gives you a wrong paragraph. A computer-use model that hallucinates enters a wrong invoice number into your accounting software. The drop in OpenAI's internal error rate (53.6% to 16.7% at low effort) is the kind of number I'd want to re-measure on my own tasks, because errors in agent loops turn into side effects, not just bad text.

How I'd evaluate Terra before switching

1. Build a task set, not a prompt set. Take 30-50 real tasks your agent does (fill this form, extract these invoice fields, update this record) with a checkable end state.
2. Measure cost per successful task. Log input, cached input and output tokens per run, multiply by price, and divide by the number of tasks that actually reached the correct end state.
3. Test reasoning effort as a dial. OpenAI reports different results at medium and max effort. Run your task set at each effort level; the cheapest setting that hits your success bar wins.
4. Track p95 time per task, not average. One stuck run can hold a sandbox for minutes.
5. Route by difficulty. OpenAI's own guidance is that Sol and Astra remain better for the hardest coding. A sensible pattern is: Terra for high-volume, bounded computer-use work; a frontier model for the hard tail; and an escalation rule between them.
6. Keep permissions outside the model. Better prompt-injection resistance is welcome, but an agent that can click "submit" still needs allowlists and approval for irreversible actions.

The takeaway

Model launches are increasingly about efficiency, not just raw capability. When you read the next launch post, ignore the price-per-token line until you've found the cost-per-task number, and then re-measure that number on your own workload before you trust it.

What metric do you use to compare models for agent work today?

References

• OpenAI, "Introducing GPT-6.1 Terra" (Oct 26, 2026): https://openai.com/index/introducing-gpt-6-1-terra
• DailyAI, "DAI#60 AI News Roundup: Anthropic IPO, Meta's $95B, GPT-6.1 Terra": https://dailyai.com/2026/10/dai60-anthropics-books-metas-hat-and-a-cheaper-terra/
• Writingmate, "AI News, Week of October 26": https://writingmate.ai/blog/ai-news-week-of-2026-10-26

Comments

[Auten]

Do you split cost per task into the first run and the repeats? The bounded, high-volume work you'd route to Terra is often the same form filled hundreds of times, and a recorded run can be replayed step by step with no model call, so the token price mostly matters for the first run and for the runs where the app changed. Asking from the Auten team (a computer-use MCP that works that way), so for us the number to watch is the share of runs that need the model at all.

[M.T.Ramkrushna]

Yes, I'd split them: first-run cost (including retries and the model calls needed to build the recording) versus repeat-run cost, plus the share of runs that fall back to the model after a UI change. Per-task cost averaged over both hides the real picture, because replay-heavy workloads are dominated by the fallback rate, not token price. For one-off or highly variable tasks the token price still decides, so I'd track both numbers per workflow.

[Auten]

Agreed, the fallback rate is the number that moves the bill. One refinement we found useful: count fallbacks per step, not per run. When one step breaks after a UI change, repairing just that step from where it failed costs a fraction of re-running the whole task with the model, so a run with one healed step should not be booked as a full model run. Would you track partial fallbacks separately, or fold them into the same rate?

[M.T.Ramkrushna]

Per-step is the better unit, and I'd track partial fallbacks as their own rate: a step-level repair is cheap, but if it fires every run after a UI change it signals a brittle recording that still needs fixing. Booking it separately also keeps the full-model-run rate honest.

[Auten]

That's a good line to draw: a repair that fires on every run isn't a cheap fix anymore, it's a recording that needs redoing, and booking it separately is what makes that visible. Thanks for the back-and-forth, this was one of the more useful cost threads on here.