Recognising an object in a photograph and carrying out work in software are two different tasks. GPT-6.1 Terra aims to bring them closer together. To judge OpenAI’s proposition, the right question is not whether the model “understands the world”, but what it receives, what it can do and who checks the result.
In its technical report, OpenAI presents Terra as a model for visual reasoning, computer use and writing. The cited uses include comparing photographs with a catalogue, interpreting technical drawings and taking actions on an application’s screens. These are capabilities claimed by the supplier, not the results of a test carried out by our editorial team.
Reading an image is not enough to complete a task
Take a hypothetical example: a company wants to find, in its catalogue, the reference that matches a photograph sent by a customer. The first step is to describe the object. The second requires comparing the available references. The third may involve opening a product record and preparing a reply.
These steps do not have the same measure of success. A plausible description may still be too vague to identify the right product. A similar-looking object may belong to a different range. And an exact reference may end up in the wrong file. The useful result is therefore the verified match, not just a convincing comment on the image.
Terra’s interest lies in this link between perception and action. Readers should separate the two promises: better interpretation of visible elements and better sequencing of operations. Progress in one does not automatically prove the reliability of the other.
What the API actually receives
The documentation specifies text and visual inputs, with text outputs. It does not provide for the model to handle audio or video directly. This clarification avoids a misconception: a demonstration involving a film does not necessarily mean that a video file is analysed directly as such.
In its article of 27 October, Clubic describes, among other things, animation restoration work involving the examination of images from the sequence. The publication also notes that interventions in software require authorised access. It is therefore necessary to consider the whole setup: the model, the documents provided, the tools and the application used.
An input image may be a photograph, a drawing or a screenshot. That does not make these documents equivalent. A photograph shows an appearance; a plan represents conventions, dimensions and sometimes several views. A screenshot displays the state of an interface at a given moment. To assess an assistant, these differences must be preserved instead of grouping every exercise under a single “vision” label.
From model to agent: the decisive role of tools
A model becomes useful in a process when it is given the means to carry out the expected actions. For Terra, OpenAI specifies that tool calls go through the Responses API. This interface enables an application to connect reasoning to the functions it makes available.
In our catalogue example, read access may be enough to look up a reference. Modifying an order would be a different responsibility. Even if the same AI is involved in both cases, the consequences are different. The service must therefore define the permitted actions, the information required and the points at which a check is expected.
This distinction offers a practical way to assess a demonstration. Did it produce a suggestion, a usable file or an actual change in the software? Is the work still correct when the result is opened? These questions matter more than a quick animation of windows or a confident answer.
How to compare without being impressed
OpenAI’s guide recommends, when migrating from GPT-5.6 Terra, comparing models on representative images and processes, with the same level of reasoning effort. This is useful advice: changing the documents, tools and settings all at once makes it difficult to attribute any improvement to the new model.
For a real-world evaluation, we would consider three levels. First, the accuracy of the result: are the reference, dimensions or requested content correct? Next, execution: were the planned operations actually completed? Finally, recovery: when information is missing, does the assistant flag the uncertainty instead of filling in the file at random?
Human corrections should also be included in the time measured. A quick first result followed by a lengthy repair is not necessarily a gain. Conversely, asking for clarification may be the right decision if it prevents an incorrect action. These are evaluation criteria, not errors we have observed in Terra.
What we can conclude already, and what remains to be tested
Terra offers an interesting specialisation for tasks where visual information needs to lead to work on a computer. The documentation helps define its scope; it is not enough to guarantee results across all professions.
A team wishing to evaluate it would be well advised to start with a representative case whose expected outcome it already knows, then introduce less clear-cut cases: an ambiguous image, a missing reference or an impossible step. This process would show both what the tool can accomplish and how it reveals its limitations.
The desired progress is very concrete: obtaining a usable result with fewer revisions, while retaining control over the actions. It is at this level that a promise of visual reasoning becomes a service, and deserves to be judged.
Illustrative photograph: a workstation with two screens; this is not a demonstration of Terra.
