Whenever I audit a computer-use workflow in staging, the first thing I inspect is the system-of-record entry the agent leaves behind—never the raw token bill. In my experience, a low-cost run that saves the wrong invoice fields, or reports completion without committing a record, is the most expensive failure mode an operations team can inherit.
GPT‑6.1 Terra makes visual reasoning and computer use a practical cost question. To answer it, follow one invoice-draft workflow from screenshot to saved record, separate the billable pieces, and divide the full workflow cost by verified outcomes. The worked examples below show why a $35 token estimate and a usable automation budget are different numbers.
- Did the correct, permitted result reach the system of record?
- Did the budget include all turns, failures, infrastructure and human help?
- Were repeated attempts counted as one assigned task rather than extra successes?
Why a screen task costs more than one model answer
Because a screen-driving loop couples visual observation, UI action selection, and downstream state mutation, its unit economics look nothing like a single-turn chat endpoint. Screenshots re-enter the context window on every step, and a single misclicked field can force an entire multi-step retry or human reconciliation pass.
Consider a fictional accounting team that needs invoice drafts entered into a legacy application. The requested outcome is a draft with the right supplier, invoice identifier, currency and amount, ready for a person to approve. Paying the invoice is outside the task. This distinction defines both the success check and the agent’s permitted scope.
The Computer use guide describes a loop: the model requests actions, the application executes permitted input, and an updated screenshot returns to the model. A completed computer call means the model finished generating that call; the application still has work to do. More observations and recovery turns can add cost before there is any saved result.
Read Figure 1: Follow the outer workflow, not just the model box. Verification can end the task; an unresolved screen state should lead to a bounded recovery path rather than unlimited clicking.
If a stable application programming interface (API) can create the same draft directly, I would evaluate that route first. An API is a defined software interface; it can avoid dependence on button positions and page layouts. Screens remain useful when the authorized task has no suitable integration route. Neither route removes the need to check what was saved.
What Terra changes—and what its specification does not promise
OpenAI describes gpt-6.1-terra as a fast, efficient model for visual reasoning, computer use and writing. Its GPT-6.1 Terra model specification lists text and image input, text output, a 1,050,000-token context window and a 128,000-token output limit. Tool calling requires the Responses API. Its reasoning settings are none, low, medium (default), high, xhigh and max.
These are supported capabilities and limits, not a guarantee that a particular invoice layout will be handled correctly. A context window is the amount of material a request can accommodate; it is not a target amount to send. Reasoning effort is a configuration choice to evaluate, not a permission setting. This article does not infer a local success rate from a vendor benchmark or claim that greater effort necessarily improves this workflow.
Build a token ledger without counting screenshots twice
Start with the usage reported for each request. The Images and vision guide explains that images become billable input tokens. Do not add a separate image-token estimate on top of an input total that already contains those images. Image dimensions, detail settings and model-specific preprocessing affect the estimate; counting screenshots alone cannot determine the bill.
Caching reuses eligible input content. The Prompt caching guide separates cache reads and writes inside total input. With total input T, read tokens R and write tokens W, ordinary input is T − R − W. Apply one appropriate price to each disjoint bucket. If both write lifetimes occur, split writes by lifetime rather than charging their aggregate again.
Read Figure 2: The large box is one input total. The smaller buckets are parts of it, not additional input. Output and infrastructure belong outside that box.
Listed Standard prices, in US dollars per million tokens, are:
| Bucket | At most 272K input | More than 272K input |
|---|---|---|
| Ordinary input | $1.00 | $2.00 |
| Cache read | $0.05 | $0.10 |
| 30-minute write | $1.25 | $2.50 |
| 12-hour write | $2.50 | $5.00 |
| Output | $5.00 | $7.50 |
These are the model page’s rates, checked October 27, 2026. Above 272K input tokens, the full request uses doubled input/cache rates and 1.5× output rates. Fast mode is 2× Standard; Batch/Flex are 50% lower; regional processing adds 10% where available. Availability and workflow constraints still need checking. An interactive UI loop cannot simply be assumed to work as a delayed batch job.
The long-context boundary applies to a request, not the monthly total
Suppose one request contains 272,000 ordinary input tokens and produces 1,000 output tokens. Its estimated token cost is 0.272 × $1 + 0.001 × $5 = $0.277000. With 272,001 ordinary input tokens and the same output, the estimate becomes 0.272001 × $2 + 0.001 × $7.50 = $0.551502.
The higher rate does not apply only to the single excess token. Conversely, a month containing millions of tokens across short requests does not by itself put every request in the long-context band. Keep request-level input totals in the ledger before aggregating costs.
Read Figure 3: The break in the pricing curve comes from a rate change, not a sudden change in model speed. The two adjacent calculations isolate that rule.
For screen workflows, history management matters because later turns may include earlier context. Do not estimate the whole job from the first screenshot. Also do not claim savings merely by cropping away information: a cheaper image that hides the currency or active account can cause a more expensive error. Evaluate any image or history reduction against the same saved-state checks.
Worked budget: how $35 becomes a $600 workflow estimate
Assume a planning cohort of 10,000 unique assigned invoice-draft tasks. The initial estimate assigns 2,000 ordinary input tokens and 300 output tokens to each task: 20 million input tokens cost $20 and 3 million output tokens cost $15, totaling $35. That is $0.0035 per assigned task before additional work.
For this worked budget, assume all requests remain in the Standard short-context band and all input is ordinary, uncached input. Budget extra turns—including screenshot input and retries—as another 10 million input tokens and 7 million output tokens. Set aside $120 for browser infrastructure and 20 hours of review at $20 per hour. These are planning assumptions, not Terra measurements. Taxes, financing, setup/migration work and any separate tool-service charges are outside this scoped example and must be added if applicable.
| Cost item | Assumption and calculation | USD |
|---|---|---|
| Baseline model usage | 20M input × $1/M + 3M output × $5/M | $35 |
| Additional model usage | 10M input × $1/M + 7M output × $5/M; includes images/retries | $45 |
| Browser infrastructure | Assumed cohort allocation | $120 |
| Review and remediation | 20 hours × $20/hour | $400 |
| Scoped workflow total | $35 + $45 + $120 + $400 | $600 |
Read Figure 4: The bar is proportional to the assumed dollars. Review dominates this example; that is a consequence of the assumptions, not a general claim about Terra deployments.
Retry cost is already inside the additional model-usage row. If a production ledger records every request, do not add a second blanket retry surcharge. Apply the same principle to screenshots, cache writes and reasoning usage: use the billable categories once, not several overlapping labels for the same work.
A useful denominator counts outcomes, not clicks or attempts
Now assume 8,600 tasks finish automatically and pass the saved-record checks, 600 finish after human correction, and 800 remain unresolved at the cohort’s reporting cutoff. Those mutually exclusive groups sum to 10,000. The 600 assisted outcomes count as completed, but they must not be described as autonomous successes.
The scoped cost per verified task is $600 ÷ (8,600 + 600) ≈ $0.0652, compared with $0.06 per assigned task. Both figures answer valid but different questions. Report the 86% straight-through completion rate and 8% unresolved share alongside cost, so a low price cannot hide excessive human work or unfinished cases.
Read Figure 5: The two successful branches join into 9,200 unique outcomes. The failed branch contributes cost to the numerator but no completed task to the denominator.
A task can have several attempts. Keep one stable task identifier through retries, and count its accepted outcome once. Fix the reporting cutoff: if an unresolved task finishes later, update the cohort and its later costs together. With zero verified outcomes, cost per verified task is undefined—not zero. Report spending and failure information instead.
This also explains why a more expensive model could still be economical: fewer failures or review minutes might offset its higher token bill. The reverse is equally possible. Compare models on the same tasks, permission rules, time limits and completion checks, rather than substituting a generic leaderboard score for local outcomes.
Permission before action; proof after saving
The draft-entry example needs two separate checks. Authorization asks whether the step is allowed before it runs. Verification asks what actually happened afterward. An invoice screenshot or a model’s reassuring completion report is not sufficient for either check.
I would give this proposed workflow an account that cannot make payments or alter supplier bank details. Application policy should resolve the current origin, screen and target from trusted runtime state, not from a model-provided target_semantic_id. An invented tag such as “safe click” must not bypass review. A domain allow-list alone does not constrain which operations are available inside that domain.
Read Figure 6: The left gate protects authority. The right readback checks saved facts. A successful cost denominator requires both, even when a model says it is finished.
Bind an approval to the actual action, record and current state; a global human_approved = true flag is too broad. Stop if the page changes before execution. Enforce permissions in the account and application backend as well as the UI handler. Treat instructions found in an invoice or web page as document content, not new authority.
After a save, compare the system-of-record fields with the trusted task: invoice and supplier IDs, currency, amount in integer minor units, allowed draft status and duplicate count. If a timeout leaves the save result uncertain, reconcile by the task/invoice identifier before clicking Save again. If no reliable readback exists, keep the outcome unverified and route it to a person. A blocked unauthorized action is a successful control event, but not a completed invoice task.
Test the economics with the same acceptance contract
The Evaluation best practices recommends task-specific evaluation, representative examples and continuous testing. For this workflow, I would begin with a staging copy: clean invoices, ambiguous totals, multiple currencies, changed layouts, expired sessions, duplicate invoice IDs, misleading document instructions and a save that times out after reaching the server.
- Define acceptance first. Specify required saved fields, allowed status, permission boundaries, reporting cutoff and a maximum time/step budget.
- Hold the comparison steady. Use the same tasks and constraints for each model/effort setting. Separate normal invoices from failure cases; report sample size and outcome definitions.
- Log the whole cohort. Retain request usage and rates, infrastructure allocation, review minutes, blocked actions, retries, unresolved outcomes and duration—not sensitive invoice contents unless necessary and authorized.
- Promote in stages. Move from staging to limited supervised draft entry only after correctness and permission checks pass. Compare full cost with the existing process, including reviewer time and deadline requirements.
Do not trade away permission controls to reach a cost target. And do not treat a small clean test set as proof of rare-error safety. Model updates, page redesigns and policy changes can invalidate a previous result, so recheck the acceptance contract when any of them changes.
The practical conclusion
Terra’s listed rates help estimate the model portion of a screen workflow. The decision to deploy depends on a larger unit: one correct, permitted task with evidence of persistence. Start with a bounded draft-entry task, meter disjoint costs, and keep assisted and unresolved outcomes visible. Only then can “lower cost” mean something a reader or operator can verify.
Sources and scope
Official documentation checked October 27, 2026: GPT-6.1 Terra model specification; Computer use guide; Images and vision guide; Prompt caching guide; Evaluation best practices. Product capabilities and listed rates come from those documents. The invoice workflow, budget, outcome counts and controls are editorial proposals and worked examples. No live Terra workflow benchmark or customer deployment is claimed.