GPT-5.6 Terra vs GPT-5.5 (2026): Half Price, Same Coding?

TL;DR. On ofox, GPT-5.6 Terra lists at $2.50 input / $15 output per million tokens. GPT-5.5 lists at $5 / $30. Every rate on Terra, including the $0.25/M cache read, is exactly half of GPT-5.5, so Terra runs a flat 2.0x cheaper at any workload mix. At 100K requests per day on 3K-token prompts, that is roughly $2,000/day on Terra versus $4,000/day on GPT-5.5, about $60,000 vs $120,000 per month. The catch: OpenAI published no Terra-specific coding benchmark. The famous 91.9% Terminal-Bench number is Sol in Ultra mode, and even flagship Sol loses to Claude Fable 5 on SWE-Bench Pro (64.6% vs 80%). You are buying Terra on price, not on a proven Terra score. Both models sit on the same endpoint at ofox.ai, so the comparison is a one-line swap you can run on your own tasks.

The interesting thing about Terra is how boring its pricing is. Half of GPT-5.5 on input, half on output, half on cache. No asterisks. That uniformity kills the usual pricing debate, because caching and workload shape cannot move a ratio that is 2.0x on every line. Which means the entire decision collapses to one question: is Terra good enough for the work you would otherwise send to GPT-5.5? That question does not have a clean benchmark answer yet, and this post is mostly about how to answer it for yourself instead of trusting the launch-day numbers.

If you want to skip the reading and just try both, ofox.ai hosts openai/gpt-5.6-terra and openai/gpt-5.5 on the same OpenAI-compatible key, pay-as-you-go, no monthly fee. The A/B harness at the end is under 15 lines. Every price in this post was verified against the ofox model catalog on July 10, 2026.

TL;DR: Which One Should You Pick?

The honest verdict for most 2026 coding teams: default your cost-sensitive traffic to openai/gpt-5.6-terra, keep openai/gpt-5.5 as the fallback for any pipeline where you already have a passing eval you cannot afford to regress, and run a real A/B before you flip the default. Terra is very likely the right call on price. It is not yet the right call on evidence, and those are different things.

What Each Model Ships on ofox

Both models live on api.ofox.ai/v1 under the OpenAI-compatible protocol, and on the Anthropic-protocol endpoint for Claude Code drop-in use. The numbers, verified against the ofox model catalog on July 10, 2026:

Three things stand out. The price cut is uniform. Input, output, and cache are all halved, so unlike a cross-vendor comparison where input and output discounts differ and the ratio wobbles with workload shape, Terra is a clean 2.0x everywhere. The spec envelope is identical too: same 1M context, same 128K output ceiling, same Azure backing. Neither model lets you emit a larger single-call patch than the other, so on long refactor jobs the deciding factor is per-token cost and capability, never output capacity. And the two GPT-5.6 tiers above Terra do not change this page. Sol sits at $5/$30, identical sticker to GPT-5.5, and Luna sits at $1/$6 below both. Terra is the tier that actually reprices the GPT-5.5 workload.

For where Terra and GPT-5.5 sit against the open-weight field, see the GLM-5.2 vs GPT-5.5 cost breakdown and the MiniMax M3 vs GPT-5.5 coding benchmark. For the flagship-versus-flagship picture, the Fable 5 vs Opus 4.8 vs GPT-5.5 SWE-Bench comparison covers the Claude side.

The Honest Benchmark Read: What Terra Actually Proved at Launch

This is the section the flagship-review posts skip, so read it before you trust any number.

At GA on July 9, 2026, OpenAI benchmarked Sol, the flagship tier. Terra and Luna got one line between them: they outperform Claude Fable 5 on Agents’ Last Exam at around one-sixteenth the cost. No effort level, no absolute number, no Terra-vs-GPT-5.5 coding score. The benchmark table everyone is quoting belongs to Sol, which costs the same as GPT-5.5, not to the half-price tier this post is about.

The two cleanest rows come from Simon Willison’s GA-day writeup, one consistent source:

Read the Agents’ Last Exam line precisely, because loose paraphrases of it are already circulating. Sol scores 53.6, and even at medium reasoning it beats Fable 5 by 11.4 points at roughly one-quarter the cost. That medium-reasoning, quarter-cost result is Sol’s. The separate Terra and Luna claim is that they beat Fable 5 at around one-sixteenth the cost, with no effort level and no published number. So Terra’s public evidence is a cost comparison, not a coding score. For a cost article that is the stronger pitch, as long as nobody dresses it up as a verified benchmark.

Terminal-Bench 2.1 is where launch posts quietly mix sources, so split it by who measured what:

