GPT-6.1 Terra benchmarks on agentic coding: 13th of 48, and what beat it

I like GPT-6.1 Terra more than its score suggests, and I trust it less for long jobs. It scored 0.6953 on our Gauntlet agentic coding benchmark, 13th of 48 ranked runs, for 75 cents. On our Forge 2.0 benchmark its two builds scored 0.4384 and 0.4174, for 73 cents and $1.09. On both boards it passed almost as many checks as models costing up to twenty times more. Then it lost points on behaviour that only shows up after a few virtual hours.

OpenAI released Terra on 26 October 2026 as the mid-tier model of the GPT-6.1 series, and it costs $1 per million input tokens and $5 per million output, which OpenAI says is 50% below GPT-5.6 Terra's standard prices. Their developer forum post says it "finishes tasks over 3× faster on average than both Astra and GPT-6.1 Sol". A few lines later it says "For in-depth research or complex coding, choose GPT-6.1 Sol or GPT-6 Astra." (GPT-6 Astra is the model the same post says Terra matches at one-tenth the price per token.) So OpenAI itself tells you that Terra stops somewhere, and I wanted to find out where that is on our two tasks. At $1 per million input tokens it will get tried behind a lot of coding agents this month, maybe yours, so I wanted our numbers out before that happens.

We ran it the morning after the listing. It ran on the laptop, through goose (the open-source coding agent, in our own fork) and OpenRouter, at medium reasoning effort, Terra's documented default. One Gauntlet run and two Forge 2.0 builds is a small sample. And the Forge pair sits in a comparison group of its own on our board, so treat those comparisons as indicative.

Terra builds fast, edits in small steps, writes very little and stops before it has tested the long path. I'd use it first for short, bounded jobs. Each run here took under 18 minutes and about a dollar. For a Jira app that has to keep its numbers right for six virtual hours under a rate limit (our harness fast-forwards a simulated clock), I'd pick GPT-6.1 Sol or Opus 5.5, or make Terra run the long test before it says done.

GPT-6.1 Terra benchmarks: 0.6953 on Gauntlet, 0.4384 and 0.4174 on Forge 2.0

The Gauntlet gives an agent 150 model calls to build a payments console. It has two services and a 3D field of payment towers, and we score it on 99 checks. Forge 2.0 gives it 300 calls to upgrade a working Jira Forge app to v2. We score that on 105 checks against three seeded Jira test sites. The Gauntlet also has a ceiling rule: if the 3D field fails certain checks, the score can't go above 0.699 however good the rest is. Terra passed 0.9274 of the weighted checks. Then it hit that ceiling. I read these from the boards on 28 October:

Call counts include one small Gemini 2.5 Flash call per run that goose makes on the side. The bills are complete, read from OpenRouter's generation records, and the live board on /agentic-benchmarks is the current word if anything moves.

What we found, in five points

1. Our run page names tower heights as Terra's Gauntlet cap. They didn't set it. Five failures in the 3D interaction band give the same 0.699 on their own, and two of them trace to one line Terra wrote.
2. Terra shrank its 3D canvas to fit the towers, from 900 by 560 pixels to 660 by 320. Its own measurement printed towers touching the bottom row. The scorer then found the coloured tower tops too small to read.
3. On Forge 2.0 it passed almost as many checks as GPT-6.1 Sol and lost half its score to reliability. A good part of it went on a background reconcile that refused itself on its own budget and started again from zero, for 24 virtual hours in build 1. The rest is spread over several groups, among them sprint totals that were wrong before any live update arrived and one check almost every model failed.
4. Its dashboard update arrived live and on time, on a total that was already wrong. The change rows were right and the sums weren't.
5. It stopped at 73 and 108 of 300 calls, saying in both builds that a six-hour run had not been verified. Jev Router, our own router that sends its calls to GPT-6.1 Sol, spent two of its 43 calls on exactly that rehearsal.

Gauntlet 7.2: 0.9274 earned, 0.699 allowed

The Gauntlet scores in two layers. The raw score is the weighted share of checks passed. Then admission bands put a ceiling on it, so if your 3D field gets certain things wrong the score can't go above 0.699, however good the rest of the app is. And a capped score sits a little under its ceiling (our scorer pulls it down by 0.05 times what you missed).

