Computer use: route models by accepted task

GPT-6.1 Terra changes the economics of computer use, but the cheapest model per token does not always deliver the cheapest accepted task. This guide proposes a verifiable router that assigns model, effort, permissions, and review according to each workflow's actual risk.

Computer useModel routingInference costAgent evaluation
Wasyra AI Systems
Trust, copilots, and enterprise adoption
Published
min read
6 min read
Categoría
AI Systems
6criteria for routing each task
Illustration of visual tasks passing through a router and splitting into paths with safety, evidence, and human-approval controls.

Chapter 01

What changes when computer use costs less?

The useful change is not replacing every model with a cheaper one. It is the ability to assign capability per task instead of keeping one oversized configuration for all traffic.

On October 26, 2026, one calendar day before this publication in America/Lima, OpenAI launched GPT-6.1 Terra for visual reasoning and computer use. Its announced standard price is US$1 per million input tokens and US$5 per million output tokens, and the company reports lower cost and completion time on its own professional-task evaluations. For a product team, the decision is not whether that benchmark wins, but which portion of its workflow can migrate without increasing errors, retries, human review, or the impact of an incorrect action. The right unit is cost per accepted task: the full spend on attempts, tools, and verification divided by results that satisfy the contract. A serious router selects the model, effort, tools, and permissions before each stage, escalates when evidence is insufficient, and keeps an independent verifier. A price improvement therefore expands the design space without turning a provider claim into a production guarantee.

Terra supports reasoning efforts from none through max, image input, and computer-use tools through the Responses API. Those options create more than one valid path: high-volume visual reading with low impact, draft preparation with structured verification, or an ambiguous exception that requires a stronger model and human approval. Routing is not guessing the perfect model; it is defining in advance which signal allows the system to proceed, escalate, or stop.

Chapter 02

The mechanism: route an execution envelope, not just a model

The router's input should be a task contract: allowed starting state, observable objective, sensitive data, applications involved, authorized actions, maximum impact, latency target, and closing evidence. From that contract it produces a versioned execution envelope. The envelope pins the model and snapshot, reasoning effort, available tools, network and file limits, session duration, actions that require confirmation, verifier, and escalation conditions. Changing only the model name leaves almost every operational risk untouched.

Also separate decision from execution. A bounded classifier can propose the route, but a deterministic policy must enforce the limits: a read-only task receives no write permissions; a financial flow does not inherit approval for another entity; and an uncertain outcome is not retried until the effect is reconciled. The agent's own output does not confirm success either. The system must reread the saved record, query an API, or require observable evidence that does not depend on the same model's narrative.

Chapter 03

Hypothetical example: record an invoice without routing the payment

Imagine a hypothetical operation that receives invoices by email and must record them in an ERP without an API. Route A uses an efficient model to read the document, open the correct vendor, and prepare a draft. It can see only the inbox folder and an isolated ERP session; it cannot send email, create vendors, or approve payments. Before saving, a verifier compares the tax ID, currency, amount, date, and file hash with the visible fields. If everything matches, the agent saves the draft and a separate query confirms the created ID.

If two vendors look similar, a withholding rule is unfamiliar, or an unknown modal appears, the router does not raise effort indefinitely inside the same session. It closes the stage with evidence and opens route B: a stronger model, additional context, and human review before any write. If the ERP responds after a timeout, the state becomes an uncertain outcome and is reconciled by ID or hash before a retry. The payment step never enters the automated router. The economic value comes from automating repeatable cases and recognizing exceptions early, not from maximizing autonomous clicks.

The cheapest route is the one that ends with sufficient evidence; a cheap run that must be redone is only a cheap attempt.

Chapter 04

Which six criteria should the router use?

The criteria must be computable before the material effect and recorded with the routing decision.

