A high benchmark score is one thing. Catching an impossible route on a trail map or spotting the revision that changes a release decision is another. When several rules need to hold at once, which model keeps track of the details and which one slips?
We put Claude Opus 5.5 and GPT-6.1 Terra through four demanding tasks at Max reasoning, covering visual reasoning, conflicting evidence, streaming code, and continuity across a long archive. Every response was checked independently. In this article, we compare their answers and see how each model handled the challenges.
TLDR: Opus 5.5 matched GPT-6.1 Terra across four independently checked tasks. Terra gave a shorter map answer and has the higher aggregate benchmark score; Opus produced a shorter parser.
What Terra and Opus 5.5 offer
GPT-6.1 Terra focuses on visual reasoning, computer use, and clear writing. Claude Opus 5.5 targets frequent, relatively small jobs such as classification, extraction, routing, and subagent work. Both accept text and images and produce text; file analysis depends on the application and its tools.
| Feature | GPT-6.1 Terra | Claude Opus 5.5 |
|---|---|---|
| API model ID | gpt-6.1-terra | claude-opus-5-5 |
| Context window | 1 million tokens | 1 million tokens |
| Standard maximum output | 128,000 tokens | 128,000 tokens |
| Reasoning in this comparison | Ultra | Max |
Our Opus 5.5 review covers its wider feature set. Here, the same work goes to both models, with correctness and instruction following checked separately.
Access and Max settings
Terra is available in ChatGPT Work and Codex on Plus, Pro, Business, Enterprise, and Edu plans, subject to access controls. It is not available in regular Chat. In Work, open the model selector, choose GPT-6.1 Terra, and set effort to Max. Recheck the selection after attaching files.
In Claude, choose Opus 5.5, open Effort, and select Max. Opus is available across Claude plans, including Free, with usage limits. Max effort is a reasoning setting; it is separate from the Claude Max subscription. The interface warns that this effort can use eight times or more usage.
For API use, Terra takes reasoning.effort="max". Opus takes output_config.effort="max" with adaptive thinking. Matching labels do not establish equal compute budgets.
Pricing and the cost of a finished task
| Standard API pricing per million tokens | Input | Output |
|---|---|---|
| GPT-6.1 Terra | $1.00 | $5.00 |
| Opus 5.5 up to 100K prompt tokens | $0.10 | $0.50 |
| Opus 5.5 above 100K prompt tokens | $0.50 | $2.50 |
At identical billable token counts on short prompts, Opus costs one-tenth as much. That is a rate comparison. Max reasoning, longer answers, tool calls, and retries can change the bill for a completed job. Terra also raises rates above 272K input tokens: input doubles and output rises by 50%.
These are API rates, separate from application subscriptions. We ran the hands-on tests in the applications and did not measure their API bills or compare end-to-end speed.
How we tested at Max
Both models received identical anonymous prompts and files in fresh chats at Max. We preset criteria, graded first available completed answers, repeated unavailable runs unchanged, and used no repair prompts. Apps could use tools; Max does not necessarily equalize compute.
Task 1: Finding an impossible route
The map task tests feasibility, a closed minimum-distance walk, and a conflicting unit label.
Prompt
Use only the attached map as a static network, not as live travel advice. Stay within the pictured network.
1. A proposed walk starts and ends at marker 23, visits markers 27 and 31, and never uses a trail segment twice. Is it feasible? Name one unavoidable repeated segment and explain why. Do not invent a route or distance if infeasible.
2. Independently, use only the pictured connections among 23, 24, 32, 33, and Scenic Overlook, including the orange 23–Overlook connector. Close Gas House Cutoff (24–32), allow retracing, and find the shortest closed walk from 23 visiting 24, 32, and 33. List its ordered points, each leg's mileage, total miles, and whether it meets a 6.3-mile cap.
3. Flag one inconsistent mile/kilometre pair printed on the map. Use miles for your calculation; do not silently repair the map.
Answer in at most 150 words. Keep the output anonymous: no personal names, organisations, contact details, account information, source bylines, or signature.
Terra 6.1 (Ultra):
Opus 5.5 (Max):
The no-repeat itinerary is impossible: reaching marker 27 from elsewhere requires using 26–27 in both directions. Closing 24–32 turns the allowed lower network into a tree. Each remaining edge must be retraced, producing a 6.4-mile minimum and missing the cap by 0.1 mile. The small 0.3-mile connector has to count twice.
Verdict: Tie on correctness, at 10/10 each. Terra used 93 whitespace-separated words and symbols against Opus’s 145; both met the 150-word limit.
Task 2: Rejecting a misleading release summary
Three release files test authority checks, pooled percentages, nearest-rank percentiles, unit conversions, and allocation rounding.
| Attached file | What the model must reconcile |
|---|---|
| release_rules.txt | Revision 3 is approved; revision 4 is a draft. All four gates must pass. |
| bench_results.txt | Supported hardware A/B, excluded prototype/debug results, an aborted startup, installed components and rollback times. |
| change_record.txt | The ready summary predates revision 3; waiver W-9 has not been approved. |
Prompt
Use only the three attached release-packet files. Decide whether candidate R7 may release at the 18:00 cutoff. For each of the four gates, report the correctly scoped metric, its governing threshold, and pass or fail. Show enough arithmetic to make the installed footprint auditable. Identify the governing revision and explain whether the earlier ready summary, revision 4, or waiver W-9 changes the decision. Use tools if helpful; do not use outside information. Keep the complete answer under 150 words. Keep all output anonymous: no personal names, organisations, contacts, account/profile information, local paths, or signature.
Terra 6.1 (Ultra):
Opus 5.5 (Max):
Both scored 12/12. Crash-free sessions were 99.96%; pooled startup p95 was the 19th of 20 samples, or 220 ms. Installed size was 1,310,720 + 122,880 + 65,536 = 1,499,136 bytes after component-wise rounding. All three passed. The slowest eligible rollback was 3.4 seconds against a 3.0-second limit, so the candidate had to stay on hold.
Neither let the stale summary, draft revision, or unapproved waiver override revision 3. Terra used 124 words and Opus 133, including their tables; both stayed under 150.
Verdict: Tie. Both handled the interacting rules and calculations correctly.
Task 3: Repairing a lazy streaming parser
This CSV state-machine repair requires handling split chunks/quotes/CRLF, rejecting bad quoting, and lazy yielding without read-ahead.
Prompt
Fix
parse_recordsin the attached Python file. Implement the full grammar and streaming contract in its module docstring. Chunk boundaries must not change the result, and completed rows must be yielded without reading ahead. Use no imports or outside information; you may use code tools to test your solution. Return only the implementation in one Python code block, at most 70 physical lines. Do not repeat the specification or include assertions. Keep the output anonymous: no personal names, organisations, contact details, account information, local paths, or signature.
Terra 6.1 (Ultra):
Opus 5.5 (Max):
Both implementations passed every prepared check. They preserved quoted line breaks, handled split CRLF and escaped quotes, rejected malformed input, and yielded a valid row before a later error. Neither imported libraries, buffered the whole stream, or retained previous rows. Terra returned 55 physical lines and Opus 44, both below the 70-line cap and both code-only.
The harness covers 202 documents: 24 handcrafted valid inputs, 18 malformed inputs, and 160 generated documents. They run through 4,153 different packetizations, plus four lazy-consumption checks. Those are repeated representations of the same underlying cases, not thousands of independent tasks. We also inspected for whole-stream buffering; this was not a measured memory benchmark.
Verdict: Tie on behavior and streaming compliance. Opus’s implementation is shorter; that alone does not establish better maintainability.
Task 4: Repairing a scene across a long archive
Across a 16,757-word, 64-record archive, models must delay one character, fix six continuity errors, and write a 60–80-word ending in under 150 words total.
Key constraints include the courier's injured right wrist, occupied left hand, two required operators, and the interlock closing at the second bell before the apprentice arrives at the third.
Prompt
Audit the proposed scene against the attached continuity archive. Approved corrections outrank drafts and recaps. New condition: the apprentice arrives at the third bell; change only that arrival. Keep only the keeper and courier at the gate. Begin with whether the lower gate can open before the tide window closes. Give six concise continuity fixes, then a corrected ending of 60–80 words. Add no people, mechanisms or equipment. Keep the complete answer under 150 words and use only the archive.
Proposed scene: At the first bell, the keeper and courier crossed the intact north stair in two minutes. The courier set the vial on a shelf and turned a wheel with the injured right hand. The copper key unlocked the other wheel. The keeper wedged it, raised a blue-glass lantern to read the silver instructions, and held the gate open alone. They crossed as the second bell sounded, although the apprentice was still away.
Keep output anonymous: no personal names, organisations, contacts, account/profile information, local paths, or signature.
Terra 6.1 (Ultra):
Opus 5.5 (Max):
Both scored 10/10. They applied the approved route and lantern corrections, preserved the vial and injury constraints, rejected the key and wedge shortcuts, and recognized that the delayed apprentice could not supply a second operator before the window closed. Neither invented a way through. Terra’s complete answer was 145 words, including a 67-word ending; Opus’s was 140, including a 63-word ending. Both met both length limits.
This tests file-assisted retrieval, correction precedence, and constrained writing. The archive is substantial, but it is far below the models’ million-token context limits. It does not establish performance near those limits.
Verdict: Tie. Both reconciled the scattered records and wrote an ending consistent with the new condition.
Conclusion
For the four workloads tested, Opus 5.5 delivered the same checked correctness as Terra at Max. Its lower API rates make it the practical first candidate when your tasks resemble these. Test it on your own failure cases before switching. Terra remains worth evaluating where the higher aggregate benchmark score translates into better results on your workload. This round found no capability failure to justify a universal winner, and no measured application cost saving.
For another capability step, see our Sonnet 5.5 vs Opus 5.5 comparison. Our ChatGPT vs Claude guide covers how the surrounding tools affect agent work.
Frequently Asked Questions
Did both models use Max effort?
Yes. Max was selected in each application. The same label does not imply equal compute budgets.
Do these tasks establish each model’s limit?
No. They are demanding, bounded tasks with independent checks, not an exhaustive search for failures.
Was the long archive a million-token context task?
No. It contained 16,757 words and was uploaded as a file. The application could assist with reading it.
Is Opus 5.5 cheaper than Terra?
Its short-prompt API rates are one-tenth Terra’s. Completed-task cost also depends on reasoning, output length, tools, and retries.