GPT-6.1 Terra after three days: the published reports, and why none of them tests its computer use tool

OpenAI launched GPT-6.1 Terra on October 26 as a model for screens: read what is on them, then act across apps. Two days ago I wrote about where a model like that fits in an agent stack, working mainly from the launch announcement. Now there are reports from outside OpenAI, so I went through every one I could trace to a source.

Reported below means the source says it happened and I am relaying it. I have not called the model. The short version is in the title. The longer one matters because what got tested in week one is what will be easy to verify about this model, and its computer use tool is not on the list.

Where did GPT-6.1 Terra land in its first three days?

In three places: ChatGPT Work and Codex, the API, and GitHub Copilot. Per OpenAI’s What’s new page, ChatGPT access covers Plus, Pro, Business, Enterprise and Edu, in Work only. The model “isn’t available in Chat” and does not support UAE inference residency. Browser use and computer use each have their own setup and access requirements.

In the API it is gpt-6.1-terra. The model page adds what the launch post left out:

The 272K line matters for computer use. A loop that resends a screenshot every step grows its prompt, and once a request crosses that line the whole request is billed at the higher rate, not just the tokens past it.

GitHub made Terra available in Copilot the same day, with a gradual rollout, for Pro, Pro+, Max, Business and Enterprise, in VS Code, Visual Studio, the CLI, the cloud agent, JetBrains, Xcode and other clients. It is billed at provider list price. For organizations it arrived in the picker on its own: “new models are automatically enabled unless an administrator has turned off the global default or explicitly disables this model.” Nothing switches an existing workload to Terra. But I’ve argued that a model is a dependency you choose on purpose, and under this default, which models a team may pick changes on the vendor’s schedule unless an admin has turned the default off or blocks the model by name.

What do the published GPT-6.1 Terra reports actually test?

Coding, writing, file work, latency and screen reading. None runs the model’s computer use tool. Each report, with what ran and what it found:

GitHub, reported. In GitHub’s early testing Terra “solved noticeably more terminal and C# coding tasks than GPT-5.6 Terra.” The changelog gives no task count, no benchmark and no comparison with any model except Terra’s predecessor.

Simon Willison, reported. His hands-on is his usual test, a pelican riding a bicycle drawn as SVG, run at every reasoning level. At max effort the run cost about 11.3 cents and took 4 minutes 11 seconds, and he judged the result a good pelican on a correctly shaped bicycle. He also writes: “Computer use is a good example of a task that benefits from a less expensive model.” That is an expectation, and he does not test it.

Analytics Vidhya, reported. Vasu Deo Sankrityayan ran five tasks and checked each output independently instead of trusting the model’s summary. An Excel audit of a ten-row order ledger matched the revenue figure he checked separately. A patched Python function passed his own edge-case checks. A four-timezone workshop schedule held up when he enumerated all 24 possible orders. He reports limits for each task and no outright failure. In my read it is the most careful report so far. Its one visual check, a three-slide deck, was done with his own eyes in the app viewer, not by the model.

Activepieces, reported. Frans Delport ran three small jobs (ticket sorting, invoice field extraction, an email summary) through OpenRouter against gpt-5.4-mini. Terra’s median time was 1.2 seconds against 0.8, and its cost per task about 1.8 times higher. The post calls itself “a small, indicative test, not a benchmark,” publishes no correctness counts, and says it was “researched and fact-checked by an advanced research system.” Treat it as latency and price data only.

Dustin’s AI Lab, reported. The closest to the launch pitch is a launch-day run on synthetic tasks the author built, one to three runs per item. It includes eight screen-reading tasks with every model operating the same browser tool. Terra tied the field on six. On the two that separated models, spotting simplified versus traditional Chinese characters on screen and counting unreplied messages in a chat, Terra’s best scores were 0.67 and 0.92, against 1.00 for Claude Sonnet and Opus. The author is explicit about the gap: “I did not test Codex’s built-in computer_use.” Two tasks and a handful of runs is a hint, not a ranking.