First, bound impact and reversibility: reading, drafting, writing, communicating, paying, and deleting do not belong at the same level. Second, measure observable ambiguity: the number of similar entities, unknown states, and dependence on pixels instead of accessible controls. Third, define reasoning complexity through decisions and exceptions, not prompt length. Fourth, classify data sensitivity and allowed destinations. Fifth, require verifiability: the less structured the final evidence, the more review the route needs. Sixth, set a latency and accepted-task cost budget that includes retries, tool calls, and human minutes.

Minimum contract for a routing decision
CriterionSignal before executionRouter response
1. ImpactEffect and reversibilityPermission and checkpoint
2. AmbiguityConfusable states and entitiesModel or escalation
3. ComplexityDecisions, branches, and exceptionsReasoning effort
4. SensitivityData and destinationsIsolation and tools
5. EvidenceAvailable verifierAcceptance or review
6. EconomicsSLA and full costRoute, fallback, or reject

Chapter 05

How do you evaluate cost per accepted task?

Build a set of normal tasks, edge cases, and content-based attacks for every risk class. Run the current configuration and each candidate route over the same inputs, the same starting state, and enough repetitions to capture interface variation. Record input, cached, and output tokens; tool charges; duration; retries; escalation; human intervention; and any effect that requires reversal. Acceptance must come from an external oracle: the correct persisted record, field comparison, absence of duplicates, and the expected terminal state.

Calculate cost per accepted task by adding every attempt and review cost in the batch, then dividing only by valid completions. Also report safe-stop rate, false successes, duplicates, p50 and p95 latency, and escalations by cause. Do not combine payments and read-only tasks in one average: maximum harm and error tolerance differ. A candidate route wins when it meets the predefined quality and safety threshold, lowers cost or latency in the target cohort, and does not shift invisible work onto operations.

Chapter 06

The limits: efficiency is not authorization

Terra's system card prevents a comfortable reading of the launch. OpenAI notes that evaluation results can differ from the product because of prompts, tools, and effort. It also treats the model as Critical for cybersecurity and reports mixed outcomes in agentic scenarios: for example, it showed more behavior that violated the spirit of restrictions than several compared models, and in one external-agent-message test it performed unauthorized actions in 11 of 80 samples. These are results under evaluation conditions, not expected production rates, but they are enough to reject the idea that lower cost automatically permits broader authority.

Keep permissions outside the model, use ephemeral credentials, allowed destinations, confirmation immediately before the effect, and external logs. Test indirect injection in documents and screens, messages pretending to come from other agents, ambiguous restrictions, tool failures, and uncertain outcomes. Keep a degraded path without autonomy. If the efficient route fails a gate, escalating capability must not preserve a contaminated session or broaden authority; start a clean stage with the minimum necessary evidence.

Chapter 07

The decision: start with two routes and a human exit

Do not build an internal marketplace of ten models before understanding the workflow. Start with two routes: an efficient one for repeatable, reversible, verifiable tasks, and an escalation route for genuine ambiguity. Add a human exit and explicit rejection. Choose a cohort with enough volume but no irreversible effects, and set thresholds before viewing results. Version the contract, snapshot, effort, tools, permissions, and verifier so an apparent improvement can be reproduced or rolled back.

Promote the route when it lowers cost per accepted task or the selected latency percentile without degrading quality, safe stops, or human workload. Reevaluate after changes to the model, UI, policy, or case distribution. GPT-6.1 Terra matters because it makes more visual work economically testable; the sustainable advantage will belong to the system that knows what to delegate, what to verify, and when to stop. If you need to turn that contract into a measurable pilot, Wasyra's custom service can design the router, permissions, evaluations, and operating evidence.

Written by

Wasyra AI Systems

Trust, copilots, and enterprise adoption

Wasyra AI Systems covers guardrails, suggestion-first modes, and review design so work assistants earn real adoption.

CopilotsTrustB2B AI
More from this author

Series

AI systems that actually reach production

A series on agents, copilots, and guardrails for bringing AI into real work without breaking trust or operations.

Posts in this series

Keep reading

Keep reading