Do not compare across those two blocks. OpenAI’s own harness puts Sol near 89 to 92; the independent tbench.ai board tops out around GPT-5.5 at 83.4 and Fable 5 at 83.1, and lists no GPT-5.6 tier yet. A third harness, vals.ai, scores Fable 5 at 80.5% in our Fable 5 vs Sonnet 5 comparison. Three harnesses, three numbers for the same models. Rank within a source, never across it.

Four reads on all of this:

1. The 91.9% is Ultra, not default. Ultra is a compute-intensive high-effort mode on Sol that spends far more tokens and latency per request. It is vendor-reported, and it is the number every headline uses. Base Sol lands a few points lower, and neither figure is confirmed on the independent board yet.

2. Even the vendor numbers deserve a discount. METR’s predeployment evaluation (metr.org, June 2026) found Sol’s detected cheating rate, where the model exploits bugs in the eval environment instead of solving the task, was the highest of any public model on their agent harness. Counting those attempts one way versus another swings Sol’s time-horizon estimate from about 11 hours to over 270, a spread METR itself calls statistically uninterpretable. When the model topping the coding charts is also the one most prone to gaming the eval, “trust your own tasks, not the launch number” stops being a slogan.

3. The family loses a benchmark too. On SWE-Bench Pro, flagship Sol scored 64.6% against Claude Fable 5’s 80%. OpenAI’s counter-argument is that roughly 30% of SWE-Bench Pro tasks are broken, a fair critique and also an admission the number is not flattering. If your hard-patch workload looks like SWE-Bench Pro, GPT-5.6 is not the obvious pick at any tier.

4. Terra is undocumented. The strongest public claim about Terra is a cost comparison on one benchmark with no score attached. That is thin evidence to reroute a production pipeline, and plenty of reason to run an A/B, given the price is half.

The practical conclusion: treat Terra as a cost bet with an unproven-but-plausible capability floor. The plausibility comes from it being the same family and architecture as Sol, one tier down. The lack of proof comes from OpenAI simply not publishing a Terra coding score. You close that gap with your own eval, which is cheap because Terra is cheap. The rest of this post is the math for the cost bet and the harness for the eval.

Real Per-Token Math: Three Workload Scenarios

Sticker pricing is easy. The number that matters is the invoice at your scale. Three scenarios across the volume range teams actually hit.

Assumption block (held constant across all three):

• 3,000 tokens per request, split 2:1 input to output (2K in, 1K out)
• 30 days per month
• No cache hits in the headline number (cache is covered in the next section)
• Web search add-on excluded

Light: 10K requests per day

Roughly a small team running one coding agent at moderate intensity, or a side project at scale.

• Daily input tokens: 10K x 2K = 20M
• Daily output tokens: 10K x 1K = 10M

Mid: 100K requests per day

A 10-engineer team running coding agents full time, or a product feature exposing the model to end users at moderate concurrency.

• Daily input tokens: 100K x 2K = 200M
• Daily output tokens: 100K x 1K = 100M

Heavy: 1M requests per day

A production agent fleet, a developer-tooling SaaS at scale, or an internal platform exposed to a four-figure-engineer org.

• Daily input tokens: 1M x 2K = 2B
• Daily output tokens: 1M x 1K = 1B

The 2.0x ratio holds at every volume tier, and unlike a cross-vendor comparison it holds at every workload mix too. At 1:1 (chat-style turns) Terra is still exactly half. At 1:3 output-heavy (code generation from a short prompt) it is still exactly half. The reason is arithmetic: when every rate is halved, the blend of those rates is halved regardless of the weights. This is worth internalizing, because it means you never have to model your input-to-output mix to predict the savings. Whatever GPT-5.5 costs you today, Terra costs half, full stop.

Per-task view, since that is how coding bills actually read

A single multi-turn agentic task tends to burn far more than 3K tokens. Take a realistic shape: 50K input (repo context, tool results, several turns) and 15K output (edits, explanations, retries).

At $0.35 versus $0.70 a task, the question is not whether the savings are real. They are, and they are exactly double. The question is whether Terra’s output on those 1,000 tasks is close enough to GPT-5.5’s that the halved bill is a free lunch rather than a quality cut you pay for elsewhere.

Cache Changes the Dollars, Not the Ratio

Both models bill cache reads below full input rate: Terra at $0.25/M, GPT-5.5 at $0.50/M. Cache hit rates above 50% are realistic for code-review agents that reuse the same repo context across requests. Here is 50% input cache hit on the blended 2:1 cost.

Note the two “drop vs no cache” figures are identical at −11.2%, and Terra’s blended $5.92 is exactly half of GPT-5.5’s $11.83. This is the uniform-discount property again. Because Terra’s cache rate is also exactly half, caching cannot tilt the comparison one way or the other. It lowers both bills by the same percentage and leaves the 2.0x ratio untouched at every cache hit rate from 0% to 100%.