Terra earned 0.9274, against 0.9342 for DeepSeek V4.1 Flash 1017 and 0.8781 for Gemini 3.8 Flash. All three ended within 0.003 of each other under the same 0.699 ceiling. GPT-6.1 Sol (0.9768 raw) and Claude Sonnet 5.5 (0.9894) cleared that band and stopped at 0.799. So among the three cheap models the cap sets the order, and Terra's raw work is level with DeepSeek's. (Gemini's run sent no reasoning setting at all. And I can't confirm the effort Sol, Sol Pro and Sonnet ran with on the Gauntlet: those runs are from early October and their request logs are gone.)

The tower heights were right, and our probe gave up on one

The run page lists t_height_pixels as the reason for the cap. Terra's height formula is correct. In web/viz.js line 40 it writes clamp(.9+.55*Math.log10(p.amount_minor/10**exp[p.currency]),.2,4.2), with the minor-unit exponent per currency (0 for yen, 3 for the Kuwaiti dinar). For a KWD payment of 992000 that gives 2.548. Our probe predicted 2.5481. Five of the six towers were measured. All five came within a pixel of the prediction.

The sixth, a euro payment, was never measured. Our probe tries up to 600 camera poses to find a clean view of a tower's top, and when it can't, it records noDecisivePose, and the scorer counts that as a failure: 5 of 6. My guess is that the small canvas left too few clean poses. A US dollar tower uses the same exponent as the euro one, and it measured at minus one pixel, so a height bug in Terra's code looks unlikely to me. Every other model in this comparison measured 6 of 6. DeepSeek's and Gemini's canvases were 890 by 480 and 1230 by 598.

I re-graded the run with that check passing, using the scorer's own band function. The ceiling stays 0.699. The 0.799 band has five failures of its own, all listed on the run page, and five failures in that band also cap the score at 0.699. So fixing that check alone would leave the ceiling at 0.699.

The flick that never coasted

The contract asks for inertia. You drag the field and let go. It keeps turning for a moment, then slows down. The release speed comes "from the last two moves". Terra wrote the coast correctly, with an exponential decay. Then it added a rule the contract doesn't have, in the pointer-up handler at web/viz.js line 77:

1if(time-lastMove.time>100){vyaw=vpitch=0}

If more than 100 ms passed since the last pointer move, the speed goes to zero. Our probe drags the field 57.6 degrees in a headless browser and lets go, and in Terra's page each probed move took 305.6 ms to draw, so by the time the release was handled the last move was well over 100 ms old. The probe recorded a release speed of 0 and a coast of 0 degrees, and both coast checks failed on it.

I think the cutoff plus slow headless frames did it, though I haven't reproduced it live. My control is Gemini 3.8 Flash. Its page was even slower (1,640 ms per move), and it still released at 4.22 degrees a second and coasted 1.66 degrees. So slowness alone doesn't zero the speed. DeepSeek V4.1 Flash fades the speed instead of cutting it (viz.js line 1186, sinceMove > 0.12 ? Math.exp(-sinceMove / FLIGHT_TAU) : 1) and coasted 12.8 degrees. Sonnet coasted 15.4, and Sol and Sol Pro 8.4 each.

And DeepSeek tested it. Its transcript has three drags with page.mouse.down() (calls 60, 131 and 134). Terra's 150 tool calls contain no mouse drag at all. It wrote viz.js once, at 08:41 laptop time in call 15, and never opened that handler again.

It shrank the picture to make the towers fit

Calls 79 to 107 are a two-minute loop in which Terra wrote a script to measure where the tower pixels sit on screen, cut the canvas, and measured again after each cut. Height went from 560 px to 480, 460, 400 and 320, and the maximum width from 900 to 760, 680 and 660. Its last measurement, at 08:48:07, printed h: 320 ... y: [ 63, 72, 300, 319 ]. Tower pixels sat on row 319 of 320. The visual contract says no tower may sit within 4 CSS pixels of the canvas edge. It moved on.

The scorer found 48 edge pixels and "0/0 readable caps show their status colour" (caps here are the coloured tops of the towers). At that size they were too small to read, so q_overview_legibility scored 0.5. Sol Pro had zero towers on the edge and 96 of 96 caps readable. I think this moment says the most about the model. Terra built itself a measurement, and the measurement showed the rule it was breaking, in its own terminal, four minutes before the run ended. It optimised the number it was watching (how much of the canvas the towers filled) and stopped there.

