GPT-6.1 Terra on OpenAI or Bedrock: which path to test first

Two paths to one model name

GPT-6.1 Terra is described by OpenAI as a fast, efficient model for visual reasoning, precise computer use and natural writing, with the model id gpt-6.1-terra¹. AWS lists it in its OpenAI catalog on Bedrock with a similar description². For a team with an AWS contract, the question is not whether Terra is good. It is whether the AWS path or the OpenAI path is the better place to run the evaluation and then production.

This article separates what the two vendors publish from what you have to read out of your own accounts. Several items that matter for the decision, in particular Bedrock's Terra rate, its exact model id, its quotas and its regions, were not on the pages checked. They appear below as things to verify, not as facts.

The recommendation, up front: evaluate Terra's quality and cost per successful task first, on whichever path you can start today. Then run a smaller parity check between paths. Mixing both questions into one test makes a failure impossible to attribute.

What OpenAI publishes for Terra directly

OpenAI's model page gives the contract for the direct path¹:

• Text and image input, text output; audio and video are unsupported.
• A 1,050,000-token context window, 922,000 maximum input tokens and 128,000 maximum output tokens.
• A June 1, 2026 knowledge cutoff and reasoning token support.
• reasoning.effort of none, low, medium (default), high, xhigh and max.
• Chat Completions, Responses and Batch are supported; tool calling requires the Responses API. Fine-tuning, embeddings and Realtime are not supported.
• One snapshot, gpt-6.1-terra.

Standard list rates are $1 per million input tokens and $5 per million output tokens, cached input is $0.05, and cache writes are $1.25 for 30-minute retention or $2.50 for 12-hour retention³. Batch and Flex are $0.50 and $2.50, and Fast mode is $2 and $10. Prompts above 272K input tokens are billed at 2x input and 1.5x output for the whole request, and regional processing endpoints carry a 10% uplift for models released on or after March 5, 2026³.

Rate limits on the direct path follow your usage tier. For Terra, OpenAI lists Build at 5,000 RPM and 1,000,000 TPM, Launch at 10,000 RPM and 4,000,000 TPM, and Grow at 15,000 RPM and 40,000,000 TPM¹. These grow as your spend grows.

What AWS publishes for Bedrock

The Bedrock OpenAI page lists Terra alongside GPT-6.1 Sol, GPT-6 Sol, Luna and Astra, and the GPT-5.6 line². The facts AWS states about the OpenAI models on Bedrock come mostly from its general-availability post, which covers GPT-5.5, GPT-5.4 and Codex, not Terra⁴:

• Calls go through the Responses API, and AWS says you pay the same per-token rate as direct from OpenAI with no additional fees.
• Each customer gets an isolated queue with automated capacity management.
• Calls inherit IAM permissions, VPC and PrivateLink isolation, KMS encryption and CloudTrail logging, and prompts and responses are not used to train models or shared with model providers.
• Codex on Bedrock usage counts toward existing AWS commitments, and inference stays within your selected Region.

Read those as the pattern AWS follows for OpenAI models, not as a guarantee for Terra. The post is dated June 1, 2026 and predates the GPT-6.1 line, so it cannot name Terra.

Bedrock also has its own tiering: Standard, Flex, Priority and Reserved⁵. You select a tier with an extra parameter at invoke time, Priority is described as up to 25% better output tokens per second for most supporting models, and Reserved sells guaranteed tokens-per-minute capacity for one or three months at a fixed price per 1K tokens per minute⁶. Which tiers Terra supports is something AWS sends you to its documentation for, so check it. The pricing page's Batch statement, at 50% below on-demand, names models from Anthropic, Meta, Mistral AI and Amazon, not OpenAI⁵. Do not assume batch exists for Terra on Bedrock.

Side by side: what to compare

Billing and commitments

Billing is usually why an AWS shop looks at Bedrock at all. On Bedrock the charge appears on your AWS invoice; on the direct path it appears on OpenAI's. Rates on the OpenAI side are a list rate, and your own agreement may differ. Whatever your contract says is what matters for cost per successful task, so use it.

Three checks make the difference:

1. Rate parity. Ask AWS for the Terra rate per tier and region, in writing. Do not rely on the GPT-5.5 statement.
2. Commitment drawdown. AWS says Codex usage counts toward commitments⁴. Ask whether Terra inference does, and whether the share is 100%.
3. Extra line items. Priority and Reserved both change the effective rate on Bedrock⁶. A Reserved purchase is a fixed monthly cost whether or not you fill it, so its cost per successful task depends on utilization, not on tokens alone.

If drawdown is full and rates match, the commitment you already hold is the argument for Bedrock. If drawdown is partial, or rates differ, compute each path's cost with the effective rate and let the evaluation below decide.

Quotas, features and region handling

Quotas are separate systems with separate failure modes. OpenAI's grow with your usage tier, and the Terra limits above are per tier¹. Bedrock's are account and region quotas you read in the console, and the isolated queue AWS describes is what protects you from noisy neighbours, not a promise of higher throughput⁴. Estimate your peak tokens per minute from request logs, add the output you expect at your chosen reasoning effort, and compare the result against each path's limit before running a test at load.