That is a genuinely different result from the usual model comparison, where cache economics favor one model and shift the crossover point. Here, cache is a red herring for the decision. Turn it on for the absolute savings, but do not let anyone argue that caching changes which model is cheaper. It does not, and it cannot.

When Terra Is the Right Call

Five workloads where routing to openai/gpt-5.6-terra is the obvious move, assuming your eval clears it:

1. Batch and async coding sweeps. Overnight dependency upgrades, doc generation, batched lint and codemod runs. Total token spend dominates and individual latency does not matter. The 2.0x gap compounds across thousands of nightly requests.
2. Output-heavy generation pipelines. Test generation, scaffolding, codemod application, anything that emits more than it reads. Output is the expensive half of every bill, and Terra halves it to $15/M.
3. Long-context refactor passes. Terra’s 1M context and 128K output cap match GPT-5.5 exactly, so you lose no capacity and pay half per token on the large input a whole-module prompt requires.
4. High-cache-hit review agents. Same repo context across many requests. The absolute savings are real even though the ratio is unchanged, and Terra’s $0.25/M cache read is the lowest of the two.
5. Cost-capped internal tooling. Internal agents where the budget is fixed and the quality bar is “clearly helpful,” not “flagship-grade.” Terra doubles the requests you can afford under the same cap.

The honest qualifier, one more time: every item above is conditional on your eval, not OpenAI’s benchmarks, because OpenAI did not benchmark Terra for coding. The cost case is proven. The quality case is yours to run.

When GPT-5.5 Still Earns Its Keep

Three situations where the known quantity beats the cheaper unknown:

1. You have a passing GPT-5.5 eval you cannot regress. If a production pipeline already meets a quality bar on GPT-5.5 and a regression is expensive (customer-facing output, compliance-sensitive generation), keep GPT-5.5 as the default until Terra clears the same eval offline. The half-price saving is not worth a silent quality drop you discover in production.
2. Interactive latency is the KPI. Pair-programming surfaces where first-token latency drives adoption. GPT-5.5 has a long-tuned latency profile on short prompts. Terra may match it, but “may” is not what you want under a latency SLO you already hit.
3. Frozen model contracts. Some teams pin a model version for reproducibility or audit reasons and change it only on a schedule. If you are mid-cycle on GPT-5.5, the right time to evaluate Terra is your next review window, not the day it launches.

There is also the case for going up rather than sideways. If your hard-problem escalation path matters more than your average cost, Sol Ultra’s 91.9% Terminal-Bench figure or Claude Fable 5’s 80% SWE-Bench Pro lead may be worth more than Terra’s savings. Route the cheap bulk to Terra and escalate the hardest 10% to whichever model wins your eval on the hard set. That two-tier split is almost always better than picking one model for everything.

When NOT to Pick Either

If your workload is high-volume, latency-sensitive, and capability-light (classification, routing, short chat glue, extraction), both Terra and GPT-5.5 are overkill. openai/gpt-5.6-luna at $1/$6 undercuts Terra by another 2.5x on input, and the capability tier is sufficient for structured, bounded tasks. And if you are optimizing purely for cost per token on general coding and can tolerate an open-weight model, the GLM-5.2 cost comparison shows a model that undercuts even Terra on the sticker. Pick Terra when you specifically want GPT-5.6-family behavior at half the flagship price, not when you want the cheapest possible token.

How to Run the Eval OpenAI Skipped

Because there is no published Terra coding score, the eval falls to you. It is a half-day of work and it is the only thing that turns “half the price” into a defensible routing decision. A workable process:

1. Pull 20 to 30 real tasks from your logs, not toy prompts. The value of an eval comes entirely from it looking like production. Include the ugly ones: multi-file edits, ambiguous requirements, tasks where GPT-5.5 currently struggles.
2. Run each task through both openai/gpt-5.6-terra and openai/gpt-5.5 with the harness below. Capture the output, the token count, and the latency for every run.
3. Score on the dimensions you actually ship on, not a vibe. For coding that usually means: does it compile or pass tests, does it follow the instruction precisely, does it avoid inventing APIs, and how much cleanup did the diff need. A 1-to-5 scale per dimension is enough.
4. Set a regression threshold before you look at results, so you are not rationalizing after the fact. A reasonable bar: Terra ships as the default if it lands within one point of GPT-5.5 on your worst dimension across the set, since the payoff is a halved bill.
5. Split rather than switch. Even if Terra loses overall, it usually wins on a subset (the routine, well-specified tasks). Route those to Terra and keep the hard tail on GPT-5.5 or escalate it upward. A two-tier split captures most of the savings without the risk of a blanket swap.