How it worked: 99 edits, two sentences

Terra made 150 tool calls in 15.4 minutes. 99 of them were edits, mostly three or four seconds apart, on files it kept minified on one line. It wrote two messages in the whole run. The first came at 08:36:50: "I'll build the services and the console against the vendor contract, then exercise the sync and browser paths locally." The second was its summary. It produced 40,190 completion tokens over the run, about 272 per call, and only 5,835 of them were reasoning.

DeepSeek made the same number of calls and wrote five times as much, and Sonnet wrote eight times as much in a third of the calls. Terra finished in 923 seconds against Sol's 1,595, and it never exercised the two coast checks it then failed.

And the older Terra

We ran ~openai/gpt-terra-latest on the same Gauntlet task on 6 October. That alias most likely pointed at GPT-5.6 Terra, OpenRouter's newest Terra then, though the logs only show the alias. It scored 0.5781 in 49 calls and 336 seconds. It sent no reasoning effort at all. So the setup differs as well as the model.

Its 3D scene sat in the wrong place on screen: 17 of 120 predicted pixels matched, and none of the six towers could be measured. Its approval notification never reached the page either, which our scorer treats as a dead primary flow (x0.9429). Its outbox relay delivered 50 events every 0.4 seconds, behind thousands of sync events. My guess is that the approval sat in that queue when the probe looked, but the logs can't prove it. GPT-6.1 Terra pulls 500 events per round trip and polls every 3 seconds, and it saw both notifications. On this task the new model is clearly better, mostly in the 3D field.

GPT-6.1 Terra on Forge 2.0: 0.91 of the checks, 0.48 reliability

Forge 2.0 multiplies the share of checks passed (the pre-severity score) by a multiplier for critical defects and by reliability. Reliability is a product over 19 groups of checks. Each group's worst check takes up to 10% off, so a group whose worst check scores 0 multiplies the total by 0.9. Six groups at 0.9 get you to about 0.53. Terra had no critical defects. It had six groups at or near 0.9 in build 1 and five in build 2.