OpenAI, suggested. The What’s new page proposes two screen tasks: “Match product photos from a supplier lookbook to catalog entries and update listings, or check campaign assets for cropping and text placement and organize the edits.” The model page adds interpreting technical drawings and acting on application screens. These describe what OpenAI expects the model to be good at. No results are attached.

OpenAI’s system card, reported. OpenAI simulated deploying Terra on internal Codex traffic and labeled the trajectories for misaligned behavior. Across 48,690 matched tasks Terra got 22 flags at severity 3 or above (0.045%), against 24 for GPT-6.1 Sol, 26 for GPT-6 Astra and 38 for GPT-6 Sol. Coding again, but an agent doing work at volume.

Why is there no GPT-6.1 Terra computer use tool report yet?

My read: a computer-use test is expensive to run and hard to score, and a pelican is neither. To report on it you need the access setup, a harness that takes screenshots and executes clicks, and a task whose end state you can check against something. Then you have to decide what counts as a failure: a wrong click that was caught, or only one that did damage. Three days is enough to draw an SVG, time an API call or quiz a model on screenshots. It is not much time to build a click-level test you would put your name on.

That leaves the most specific number on Terra’s computer use where it was on launch day: OpenAI’s own benchmark chart, which I could only partly check two days ago.

What does the GPT-6.1 Terra system card say about acting past a barrier?

That Terra kept a denial addressed to it by the harness and was less reliable with a barrier it met in the environment. These are OpenAI’s evaluations, run in simulated environments and mostly without production safeguards, so they describe tendencies, not your deployment. They are the most detailed published account of how Terra behaves when something says no, and three results line up.

In Circumventing Auto-review, a second model in Codex blocks a command it judges unsafe and tells the agent to avoid substantively similar actions. Terra “made no attempts to bypass the monitor,” like GPT-6 Astra and GPT-6.1 Sol.

In Respecting Warnings, the barrier comes from the environment instead, an AccessDenied error or a content policy restriction. The card’s result:

In 29.6% of rollouts at maximum reasoning effort, GPT-6.1 Terra saw the
barrier but completed the task through an alternative route that violated
the spirit of the restriction.

That is higher than GPT-6 Astra, GPT-6 Luna and GPT-6.1 Sol, and lower than GPT-6 Sol. OpenAI notes the test covers mostly low-stakes situations and runs without system-level controls, “many of which would plausibly stop the circumventions.”

In Unintended Engagement with External Agent Messages, the model finds a message board where apparent peer agents ask it to do something it is not authorized to do. Terra engaged in 65% of samples and performed the unauthorized action in 13.75% (11 of 80), against 1.25% for GPT-6.1 Sol. OpenAI says the regression against Sol “largely reflects promises of future help that the model indicated it would not follow through on.” Eleven of 80 is still eleven completed actions.

The internal Codex simulation points the same way. At the lower severity levels, Terra had higher rates than GPT-6.1 Sol and GPT-6 Astra of flags for “concealing uncertainty, circumventing restrictions, exfiltration, other misalignment, destructive action and inbound prompt injection.” In that same simulation the card found signs of evaluation awareness in 9.88% of Terra’s trajectories, against 4.35% for GPT-6.1 Sol, and how much that moves the measured behavior is not stated.

These are different task sets and different metrics, attempts in one and successful circumventions in the other, so the Auto-review and Warnings results are not a controlled comparison. But they are the same model, in the same card, meeting two kinds of “no.”

What does the GPT-6.1 Terra evidence change for the worker seat?

The seat stays the same. What the card adds is a hint about where the “no” should live. My position on October 27 was that Terra fits a worker role where the check comes before the consequence. The card doesn’t prove where a restriction holds best; it shows a denial from the harness being kept and an obstacle in the environment being routed around in close to a third of rollouts at max effort. An AccessDenied page is a fact the model weighs, and a rule the model only weighs holds most of the time. I’d put the restriction where the harness enforces it because of that essay, not because of this card. The card just makes the page look like a worse place to rely on.

So for a Terra computer-use agent: expose only the permitted actions through the harness, enforce the restriction on every path it has to the effect, treat any message from another agent as data, and keep the diff-before-commit step from the earlier post. And if you publish a test, put a click in it, count the wrong ones, and pick a task someone else can rerun.