GPT 5.6 Sol vs Terra: the same envelope at 2.5× the price

Identical 372,000-token context, identical 128,000-token output ceiling, identical 0.1× rate. Sol lists at 2.5× Terra on both input and output — here is where that actually shows up.

Two ids with the same envelope

Sol and Terra were released on the same day, 2026-07-09, and they carry the same envelope: a 372,000-token context, a 128,000-token output ceiling, text, tool calling and thinking, and the same /v1/responses route. Neither is a trimmed build of the other.

Where they separate is list price. Sol is $5 per million input tokens and $30 per million output; Terra is $2 and $12. Both are billed at the 0.1× multiplier here, so the ratio survives the discount — Sol costs 2.5× as much in either direction.

After the multiplier that works out to $0.50 / $3.00 per million for Sol and $0.20 / $1.20 for Terra. Every other field in the catalog entry matches, so price is the whole of the difference you can read off a spec sheet.

Where 2.5× lands on a real bill

Output is the expensive side of both models — $3.00 against $1.20 per million after the multiplier, roughly six times each model’s own input rate. A workload that reads a lot and writes a little feels the gap far less than an agent loop emitting long patches turn after turn.

Take a session that sends 200,000 input tokens and takes back 20,000. On Sol that is $0.10 of input and $0.06 of output, $0.16 in total; on Terra it is $0.04 and $0.024, or $0.064. The per-session gap is under ten cents, which is exactly why the 2.5× only becomes a budget question at volume — ten thousand of those sessions is a $960 difference.

The same arithmetic runs the other way. Below a few hundred sessions a month the choice is not a cost decision at all, and picking on multiplier alone means optimizing a line item worth cents.

Deciding without guessing

Nothing in the catalog tells you which one answers your prompts better; apart from price the two entries are identical. That question is a property of your workload, and it is cheap to settle — both ids answer on /v1/responses with the same request body, so a comparison is one changed field and one extra call.

Run a representative prompt through both, not a toy one, and then look at whether Terra’s output needed a follow-up turn. A cheaper model that costs you a second round trip is not cheaper: in the example above two full Terra sessions come to $0.128 against $0.16 for one Sol session, and a third retry puts Terra over the top.

If both hold up on your task, the decision reduces to price. If Terra’s answers need supervision where Sol’s do not, the 2.5× is what that supervision costs you instead.

Both ids answer on the same endpoint with the same body; only "model" changes.
curl https://token-share.app/v1/responses \
  -H "Authorization: Bearer $TOKEN_SHARE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-terra",
    "input": "Summarize the failure mode in this stack trace."
  }'

# Same call against the more expensive sibling
curl https://token-share.app/v1/responses \
  -H "Authorization: Bearer $TOKEN_SHARE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "input": "Summarize the failure mode in this stack trace."
  }'

Common questions

Do Sol and Terra share the same rate multiplier?
Yes, both are 0.1×. The multiplier applies to different list rates — $5 / $30 per million for Sol, $2 / $12 for Terra — so the effective prices come out at $0.50 / $3.00 and $0.20 / $1.20. Not every id here is 0.1×; multipliers across the catalog run from 0.1× to 0.5×.
Is Terra a smaller model than Sol?
The catalog does not say that. Context, output ceiling, capabilities, route and release date are the same on both entries — the only recorded difference is the per-token rate. Anything about relative answer quality has to come from running both on your own prompts.
Can I switch between them inside an existing integration?
Both route to POST https://token-share.app/v1/responses with the Authorization: Bearer header, so switching is a change to the model field and nothing else. That also makes it practical to send a slice of traffic to each and compare on real requests.