Frontier models compared: GPT-6, Fable 5.1, Gemini, Grok

Four model families sit at the top of their vendors' price lists this autumn: OpenAI's GPT-6 Astra, Anthropic's Claude Fable 5.1, Google's Gemini 3.1 Pro and xAI's Grok 4.7. Comparisons of them tend to lead with benchmark charts. This one leaves benchmarks out and compares only what each vendor publishes about its own model — the facts that decide whether a model can run your workload at all, and what your provider will bill for it. Then it gives a method for the question the facts cannot answer: which one does your task well enough.

Every rate below is the vendor's own list rate, read on 2026-09-29. If your organization has negotiated rates with a provider, those are what you pay; the list rate is a reference point.

The four models on one page

GPT-6 Astra is described by OpenAI as its most capable model, built for the hardest end-to-end work¹. Claude Fable 5.1 is Anthropic's model for demanding reasoning and long-horizon agentic work². Gemini 3.1 Pro is published under the preview codes gemini-3.1-pro-preview and gemini-3.1-pro-preview-customtools, the second tuned for agentic work with custom tools and bash³. Grok 4.7 is served as grok-4.7, with a 500K-token context window and reasoning effort from low to xhigh⁴.

Three facts in that grid deserve attention before anything else:

• Gemini 3.1 Pro is a preview. Its model codes carry -preview³. That is a lifecycle fact, not a quality one, and it belongs in any production decision.
• Output limits differ by a factor of two. Astra and Fable 5.1 both allow 128K output tokens⁵²; Gemini 3.1 Pro allows 65,536³. Long generated documents or large code edits can hit the lower limit.
• Grok 4.7's window is 500K⁴, where the other three sit near one million. Astra's 1.05M window accepts at most 922K input tokens⁵.

All four accept images alongside text; Gemini 3.1 Pro also takes video, audio and PDF input³. All four support function calling and structured outputs according to their vendors⁵⁶³⁴.

List rates

Astra and Fable 5.1 list the same rates: $10 per million input tokens and $50 per million output tokens⁷⁸. Gemini 3.1 Pro lists $2 input and $12 output for prompts up to 200K tokens⁹. Grok 4.7 lists $2 input and $6 output under 200K¹⁰. See each model's reference page for the catalog entry INFRO estimates against: GPT-6 Astra, Claude Fable 5.1, Gemini 3.1 Pro and Grok 4.7.

A per-token rate is only half of a comparison, because the models do not produce the same number of tokens for the same work. A model that thinks longer, writes longer answers or needs a second attempt costs more per task at the same rate. That is why the method at the end divides by successful tasks, not by tokens.

Where the bills diverge: caching and long prompts

Two published rules change a bill more than the headline rate for many production workloads.

Cached input. Agents and assistants resend the same system prompt, tool definitions and history on every call, so cached-input pricing often decides the input bill. Fable 5.1 bills cache hits at 0.025x input, $0.25 per million, with 5-minute cache writes at $12.50 and 1-hour writes at $20⁸. Astra lists cached input at $1.00 and cache writes at $12.50⁷. Gemini 3.1 Pro lists context caching at $0.20 per million for prompts up to 200K, plus $4.50 per million tokens per hour of storage⁹. Grok 4.7 lists cached input at $0.50 below 200K⁴.

Long prompts. Each vendor treats a large prompt differently:

Other published options that affect cost

• Batch. OpenAI lists Astra's batch and flex tiers at $5 input and $25 output⁷; Anthropic lists Fable 5.1 batch at the same $5 and $25⁸; Google lists Gemini 3.1 Pro batch at $1 and $6 below 200K⁹. Batch suits work nobody is waiting for.
• Location. Anthropic applies a 1.1x multiplier when you pin inference to the US with inference_geo⁸. OpenAI charges a 10% uplift on regional processing endpoints for models released on or after March 5, 2026⁷. If your contracts require a region, compare the uplifted rates.
• Knowledge cutoff. Astra's is April 30, 2026⁵; Fable 5.1's reliable knowledge cutoff is June 2026². It matters for tasks that depend on recent facts without retrieval.

What this comparison cannot tell you

No table of published facts says which model writes the better contract summary, fixes the harder bug or follows your tool schema more reliably on your data. Vendors publish benchmark results for their own models, but a benchmark measures a benchmark. Your prompts, your tools, your documents and your definition of a correct answer are different, and differences in output length and retry rate change the real cost per task as much as the rate card does. See evaluating models on real workloads for how to build the evaluation set.

A method for choosing

1. Shortlist on facts. Remove any model that cannot run the task: too small a window, too low an output limit, a missing modality, a data-location option you need, or a preview status your policy rejects.
2. Build an eval set from real traffic. Fifty to a few hundred real inputs per task type, each with a check a machine or a reviewer can apply: schema valid, test suite passes, answer matches the reference.
3. Run every candidate on the same inputs through the same client, recording each request's estimated provider cost and outcome.
4. Compute cost per successful task — total estimated cost for the model divided by the number of tasks it passed — and route each task tier to the lowest-cost model that meets your pass rate. The companion piece on cost per successful task goes deeper on the metric.

Running the comparison through INFRO routes

INFRO does not score answers; your eval harness does. What INFRO contributes is one endpoint for every candidate on your own provider accounts, a record of each request, and an estimate of what your provider will bill for it.

Connect each provider account you want to test under Providers — OpenAI, Anthropic, Google AI (Gemini) and xAI each have a connection kind. Then call each candidate by its catalog id through the OpenAI-compatible endpoint, tagging the run so its requests can be grouped later:

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["INFRO_API_KEY"], base_url="https://api.infro.io/v1")

CANDIDATES = [
    "openai/gpt-6-astra",
    "anthropic/claude-fable-5.1",
    "google/gemini-3.1-pro",
    "xai/grok-4.7",
]

def run(task, model):
    resp = client.chat.completions.create(
        model=model,
        messages=task["messages"],
        extra_body={"metadata": {"workflow": "frontier-eval", "feature": task["kind"]}},
    )
    usage = resp.usage.model_dump()
    return {
        "request_id": resp.id,             # INFRO request id, req_...
        "model": resp.model,               # the model that actually served
        "passed": task["check"](resp.choices[0].message.content),
        "cost": usage.get("cost"),         # estimated provider cost; None if unpriced
    }

usage.cost is an estimate of what your provider will bill, and usage.price_source says whether it came from the list rate or from a rate you entered. Totals for the run come from GET /v1/usage?group_by=model&from=...&to=..., which returns requests, cost, unpriced requests, error rate and p50/p95 latency per model (usage analytics); individual requests are in GET /v1/requests?workflow=frontier-eval (request traces).

Two cautions. First, the catalog carries one rate per model, so a request above a vendor's long-prompt threshold is estimated at the base rate and reads low; if your prompts cross those thresholds, enter your own rate under Prices (billing) or compare against the provider's invoice. Second, if you have negotiated rates, enter them too, or the comparison will rank list prices you do not pay.

Once you have decided, put the choice behind a route: a stable name such as contract-review whose ordered targets name the chosen model first and a tested alternative second. The application keeps sending "model": "contract-review"; changing the model is a console edit, and every request's trace names the connection and model that served it. A weighted route can also send a small share of live traffic to a challenger, but it still falls through to other targets on failure, so group results by the model that served, not by which target was picked first (routing).

Your providers bill your accounts directly for every one of these requests, at your rates. INFRO's subscription is separate and is not priced per token.