On features, one rule of thumb: the stricter your use of tools, the more you should test the Bedrock path early. OpenAI states that Terra tool calling requires the Responses API and lists the hosted tools it supports, including computer use, MCP and web search¹. AWS's post says the Responses API is the way in on Bedrock for the models it covers⁴. Whether every hosted tool behaves the same on Bedrock is not something these pages settle. Run your actual tool schema on both.

On regional data handling, the two vendors work differently. OpenAI offers regional processing endpoints for a 10% uplift on models released on or after March 5, 2026³. On Bedrock, AWS says inference stays in the Region you select for Codex, and refers you to its regions page for model availability⁴. If your requirement is that data stays in a named region, the deciding evidence is the Bedrock model card and your AWS agreement, not this comparison. If a path cannot meet it, it is out of the evaluation regardless of cost.

An evaluation protocol: does Terra beat your current tier?

The decision metric is cost per successful task: the total cost of all attempts divided by the number that pass your check⁷. Cheaper tokens do not help if Terra fails more often or reasons longer. A small protocol:

1. Freeze a task set. 200 to 500 real, anonymised requests per task type, with the prompt, tools and expected result. Do not edit it between runs.
2. Write the check first. Schema validity, exact-match labels, tests passing, or a rubric applied to a human-reviewed sample. Silent failures need the sample.
3. Fix the configuration. Same prompt, same tool schema, same reasoning effort. Terra defaults to medium¹, so pin effort explicitly on both sides. Then repeat at one other effort, because effort moves output tokens and cost.
4. Run the current tier and Terra on one path. Record input, output and cached tokens and latency from the response's usage fields.
5. Price with your own rates. Use the effective rate you confirmed, not a list rate, and include cache writes if your prompt design uses them.
6. Compute the numbers and compare their bounds, not only the means.
7. Run the parity check. Send a random 100 of the same tasks to the second path and compare pass rate, output length and latency against the first.

from dataclasses import dataclass
from math import sqrt

@dataclass
class Run:
    passed: int
    total: int
    cost_usd: float  # sum of all attempts, priced at YOUR effective rates

def wilson_lower(passed: int, total: int, z: float = 1.96) -> float:
    p = passed / total
    d = 1 + z * z / total
    centre = p + z * z / (2 * total)
    margin = z * sqrt(p * (1 - p) / total + z * z / (4 * total * total))
    return (centre - margin) / d

def cost_per_success(r: Run) -> float:
    return r.cost_usd / r.passed if r.passed else float("inf")

def terra_wins(terra: Run, current: Run, min_pass_lower: float) -> bool:
    return (
        wilson_lower(terra.passed, terra.total) >= min_pass_lower
        and cost_per_success(terra) < cost_per_success(current)
    )

Decide with the lower bound, as the code does. With 300 tasks, a 91% observed pass rate has a lower bound a few points lower, and that is the figure to compare with the minimum your product can tolerate. If neither tier passes, the problem is the prompt, the context or the tools, not the model.

Choosing the path, and wiring it

A practical order of work, for a team with an AWS contract:

• Start the model evaluation where access exists today. If you have OpenAI credentials, run steps 1 to 6 there; if only AWS, run them on Bedrock. Either gives you the pass rate and token counts.
• Then confirm the Bedrock facts in the table, and run the parity check. Same pass rate within noise, a Terra rate you have in writing, and full commitment drawdown make Bedrock the default for AWS-contract workloads.
• Keep the other path as a fallback or a comparison. Two accounts mean two quotas, so a rate-limit or capacity problem on one does not stop the other. That only helps if both are tested with the same tasks.
• Pin the id and record the date. OpenAI lists a single snapshot, gpt-6.1-terra¹. Record the snapshot or id you tested and the date, and re-run when either side changes a rate or a model.

INFRO can sit under this test. You connect your own OpenAI account and your own Bedrock account (a Bedrock API key and a region); Bedrock models appear as aws-bedrock/<model id> for any model on your account⁸. A named route with weighted targets can send a share of traffic to each connection, usage records the model, latency, token counts and estimated provider cost per request, and negotiated rates you enter are used before the vendor's list rate. The model ids still come from your own accounts, so confirm them as above. Providers continue to bill you directly.

Failure modes to watch

• Comparing list rate to a contract rate. One side is at list and the other is negotiated, so the winner is the contract, not the model.
• Default effort differences. Terra defaults to medium¹; if the current tier's default differs, you are comparing effort levels, not models.
• Tool-schema drift. A tool that works on the Responses API on one path may behave differently on the other; test with real tool traffic.
• Long-context cliffs. Above 272K input tokens the full request is priced at 2x input and 1.5x output on OpenAI³. If a slice of your tasks crosses it, price that slice separately on each path.
• Quota hit under load. A clean evaluation at 5 requests per second says nothing about 500. Check the limit first.
• Treating Reserved as a rate. It is a capacity purchase billed monthly⁶; amortize it over the tokens you actually send.