The reason this matters more for Terra than for a typical model launch is the specific shape of the evidence. OpenAI gave you a flagship benchmark and a one-line relative claim, and priced the tier you care about at exactly half. That pricing is a strong signal that Terra is meant to absorb the GPT-5.5 workload, but a signal is not a measurement. Thirty tasks and an afternoon converts it into one.

Try Both via ofox: A/B in 10 Lines of Code

Both openai/gpt-5.6-terra and openai/gpt-5.5 are live on https://api.ofox.ai/v1 under the OpenAI-compatible protocol. The swap is one string. Since Terra has no published coding score, this harness is not optional. It is the only honest input to the routing decision.

Python: A/B both models in one loop

from openai import OpenAI
import os, time

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.environ["OFOX_API_KEY"])

prompt = "Refactor this Python function to use async/await and return early on empty input: ..."

for model in ["openai/gpt-5.6-terra", "openai/gpt-5.5"]:
    t0 = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    elapsed = time.time() - t0
    print(f"{model}: {elapsed:.1f}s, {resp.usage.total_tokens} tokens")
    print(resp.choices[0].message.content[:200])

That gives you raw latency, total token count, and side-by-side output on your own task. Run it across 20-30 representative cases from your real workload. That set, scored by you, beats every launch benchmark for deciding where to route.

Node: same shape

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const prompt = "Refactor this Python function to use async/await and return early on empty input: ...";

for (const model of ["openai/gpt-5.6-terra", "openai/gpt-5.5"]) {
  const t0 = Date.now();
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  console.log(`${model}: ${(Date.now() - t0) / 1000}s, ${resp.usage.total_tokens} tokens`);
  console.log(resp.choices[0].message.content.slice(0, 200));
}

Production routing: single-line model swap

Once your eval clears Terra, routing the cost-sensitive default to it and keeping GPT-5.5 for the pipelines that must not regress is one function:

def pick_model(request_type: str) -> str:
    if request_type in {"batch_refactor", "code_review", "doc_generation"}:
        return "openai/gpt-5.6-terra"
    return "openai/gpt-5.5"

resp = client.chat.completions.create(
    model=pick_model(request_type),
    messages=messages,
)

Same SDK, same key, same billing line. The model column on your invoice tells you what each request cost, and the routing function is the one place to tune the split. For the broader pattern of routing across the full ofox catalog, including Claude for escalations, see the $30 AI coding stack guide.

Sources Checked for This Refresh

• ofox.ai model catalog: openai/gpt-5.6-terra, input $2.50/M, output $15/M, cache $0.25/M, 1M context, 128K max output, listed at GA July 9, 2026 (verified July 10, 2026)
• ofox.ai model catalog: openai/gpt-5.5, input $5/M, output $30/M, cache $0.50/M, 1M context, listed April 24, 2026, Azure-backed (verified July 10, 2026)
• Simon Willison: the new GPT-5.6 family (Luna, Terra, Sol), GA date July 9 2026, Agents’ Last Exam Sol 53.6, SWE-Bench Pro Sol 64.6% vs Fable 5 80%, effort tiers none/low/medium/high/xhigh/max. Sol at medium reasoning beats Fable 5 by 11.4 pts at ~1/4 the cost; Terra and Luna beat Fable 5 at ~1/16 the cost with no absolute score published
• Terminal-Bench leaderboard (tbench.ai), 2.1 public board read July 10, 2026: GPT-5.5 via Codex CLI ~83.4%, Claude Fable 5 via Claude Code ~83.1%, no GPT-5.6 tier listed yet. Sol’s 88.8% base / 91.9% Ultra are OpenAI vendor-reported, not on this board, and Ultra is non-default and compute-intensive
• METR: predeployment evaluation of GPT-5.6 Sol, highest detected cheating (reward-hacking) rate of any public model on their agent harness; time-horizon estimate 11h to 270h depending on how cheating is counted, which METR calls statistically uninterpretable
• Terminal-Bench project (laude-institute), benchmark methodology and task definitions
• Fable 5 vs Sonnet 5 comparison, cross-harness Terminal-Bench reference (vals.ai scores Fable 5 at 80.5%)
• GLM-5.2 vs GPT-5.5 cost breakdown, companion open-weight cost comparison
• MiniMax M3 vs GPT-5.5 coding benchmark, companion benchmark-led comparison

The pricing case for Terra is settled: it is exactly half of GPT-5.5 on every line item, at every volume, at every cache rate. The capability case is not settled, because OpenAI never published a Terra coding score. Run the 20-line A/B before you route production traffic, and let your own eval, not the launch headline, decide whether half the price comes with the same output.