Our board groups runs whose setup matched. Terra's two builds form a group of their own. Sol and Opus share one group. Sonnet and Gemini 3.8 Flash share another. DeepSeek and Jev Router each have their own. But every Forge 2.0 run I compare here used the same task and sent the same medium reasoning effort. Jev Router comes up a lot below. It's our own router, and in this run all 43 of its model calls went to GPT-6.1 Sol (plus goose's one Gemini side call). Its build scored 0.8523, the best here.

One group is a loss Terra shares with almost everyone: a_action_result scored 0 for four of the five models here, Terra included, and Opus got 3 of 5, so I'm not counting it against Terra.

The reconcile that never finished

The task app keeps a scope ledger of what was added to and removed from each Jira sprint, and when Jira drops change events (our test harness drops some on purpose) the app has to heal itself. A background reconcile reads Jira's change history and fills the gaps. It has to stay inside 70% of an hourly rate budget, which is 1,680 points in the task's own rate model (not Atlassian's published quotas). Terra's build 1 meters its own spending before each background request, at src/jira.js lines 26 and 46:

1if (used + cost > limit) throw new RateLimited(..., 'local-background-budget');

That part is fine. The refusal is where it goes wrong. Build 1 saves its cursor only when the function is about to run out of time (src/sync.js lines 246 and 275). When it refuses itself on budget, the job is retried up to 900 seconds later. And it starts again from discovery and the candidate search. It never got far. In the heal phase on the hardest seed, our observations show 97 deliveries of that one reconcile, all retries, over 24 virtual hours. They made 192 search pages and only 24 changelog reads. It healed 0 of 4 dropped changes.

Build 2 has no cursor at all. It throws WorkContinues when time runs low, queues a fresh reconcile and searches again. That went on for 1,096 invocations over 273 virtual hours, until Forge stopped it with "The limit on cyclic invocation has been reached." (Forge caps how many times a chain of functions can re-queue itself.) It healed 1 of 4 and kept background spending within its 70% share in only 6 of 829 hours.

My guess for build 1 is a livelock. One full pass costs more than an hour's allowance, and each hour it starts the pass from zero. That reading comes from the call sequence and the code. The 0 of 4 healed is measured.

Jev Router charges itself with the same cost formula, 1 + issueIdsOrKeys.length, at src/jira.js line 25. (It routed to GPT-6.1 Sol here too, as in the run I wrote about earlier this month.) But at src/sync.js line 152 it has a comment Terra never wrote: "Durable reconciliation: each page is checkpointed before the next is requested." It reads pages of 50 issues and stores each page's changelog under its own key before processing it. Its heal phase took 2 invocations and healed 4 of 4. Opus and Sol healed 4 of 4 as well, DeepSeek 1 of 4.

Terra knew the risk. Build 1's last message says "continuation under unusually large workloads have not been fully validated". Build 2's says "Low quota settings can defer reconciliation".

If the heal group and the rate-quota group next to it (10 of 954 person-facing requests refused for quota) had both been clean, build 1 would score 0.541 by my arithmetic from the run document. Fixing the re-estimated totals in the next section alone would give 0.478. Their groups also hold a not-started view and a comment-format failure, and clearing all of them gives 0.591.

A live update, right on time, on the wrong number

Our scorer makes two scripted changes to one sprint and watches the dashboard widget. Terra's live path works. Its backend waits five seconds for the app's own storage index to catch up, then publishes on a global Forge Realtime channel (src/realtime.js lines 17 to 19), and the widget subscribes to it. The added total moved by +5, live, with no polling and no reload. But it moved from 149.5 to 154.5 in build 1 and from 162.5 to 167.5 in build 2. The three builds I compared it with all went from 163 to 168. So u_widget_live scored 0. Our scorer's message for it, "the dashboard does not update live", gets the reason wrong, and that one's on us.

It shows up in other checks too. t_out_of_order reads "11/11 rows exact, 0/3 sprints with oracle numbers" in both builds. Re-estimated sprints matched the expected numbers in 1 of 6 and 2 of 6 (Jev 6 of 6, Opus and Sol 5 of 6). Terra kept v1's computeTotals. So did Jev. I think the fault is in what feeds the totals. Terra reads only the Sprint field's change history (fieldIds: [sprintFieldId], src/sync.js line 205). A story-point re-estimate inside a sprint is invisible to it. And an unhealed dropped change can flip an issue between committed and added. Jev also reads the estimate fields' history and freezes the members of closed sprints. The checkpoint dumps don't carry the rows, so I couldn't diff it issue by issue. Which path lost the 13.5 points is a guess.

What each one ran before saying "done"

A six-virtual-hour rehearsal exercises both defects above. You reset the site, run the reconcile, feed it an hour of events, repeat six times and read the logs. Terra's build 1 tested pieces: event batches of 3, 6, 30, 250 and 700, and the scheduled reconcile four times. It never ran that sequence. The string local-background-budget appears zero times in its transcript, so it never watched its own refusal fire. It stopped at 73 of 300 calls with "a complete six-hour run against the scoring seed was not verified." Build 2 stopped at 108 with "A full six-hour run was not verified." Its last shell command deleted its dev logs.

Jev Router used 43 model calls in total and spent two of them (calls 36 and 37) on exactly that rehearsal, reset; scheduled scope-reconcile; events --limit 165; ... through hour six. Then it grepped the output for killed invocations and errors. Its report: "The dev stream completed with hourly reconciliation and no killed invocations or function errors." Opus didn't run the full six hours either. But it checked its numbers against a recount from Jira for all six active sprints.

I think this is how Terra behaves at medium effort. It writes an accurate limitations paragraph where Jev spends the budget to close the gap. The token counts fit: about 70 reasoning tokens per call for Terra, against roughly 290 for Sol and 370 for Jev's Sol leg, at the same effort label. A model that thinks little per step may be planning little per step, though I've seen it on one task and two builds. We didn't run Terra at high effort, and we haven't tested whether telling it to run the six-hour rehearsal makes it do so.

GPT-6.1 Terra vs GPT-6.1 Sol

Sol won on both boards. On the Gauntlet, Sol scored 0.7978 to Terra's 0.6953. Sol cost at least $1.28 (its bill is a lower bound), Terra $0.75. Both builds are good underneath. Sol cleared the interaction band that capped Terra. On Forge 2.0, Sol's two builds scored 0.6495 and 0.5371 for $1.15 and $1.23. Terra scored 0.4384 and 0.4174 for $0.73 and $1.09, in a different comparison group. Sol used fewer calls (about 48 per build) and more thought per call. GPT-6.1 Sol Pro scored 0.9574 on the Gauntlet in 44 calls, the top run on that board, for $4.91.

Artificial Analysis runs its own coding agent index and puts Terra at 48 and Sol at 54, and on its separate Intelligence Index it finds Terra's low and medium effort levels Pareto-optimal for cost. Our two tasks agree on the order and disagree on the size of the gap. I think ours run long enough for a skipped rehearsal to cost something. On the Hacker News launch thread one commenter wrote "I'm not sure why you would pick Terra over Sol in that case." On our Forge task you'd save little by picking it. A Sol build cost $1.15 to $1.23 and a Terra build $0.73 to $1.09, and Sol's builds scored 0.10 to 0.23 higher.

GPT-6.1 Terra pricing: what a run cost

OpenAI's model page lists Terra at $1 in, $5 out and $0.05 for cached input on the standard tier. OpenRouter doubles input and raises output to $7.50 once a single prompt reaches 272,000 tokens. Our largest prompt was 157,263, so that never applied. We were routed to OpenAI's standard endpoint. OpenRouter also lists a Flex endpoint at half price, which would have made these runs about 34 to 52 cents. Most of each bill is cached input that goose sends again with each call, 8 million cached tokens for 40 thousand written.

For scale, on Forge 2.0, Claude Opus 5.5's 0.7294 build cost $20.71. Sonnet 5.5's 0.5899 build cost $5.00 and Gemini 3.8 Flash's 0.4958 build $6.70. Jev Router's 0.8523 build cost $1.15, and DeepSeek V4.1 Flash 1017's 0.6618 build at least $0.32. Terra is cheap. Per point on this board, though, DeepSeek was cheaper, and by a lot.

Why might it behave like this? What the cards say

Sources: OpenAI's Terra and Sol model pages, the Terra system card addendum, the DeepSeek V4.1 Flash model card, the Gemini 3.8 Flash model card, Anthropic's Sonnet 5.5 and Opus 5.5 pages, and OpenRouter's listing for the served context.

OpenAI publishes no parameter count or attention design for Terra, so its card can't explain the reliability gap. Two lines in it do fit what we saw. The system card calls it "a fast, efficient model for high-volume professional work, with strong image analysis and computer use capabilities". That fits a model that looked at its own canvas five times, checked its scene against the app's debug digest twice and measured pixels with a script. And OpenAI's advice to use Sol or Astra for complex coding is what our Forge numbers say too. Sonnet 5.5's default effort is high, so our medium sits one step below its default. For Terra, Sol and Opus, medium is the default.

Where our harness got it wrong

Our Gauntlet probe scores a tower it couldn't measure as a tower measured wrong. And our run page names that check as the cap when another band gives the same 0.699. We should leave unmeasured cases out of the count, record how many scans the probe tried, and print the band that actually binds. Our Forge widget check says "the dashboard does not update live" when the update arrived on a wrong total. It should say the number was wrong. And a_action_result scores 0 for four of the five models I compared here, which usually means the check deserves a look before a model does. Fixing them wouldn't change Terra's 0.6953, 0.4384 or 0.4174, only the reasons the run page prints.

I also couldn't find the goose version these runs used. The run files carry no version string, and the laptop's app was updated after the runs. The three Terra runs sent medium effort, which our app has done since 3.0.116, so they ran on that version or a later one.

Should you use GPT-6.1 Terra for agentic coding?

For short, bounded jobs, yes, and I'd try it first. It wrote a correct height formula for four currencies and a relay that didn't lose the approval notification. Its Forge v2 upgrade passed lint, bundling, manifest and scope checks. Each run took under 18 minutes and about a dollar. For work that has to survive time, like background sync, retries under a rate limit or anything that runs for hours after you look away, I'd use GPT-6.1 Sol or Opus 5.5. Or keep Terra and make the rehearsal part of the task. Tell it to run the long scenario and show you the log before it says done. In both Forge builds it wrote down that the six-hour run wasn't verified. At medium effort it didn't go and run it.

The goose fork we ran this in still isn't a polished product (we use it because we know where it squeaks), and it produced every number above. If you've put Terra behind an agent for something long-running, did it stop early and leave you a careful note about what it hadn't checked, or did it run the long test when you asked? Tell us in the comments under this post. Each run above, with its video and its bill, is on the benchmark page, and the October roundup has the rest of the field.