DEV Community: Owen

Best LLM API Providers 2026: 4 Types and What Each Costs

Owen — Mon, 03 Aug 2026 04:36:02 +0000

Best LLM API Providers 2026: 4 Types and What Each Costs

TL;DR: There are four ways to buy LLM tokens in 2026 and they are not competing on the same axis. Native APIs sell the canonical price and day-zero features. Open-weight hosts sell cheap tokens, from $0.05/M on Together's gpt-oss-20B. Routers sell one key across many vendors, typically at list price with the cost moved into payment fees, 5.5% on card top-ups at OpenRouter. Cloud platforms sell procurement, and charge for it: partner-cloud regional endpoints run 10% over global, and Vertex's priority tier is 1.8x standard. The same Claude Opus 5 call costs $5/$25 per 1M tokens on three of the four. What actually differs is everything around the token.

TL;DR: Which Type Should You Buy From?

Your situation	Buy from	Why
You need a model the week it ships	Native API	Partner clouds and routers lag on new SKUs and on new features
Your bill is dominated by one open-weight model	Open-weight host	Serverless per-token, then dedicated GPUs once you saturate them
You call four vendors and want one invoice	Router	One key, one balance, one wire format if you want it
Finance already approved a cloud commitment	Cloud platform	The spend lands on an invoice that exists, which is often the whole argument
You need sub-second first tokens on a small model	Open-weight host	Groq publishes 560 tok/s on its `llama-3.1-8b-instant` and 1000 tok/s on its `openai/gpt-oss-20b`, at its own prices
You want a fallback route without a second contract	Router	Failover is the product, not a feature you build
Your data must stay in one legal region	Cloud platform or native residency	Both offer it, both charge about 10% for it
You are still deciding which model to use	Router	Swapping a model ID is cheaper than swapping an integration

Two ways to stop reading here. If you spend under about $200 a month on tokens, buy directly from whichever lab makes the model you like and revisit this when the number gets interesting; every optimization below is worth less than the afternoon you would spend on it. If you already run production traffic across more than two vendors, skip to the hidden-cost table, because that is where your money is actually going.

The Four Types, Side by Side

The useful distinction is not brand. It is who runs the GPUs, who sets the price, and who sends the invoice.

	Native API	Open-weight host	Router / aggregator	Cloud platform
Examples	OpenAI, Anthropic, Google, DeepSeek	Together, Fireworks, Groq	OpenRouter, ofox	Bedrock, Vertex AI, Microsoft Foundry
Runs the inference	Yes	Yes	No	Yes, or resells the lab
Model catalog	One lab's models	Open-weight only	Many labs, 100+ IDs	The cloud's partner list
Sets the price	Yes, this is list	Yes, competitively	Copies list, mostly	List plus platform surcharges
New model on day one	Yes	For open weights, yes	Usually within days	Often weeks
Auth	Bearer token	Bearer token	Bearer token	IAM roles, SigV4, service accounts
Billing	Card or invoice, per lab	Card, per host	One prepaid balance	Your existing cloud invoice
Failover across vendors	You build it	You build it	Built in	Within one cloud's catalog
Best at	Newest features, highest ceilings	Cost per token	Breadth and switching cost	Procurement and compliance

Everything below is that table at length, with the numbers I could verify.

Type 1: Native APIs

Buying from the lab that trained the model is the default, and for most teams it stays the right answer longer than the internet suggests.

You get three things nowhere else gives you reliably. New models on release day. Features that only exist first-party, like Anthropic's fast mode, which the pricing docs state is available on the Claude API only and not on partner-operated platforms. And the highest published rate-limit ceilings, since every other route is buying capacity from the same place you would be.

Here is what the three big labs actually charge, per 1M tokens, checked 2026-08-02.

Model	Input	Cached input	Output
Claude Fable 5	$10	$1	$50
Claude Opus 5	$5	$0.50	$25
Claude Sonnet 5	$2 (through Aug 31, then $3)	$0.20	$10 (then $15)
Claude Haiku 4.5	$1	$0.10	$5
gpt-5.6-sol	$5	$0.50	$30
gpt-5.6-terra	$2	$0.20	$12
gpt-5.6-luna	$0.20	$0.02	$1.20
gpt-5.5	$5	$0.50	$30
Gemini 3.6 Flash	$1.50	$0.15	$7.50
Gemini 3.5 Flash-Lite	$0.30	$0.03	$2.50

Two caveats before you use those numbers. OpenAI publishes separate short-context and long-context columns, and the figures above are the short-context tier. Long context is not a uniform multiplier: gpt-5.6-luna goes from $0.20/$1.20 to $0.40/$1.80, so input doubles while output rises by half. The Gemini figures are Vertex's Global tier, and several models in that line price non-global endpoints 10% higher, Gemini 3.5 Flash at $1.65/$9.90 against $1.50/$9.00.

Two things in that table are worth more than the headline prices. Every one of these labs discounts batch work by 50% on both input and output, which is the single largest lever available if any part of your workload can wait. And cached input runs at a tenth of fresh input across all three, so an agent with a stable system prompt is paying a fraction of what the list price implies. We worked that math out in detail in Anthropic vs OpenAI prompt caching.

The cost of going native is administrative and it compounds quietly. Four labs means four keys, four dashboards, four billing relationships, and four different rate-limit rulebooks that share no vocabulary. We compared five of those rulebooks side by side in LLM API rate limits compared and they disagree on almost everything, including what a "request" is.

Go native if you are standardized on one lab, if you need release-day access, or if your volume is large enough that you want a direct commercial conversation with someone. It stops being comfortable at the point where you are still evaluating models, where you want somewhere to fail over to on the afternoon one lab has a bad day, or where you are holding four keys and a finance team has started asking about them.

Type 2: Open-Weight Inference Hosts

This category exists because some model weights are public, which means the price is set by GPU economics rather than by whoever owns the model. Competition here is real, and the prices show it.

Model	Host	Input /1M	Output /1M
gpt-oss-20B	Together	$0.05	$0.20
gpt-oss-20B	Groq (`openai/gpt-oss-20b`)	$0.075	$0.30
LFM2.5-8B-A1B	Together	$0.03	$0.12
gpt-oss-120B	Together	$0.15	$0.60
gpt-oss-120B	Groq (`openai/gpt-oss-120b`)	$0.15	$0.60
Qwen3.5-397B-A17B	Together	$0.60	$3.60
Llama 3.3 70B	Together	$1.04	$1.04
Llama 3.3 70B	Groq (`llama-3.3-70b-versatile`)	$0.59	$0.79
DeepSeek V4 Flash	DeepSeek (native)	$0.14	$0.28

Prices as published on each vendor's pricing page, checked 2026-08-02.

Read that table by row pairs, because the duplicated model names are the point. Same published weights, and what you pay depends on whose cluster they run on. Together is cheaper on gpt-oss-20B, $0.05/$0.20 against $0.075/$0.30. Groq is cheaper on Llama 3.3 70B, $0.59/$0.79 against a flat $1.04/$1.04. They tie on gpt-oss-120B. Nobody wins the category, which is what you get in a market where the product is commoditized and the differentiation is scheduling. It also means throughput and price do not travel together: Groq's 1000 tok/s belongs to Groq's gpt-oss-20B at Groq's price, not to Together's cheaper listing of the same weights.

Two structural things separate this category from the rest.

The first is that you can graduate off per-token pricing. Together publishes dedicated H100 instances at $5.49/hour on demand and GPU clusters at $3.99 per GPU-hour, dropping to $3.19 with a reservation. Fireworks lists on-demand GPUs at $7.00/hour for an H100 or H200, $10.00 for a B200 and $12.00 for a B300. That gives you a break-even you can compute: a single H100 at $5.49/hour is about $4,000 a month, so once your serverless bill on a 20B-class model passes that and your traffic is steady rather than spiky, dedicated starts to win. Spiky traffic keeps you on serverless longer than the arithmetic suggests, because you pay for the idle hours too.

The second is a trap worth naming. Model availability on these hosts is not a promise. Groq's model docs split their catalog into production and preview, and the preview language is unusually direct: those models are "intended for evaluation purposes only and should not be used in production environments as they may be discontinued at short notice." At the 2026-08-02 check that list included qwen/qwen3.6-27b. If you pin a preview model ID in production you have accepted a dependency that the vendor has told you in writing not to accept.

This category earns its place on high volume against public weights, on latency-critical small-model work, and on anything you might eventually want to pull in-house and self-host with the same outputs. It is the wrong place to be if you need a frontier closed model, or if you need one specific model ID to still exist next quarter.

Type 3: Routers and Aggregators

A router does not run inference. It terminates your request, decides which upstream gets it, forwards it, and hands you back a normalized response. What you are buying is the absence of integration work: one key, one balance, one wire format, and a fallback path you did not have to build.

The pricing question people ask about this category is whether there is a markup, and the answer for the two biggest is more interesting than yes or no.

OpenRouter states plainly that it does not mark up inference: "We pass through the pricing of the underlying providers; there is no markup on inference pricing (however we do charge a fee when purchasing credits)." The revenue moves to the payment layer instead. Its FAQ puts the card fee at "a 5.5% ($0.80 minimum) fee when you purchase credits," crypto at 5%, and bring-your-own-key routing at "5% of what the same model and provider would normally cost on OpenRouter" once you pass the first 1M BYOK requests in a month. On a $600 monthly token spend the card fee is about $33. At $10,000 it is $550. We itemized every charge in OpenRouter pricing: the hidden 5.5% fee, and looked at production reliability separately in Is OpenRouter reliable?.

Since ofox is also in this category, the fair thing is to check our own price sheet the same way. Every model page I pulled on 2026-08-02, against the vendor's published list price:

Model ID	ofox listed	Vendor list	Match
`anthropic/claude-opus-5`	$5 / $25	$5 / $25	Yes
`anthropic/claude-sonnet-5`	$2 / $10	$2 / $10	Yes
`openai/gpt-5.5`	$5 / $30	$5 / $30	Yes
`google/gemini-3.6-flash`	$1.50 / $7.50	$1.50 / $7.50	Yes
`deepseek/deepseek-v4-flash`	$0.14 / $0.28	$0.14 / $0.28	Yes
`openai/gpt-5.6-luna`	$1 / $6	$0.20 / $1.20	No, 5x over

Five out of six at list, one materially over it. The Luna row is not a rounding error: OpenAI cut that model's list price by 80% on 2026-07-30 and the listing still showed the pre-cut tier three days later. The lesson applies to every router including this one. A gateway price sheet is a snapshot, and vendor list prices move without warning, so check the model page for the exact model ID on the day you plan to call it rather than extrapolating from anyone's reputation for being cheap. Same finding we hit in DeepSeek V4 Flash vs Gemini 3.6 Flash.

The other thing to check before picking a router is which wire formats it speaks, because your tooling does not get a vote. Claude Code wants the Anthropic Messages shape. Codex CLI wants OpenAI's. A router exposing only one of them puts a translation layer in your path. ofox documents three base URLs, one per protocol: https://api.ofox.ai/v1 for OpenAI Chat Completions, https://api.ofox.ai/anthropic for Messages, https://api.ofox.ai/gemini for Gemini. Its /v1/models returned 122 model IDs across 12 provider prefixes when I called it on 2026-08-02.

A router pays for itself while you are still choosing models, once you call more than two vendors, when you want failover you did not have to build, or when one prepaid balance is easier to defend than four card-on-file relationships. It is the wrong layer if you need a brand new SKU on day one, if you need a first-party-only feature, or if you have negotiated a volume discount directly with a lab. In that last case going through anyone else is strictly worse.

There are more than two products in this category. We ranked seven of them, with migration notes, in 7 best OpenRouter alternatives, and the general selection framework is in the LLM API gateway guide.

Type 4: Cloud Platforms

Amazon Bedrock, Google Vertex AI and Microsoft Foundry sell a different product from everyone above, and pretending otherwise is how teams end up disappointed by them. They sell procurement. The model is a line item on an invoice your company already pays, inside an account your security team already reviewed, billed against a commitment you may already have signed. For a large enough organization that is worth real money, and the token price is close to irrelevant.

The surcharges are real and they are documented.

Surcharge	Where	Amount
Regional or multi-region endpoint	Bedrock, Google Cloud	10% over global endpoints. Anthropic's docs scope this to Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 "and all future models", so Opus 5 and Sonnet 5 are included
Priority service tier	Vertex AI	1.8x standard. Google does not print the multiplier, but every Gemini row divides out to it: 3.6 Flash goes from $1.50/$7.50 to $2.70/$13.50
US-only inference geography	Claude API, Claude Platform on AWS, Foundry	1.1x on all token categories, Claude 4.6 and later
Provisioned throughput	Bedrock	Per model unit per hour, with no-commitment, 1-month and 6-month rates. In the Cohere section's Provisioned Throughput table, Cohere Command runs $49.50, $39.60 and $23.77 respectively
Batch / Flex tier	Bedrock, Vertex AI	Discount, not a surcharge: 50% off standard

Billing mechanics differ too, in ways that matter to whoever reconciles the invoice. Claude Platform on AWS and Claude in Microsoft Foundry both bill in Claude Consumption Units at a fixed $0.01 per CCU, metered hourly and invoiced monthly. Anthropic's docs describe that as "Arrears only (postpaid); no prepaid credits," and your cloud bill shows one CCU line item rather than a per-model breakdown. If your cost attribution depends on seeing which model spent what, that reconciliation happens in the vendor console, not in Cost Explorer.

Bedrock also prices per region, with separate tables for US East, Frankfurt, Sydney and others, and it splits inference into Standard, Flex, Priority and Reserved tiers. Provisioned throughput is quoted per model unit per hour rather than per token, and for Anthropic models the page does not publish a rate at all: it tells you to reach out to your account team, which is a fair summary of the whole category. Vertex charges cached input at 10% of standard, the same ratio as first-party.

Buy here when you have committed spend to burn down, when procurement treats a new vendor as a quarter-long project, or when compliance gets easier the moment traffic stays inside an account you already own. Buy elsewhere when you want the newest model, the lowest price, or an API key rather than an IAM role. Auth in this category is real work: SigV4 signing or service-account credentials instead of a bearer token, a day of engineering the first time and a little more every time a new service needs access.

Pricing Math: The Same Workload, Four Ways

List prices do not answer the question people are actually asking, which is what the invoice says. Three workloads I see repeatedly, at the rates verified above.

Workload A. Customer-facing assistant on a frontier model. 20M input and 5M output tokens per month on Claude Opus 5.

Route	Math	Monthly
Anthropic direct, global endpoint	20 × $5 + 5 × $25	$225
Router at list price	Same rates	$225
Partner cloud, regional endpoint	$225 × 1.10	$247.50
Anthropic Batch API, if the work can wait	20 × $2.50 + 5 × $12.50	$112.50

The type you buy from moves this bill by 10%. Whether the work can be batched moves it by 50%. That ordering holds for most teams, which is why "which provider is cheapest" is the wrong first question.

Workload B. Agent backend at volume. 200M input and 50M output tokens per month, cheap tier.

Route	Math	Monthly
DeepSeek V4 Flash, native rates	200 × $0.14 + 50 × $0.28	$42
gpt-oss-120B on Together	200 × $0.15 + 50 × $0.60	$60
gpt-5.6-luna, OpenAI list	200 × $0.20 + 50 × $1.20	$100
gpt-5.6-luna, via a listing still on the pre-cut tier	200 × $1 + 50 × $6	$500
Gemini 3.6 Flash	200 × $1.50 + 50 × $7.50	$675

The spread inside one quality tier is 16x, and one row of it is nothing but a stale price sheet. This is where checking the specific model page pays for itself in an afternoon.

Workload C. Offline classification. 500M input and 20M output tokens per month on Claude Haiku 4.5.

Route	Math	Monthly
Claude Haiku 4.5, Batch API at 50% off	500 × $0.50 + 20 × $2.50	$300
Claude Haiku 4.5, standard rates	500 × $1 + 20 × $5	$600
Gemini 3.6 Flash on Vertex, standard tier	500 × $1.50 + 20 × $7.50	$900
Gemini 3.6 Flash on Vertex, priority tier	500 × $2.70 + 20 × $13.50	$1,620

The first two rows are the same request to the same model, a factor of two apart, separated only by whether you were willing to wait. Add the model and tier choice and the spread across one unremarkable workload runs from $300 to $1,620. Almost nobody who could be running workload C in batch mode actually is.

The Costs That Don't Show Up on the Price Page

Every category has one line item that is invisible until it arrives.

Type	The invisible cost	What it looks like
Native	Integration multiplied by vendor count	Four SDKs, four retry policies, four rate-limit rulebooks with no shared vocabulary
Native	Tokenizer changes	Anthropic's docs note Claude 4.7 and later use a tokenizer producing about 30% more tokens for the same text, so a same-price model upgrade can still raise your bill
Open-weight host	Idle GPU hours	Dedicated capacity bills the trough as well as the peak; spiky traffic burns the break-even
Open-weight host	Catalog churn	A preview model ID can be withdrawn at short notice, by the vendor's own warning
Router	Payment fees	5.5% card top-up at OpenRouter, plus 5% for BYOK past 1M monthly requests
Router	Price-sheet lag	The Luna row above: 5x over list for three days after a vendor cut
Cloud	Auth engineering	IAM roles and request signing instead of a bearer token, once per service
Cloud	Surcharge stacking	Regional 1.10 × priority 1.8 compound before you notice
All four	Not batching	50% left on the table on every workload that could have waited an hour

The tokenizer line is the one nobody plans for. A model upgrade at identical per-token pricing can still raise your invoice if the new tokenizer is denser, and no price-comparison table will show you that.

When You Need Two Types, and When One Is Enough

One type is enough when your traffic runs on one or two models, an hour of downtime is an annoyance rather than an incident, and your monthly spend is small enough that a 10% difference is not worth an integration. That describes most teams for longer than they expect.

You want a second type once one of three things is true. A model outage costs you more than the fallback would cost to build, in which case a router is the cheapest second route because failover is what it sells. Your finance process cannot absorb another vendor, in which case a cloud platform solves a problem no amount of price optimization will. Or your volume on one specific model is large enough that a dedicated deployment beats per-token pricing, which puts you on an open-weight host regardless of what else you run.

The pairing that shows up most often is a native key plus a router. The native key carries primary traffic and gets you release-day models and the highest rate-limit ceiling. The router is the escape hatch, already integrated, holding a small balance, one model-ID string away from taking over.

What you should not do is buy a second vendor of the same type and call it redundancy. Two routers pointed at the same upstream provider fail together.

Switching Types Without Rewriting Your Client

Type selection is reversible because three of the four categories speak the OpenAI Chat Completions shape. Native OpenAI, most open-weight hosts and most routers accept the same request body, so the base URL and the model string are the only things that change.

Python

import os
from openai import OpenAI

ROUTES = [
    ("https://api.openai.com/v1",  "gpt-5.6-luna"),
    ("https://api.ofox.ai/v1",     "deepseek/deepseek-v4-flash"),
    ("https://api.ofox.ai/v1",     "anthropic/claude-opus-5"),
]

for base_url, model in ROUTES:
    client = OpenAI(base_url=base_url, api_key=os.environ["API_KEY"])
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Summarize this in one line."}],
    )
    print(model, r.usage.total_tokens, r.choices[0].message.content[:80])

Node

import OpenAI from "openai";

const routes = [
  ["https://api.openai.com/v1", "gpt-5.6-luna"],
  ["https://api.ofox.ai/v1", "deepseek/deepseek-v4-flash"],
  ["https://api.ofox.ai/v1", "anthropic/claude-opus-5"],
];

for (const [baseURL, model] of routes) {
  const client = new OpenAI({ baseURL, apiKey: process.env.API_KEY });
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: "Summarize this in one line." }],
  });
  console.log(model, r.usage.total_tokens, r.choices[0].message.content.slice(0, 80));
}

Run that loop against your own prompts before committing to a type. Token counts vary more between models than prices do, and a model 3x cheaper per token that spends 4x the output tokens is not cheaper. The ofox model catalog has current per-model rates if you want today's numbers rather than this article's.

Cloud platforms are the category that does not fit this pattern, which is the honest reason they are more work. Bedrock and Vertex want signed requests and platform SDKs, so moving onto or off them is a migration rather than two edited strings.

Sources Checked for This Refresh

Anthropic model pricing, batch, caching, partner-cloud and CCU billing: platform.claude.com/docs/en/about-claude/pricing (checked 2026-08-02)
OpenAI GPT-5.x list pricing and batch discount: developers.openai.com/api/docs/pricing (checked 2026-08-02)
Vertex AI Gemini pricing, standard and priority tier tables, global vs non-global rates, batch discount: cloud.google.com/vertex-ai/generative-ai/pricing, which now redirects to the Agent Platform pricing page (checked 2026-08-02)
Amazon Bedrock pricing tiers, batch discount, provisioned throughput commitments, per-region tables: aws.amazon.com/bedrock/pricing (checked 2026-08-02)
OpenRouter fee structure, all quotes: openrouter.ai/docs/faq (checked 2026-08-02)
Together serverless, dedicated and cluster pricing: together.ai/pricing (checked 2026-08-02)
Fireworks on-demand GPU pricing: fireworks.ai/pricing (checked 2026-08-02)
Groq production vs preview model policy, per-token prices and throughput figures: console.groq.com/docs/models (checked 2026-08-02)
ofox per-model pricing and catalog size: model pages under ofox.ai/models/, plus a live GET /v1/models call; protocol base URLs from ofox.ai/llms-full.txt (checked 2026-08-02)

Originally published on ofox.ai/blog.

DeepSeek V4 Flash vs Gemini 3.6 Flash: Tied Score, 10x Price

Owen — Sun, 02 Aug 2026 00:36:27 +0000

DeepSeek V4 Flash vs Gemini 3.6 Flash: Tied Score, 10x Price

TL;DR: DeepSeek V4 Flash 0731 and Gemini 3.6 Flash both land on 50 on the Artificial Analysis Intelligence Index v4.1, with GPT-5.6 Luna one point ahead at 51. Their list prices span more than an order of magnitude. The interesting part is what happens when you stop comparing price tags and start comparing invoices for the same evaluated workload. Artificial Analysis publishes what it paid to run each one: $72.02 for DeepSeek, $190.87 for Luna, $726.70 for Gemini. The sticker gap on output price is 27x. The gap on the actual bill is 10.1x, because DeepSeek burned 210M output tokens on that run to Gemini's 59M. Both numbers say buy DeepSeek if your workload is text; neither of them survives contact with a pipeline that sends images.

TL;DR: Which One Should You Pick?

Your situation	Pick	Why
Text-only, high volume, cost is the constraint	DeepSeek V4 Flash 0731	Cheapest per token by ~10x, and a 98% cache discount on top
Anything with images, audio, video or PDFs	Gemini 3.6 Flash	DeepSeek 0731 is text only; there is no cheaper workaround
Interactive UX where latency is visible to a user	Gemini 3.6 Flash	~220 output tokens/sec, and the lowest TTFT of the three on AA's runs
Long single generations (full files, long reports)	DeepSeek V4 Flash 0731	384K max output vs Gemini's 64K
You want the top index score and vision on one model	GPT-5.6 Luna	51 on the index, vision, and an 80% price cut on 2026-07-30
Bounded agent loops where you can cache aggressively	DeepSeek V4 Flash 0731	Cache reads at $0.0028/M, the lowest of the three by a wide margin
You need reproducible third-party latency numbers today	Gemini 3.6 Flash or GPT-5.6 Luna	AA had no speed or TTFT data for the 0731 build at snapshot

Two ways to stop reading here. If your workload sends any non-text input, the second row settles it and the rest of this article is background. If your workload is text and runs under about 20M tokens a month, the annual difference between the cheapest and most expensive option above is smaller than a day of engineering time, so pick on latency and move on. Everything below is written for the case where the bill is large enough to argue about.

What Actually Changed on July 31

DeepSeek shipped a new build of V4 Flash on 2026-07-31 and did not change the model. Same 284B total parameters, same 13B active, same 1M context, same $0.14 / $0.28 price. The API model name is unchanged too, deepseek-v4-flash, with the build identified in DeepSeek's docs as model version DeepSeek-V4-Flash-0731. What changed is post-training.

The measured effect is larger than "post-training only" usually implies. On the Artificial Analysis Intelligence Index v4.1, the score went from 40 to 50. AA's agentic evaluation, GDPval-AA v2, moved from 1189 Elo to 1559. Terminal-Bench 2.1 gained 17 points to reach 79%. AA also places the 0731 build 6 points ahead of DeepSeek V4 Pro, DeepSeek's own flagship, which is an awkward result for anyone who wrote routing rules on the assumption that Pro handles the hard cases.

We were among those people. Our DeepSeek V4 Pro vs Flash routing guide from May concluded that multi-file work and long agent loops belonged on Pro. For the 0731 build that conclusion no longer holds, and the honest version is that Flash is now the default and Pro is the exception you justify.

The weights landed faster than anyone said they would. AA's launch coverage described full weights as expected "in the coming weeks", and most secondary coverage still repeats that. Checked on 2026-08-01, deepseek-ai/DeepSeek-V4-Flash-0731 on Hugging Face already carries the model as 48 safetensors shards under MIT, ungated. If you read somewhere that 0731 is API-only, that was true for about a day.

One caveat worth stating before the numbers start. The Intelligence Index is a rolling leaderboard, and everything below is a 2026-08-01 snapshot. Treat the ordering as the durable fact and the absolute score as a reading taken on a particular day.

Quick Specs Comparison

Feature	DeepSeek V4 Flash 0731	Gemini 3.6 Flash	GPT-5.6 Luna
ofox model ID	`deepseek/deepseek-v4-flash`	`google/gemini-3.6-flash`	`openai/gpt-5.6-luna`
AA Intelligence Index v4.1	50	50	51 🏆
Released	2026-07-31 (0731 build)	2026-07-21	2026-07-09
Input price (vendor list)	$0.14/M 🏆	$1.50/M	$0.20/M
Output price (vendor list)	$0.28/M 🏆	$7.50/M	$1.20/M
Cached input	$0.0028/M 🏆	$0.15/M	$0.02/M
Context window	1M	1M (1,048,576)	1M
Max output	384K 🏆	64K (65,536)	128K
Input modalities	Text	Text, image, video, audio, PDF 🏆	Text, image
Output speed (AA)	not published at snapshot	219.6 tok/s 🏆	172.1 tok/s
Time to first token (AA)	not published at snapshot	15.11s 🏆	121.89s
Open weights	Yes, MIT on Hugging Face 🏆	No	No
Wire protocols	OpenAI, Anthropic, Responses	OpenAI, Gemini	OpenAI, Anthropic, Responses

Two rows deserve a second look. Max output is a real separator: 384K against 64K is the difference between generating a long file in one call and building a continuation loop. And the empty latency cells are not a formatting accident. AA's provider page for the 0731 build listed no speed or time-to-first-token data at the 2026-08-01 snapshot, so anyone quoting you a tokens-per-second figure for this build is quoting something else.

The Benchmark Picture: One Point Separates Three Models

Here is the AA sub-score detail for the 0731 build, with the delta against the April build where AA published one.

Evaluation	DeepSeek V4 Flash 0731	Change vs April build
Intelligence Index v4.1	50	+10
GDPval-AA v2 (Elo)	1559	+370
Terminal-Bench 2.1	79%	+17
GPQA Diamond	91%	+1
AA-LCR	66%	+3
SciCode	50%	+5
Humanity's Last Exam	37%	+5
τ³-Bench Banking	31%	+8
CritPt	17%	+9
AA-Omniscience Index	-16	+7

The Omniscience row is the one people skip. AA reports that the improvement came from fewer hallucinations rather than from knowing more, with accuracy flat. For a model you are about to point at production traffic, "wrong less often" is a more useful upgrade than "knows more", and it is the sort of thing a single composite score hides.

Two sourcing notes, because this release has more than one set of numbers floating around.

DeepSeek's own release materials report Terminal-Bench 2.1 at 82.7, DeepSWE at 54.4 and Cybergym at 76.7. Artificial Analysis reports Terminal-Bench 2.1 at 79%. Both can be correct; harnesses, scaffolds and effort settings differ, and there was no third-party reproduction of the DeepSWE and Cybergym figures at snapshot time. We are using AA's numbers throughout because they are the only ones measured the same way across all three models here. If you see 82.7 quoted somewhere, that is the vendor's harness, not a contradiction.

The other one: the LMArena score attached to DeepSeek V4 Flash on most catalog pages, including ours, reads 1438 Overall with a rank in the seventies, updated 2026-07-12. That predates the 0731 build by nineteen days. It measures the April model. Arena scores for the new build will need new votes, and until then the number sitting next to "DeepSeek V4 Flash" on any comparison page is describing a model that scored 10 points lower on AA.

The Verbosity Tax: Why the Sticker Gap Is Not the Bill Gap

Every comparison of these two models leads with $0.14 against $1.50 and stops there. That ratio is real, and it is also the least reliable number in this article, because it prices a token rather than a job.

Artificial Analysis publishes something better: what it actually paid to run each model through the same Intelligence Index suite, invoice included.

Model	Output tokens for the index run	AA's total cost for the run
DeepSeek V4 Flash 0731	210M	$72.02
GPT-5.6 Luna	130M	$190.87
Gemini 3.6 Flash	59M	$726.70

Same evaluation, three real bills. Gemini costs 10.1x what DeepSeek costs, and Luna 2.7x. Against the sticker ratios of 27x and 4.3x on output price, that is roughly 60% of DeepSeek's paper advantage disappearing somewhere between the price card and the invoice.

Where it goes is tokens. DeepSeek spent 210M output tokens on that suite against Gemini's 59M, which AA flags as very verbose against the field. Price the output leg alone at list rates and you get $58.80 for DeepSeek, $156.00 for Luna and $442.50 for Gemini, a 7.5x gap on that leg. The shape of the two bills differs accordingly: output is about 82% of what DeepSeek's run cost and about 61% of Gemini's. That is the signature of a model that writes three and a half times as much to reach the same score. AA does not publish input token counts per model, so the remainder is not decomposable any further from published figures.

Which number you plan against depends on your traffic. A workload that is mostly prompt tracks the input ratio, 10.7x. A workload that is mostly generation gets compressed toward 7.5x by the verbosity. AA's end-to-end figure of 10.1x sits between them, on a suite that is itself a mix, which is why 10x is a better default than 27x for anything you have to defend in a budget review.

Two caveats on the token counts. They come from AA's max-effort and high-effort configurations, which is the expensive end of each model's range rather than a typical production setting. And verbosity is workload dependent; a suite full of hard reasoning problems flatters models that reason briefly, and your extraction pipeline is not that suite.

One footnote on the 210M, since two AA numbers circulate. The model page reports 210M output tokens for the index run; AA's launch article reports ~206M, alongside the more interesting fact that this is 12% fewer output tokens than the previous V4 Flash build spent (~234M). So 0731 is both more verbose than its peers and less verbose than its own predecessor. We use 210M throughout because the model-page figure is the one published the same way for all three models here.

The lever, though, is real and it is one flag. DeepSeek's docs list deepseek-v4-flash as supporting both non-thinking and thinking modes, with thinking as the default, and reasoning tokens bill as output. For bounded work, turning thinking off is where the verbosity tax goes away.

Measure it on your own traffic

AA's ratio is a starting estimate, not your number. Getting your own takes one run over a sample of your real prompts, because every OpenAI-compatible response carries the token counts you need:

import collections
from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_API_KEY")

costs = {  # input, output, per 1M tokens
    "deepseek/deepseek-v4-flash": (0.14, 0.28),
    "google/gemini-3.6-flash": (1.50, 7.50),
    "openai/gpt-5.6-luna": (0.20, 1.20),
}
totals = collections.defaultdict(float)

for prompt in load_your_real_prompts():        # 50 is enough to see the shape
    for model, (pin, pout) in costs.items():
        u = client.chat.completions.create(
            model=model, messages=[{"role": "user", "content": prompt}]
        ).usage
        totals[model] += (u.prompt_tokens * pin + u.completion_tokens * pout) / 1e6

for model, spend in sorted(totals.items(), key=lambda kv: kv[1]):
    print(f"{model:32} ${spend:.4f} over the sample")

Fifty representative prompts cost a few cents to run across all three and will tell you more than any leaderboard. Two things to watch for. Run it twice with thinking on and off for DeepSeek, since that flag moves the output column more than the model choice does. And sample from your actual traffic distribution rather than your hardest cases, because verbosity ratios measured on hard reasoning problems do not transfer to a queue full of two-line classifications.

Pricing Math: Two Real Monthly Bills

All prices below are vendor list, snapshot 2026-08-01, per 1M tokens.

Scenario A, an extraction pipeline. 200M input tokens and 10M output tokens per month, no caching, short structured outputs.

Model	Input cost	Output cost	Monthly total
DeepSeek V4 Flash 0731	$28.00	$2.80	$30.80
GPT-5.6 Luna	$40.00	$12.00	$52.00
Gemini 3.6 Flash	$300.00	$75.00	$375.00

Input dominates, so this scenario tracks the input-price ratio closely: Gemini costs 12x DeepSeek, Luna 1.7x. Note how much the July 30 price cut changed Luna's position here. At the old $1 / $6 the same workload was $260 a month.

Scenario B, a coding agent loop. 100M input tokens at a 70% cache hit rate and 40M output tokens per month.

Model	Cached input	Fresh input	Output	Monthly total
DeepSeek V4 Flash 0731	$0.20	$4.20	$11.20	$15.60
GPT-5.6 Luna	$1.40	$6.00	$48.00	$55.40
Gemini 3.6 Flash	$10.50	$45.00	$300.00	$355.50

That table holds tokens constant, which quietly assumes all three models write the same amount to do the same job. They do not. Holding the work constant instead, and scaling output by the verbosity ratios from the index run, gives a fairer picture of the same agent loop:

Model	Output tokens for equal work	Monthly total
DeepSeek V4 Flash 0731	142M	$44.16
GPT-5.6 Luna	88M	$113.00
Gemini 3.6 Flash	40M (baseline)	$355.50

DeepSeek goes from 23x cheaper to 8x cheaper. The decision does not change. The number you put in a slide should.

For the deeper version of this arithmetic on DeepSeek specifically, including what cache misses do to a real bill, see our V4 Pro cost breakdown and the DeepSeek V4 API pricing guide.

Two Pricing Details That Will Move Your Bill

DeepSeek is about to introduce peak-hour pricing. Its pricing docs carry a footnote: the API will adopt a peak/off-peak policy under which peak-hour prices are 2x regular prices, applicable to all billing items, with the effective date pending official announcement. The peak windows are 09:00 to 12:00 and 14:00 to 18:00 Beijing time, UTC+8.

Translate that to your own clock before you assume it is harmless. Those windows land at 21:00 to 00:00 and 02:00 to 06:00 US Eastern, which is the middle of the night for a US-daytime workload, and at 03:00 to 06:00 and 08:00 to 12:00 Central European, which eats a European team's entire morning. If you run in Europe and DeepSeek turns this on, your $0.14 becomes $0.28 for the first half of the working day. That is still under Gemini, but it is not the number you budgeted.

The route you buy through can differ from the vendor's list price. OpenAI cut GPT-5.6 Luna by 80% on 2026-07-30, from $1 / $6 to $0.20 / $1.20. Listings that serve Luna through Azure had not moved at the 2026-08-01 snapshot, including ours, where openai/gpt-5.6-luna is an Azure route showing $1 / $6 list. Same model ID, 5x apart, purely on which upstream you land on.

Model	Route at snapshot	Input	Output	Cached input
DeepSeek V4 Flash 0731	DeepSeek first-party	$0.14	$0.28	$0.0028
DeepSeek V4 Flash 0731	Aliyun BaiLian	$0.14	$0.28	$0.028
DeepSeek V4 Flash 0731	Azure	$0.19	$0.51	$0.19
Gemini 3.6 Flash	Google / Vertex	$1.50	$7.50	$0.15
Gemini 3.6 Flash	Google batch or flex	$0.75	$3.75	$0.075
GPT-5.6 Luna	OpenAI first-party	$0.20	$1.20	$0.02
GPT-5.6 Luna	Azure	$1.00	$6.00	$0.10

Two footnotes on that table. Our Luna listing was running a 20% promotion at snapshot, which takes the Azure route to an effective $0.80 / $4.80, still four times the OpenAI list price. And the cache-read column deserves its own look: on the Azure DeepSeek route, cache reads cost the same as fresh input, which deletes the single largest cost advantage this model has.

The general rule the table teaches: check the route, not the model name. A price cut announced by a lab reaches that lab's own API immediately and everyone else on their own schedule. Two of the seven rows above are the same model at very different money.

What Text-Only Actually Costs You

The cheapest model in this comparison cannot see. DeepSeek V4 Flash 0731 accepts text, calls functions, returns JSON and speaks both the OpenAI and Anthropic wire formats, and that is the whole list. Gemini 3.6 Flash takes text, image, video, audio and PDF. GPT-5.6 Luna takes text and image.

This is not a quality gap you can close with prompt engineering or a bigger budget. If your pipeline sends screenshots of a broken UI, scanned invoices, or frames from a video, the DeepSeek call does not fail gracefully at a higher price. It fails structurally. Every cost table above becomes irrelevant for that class of work, which is why the modality row sits near the top of the specs table rather than buried at the bottom.

A common resolution is to split the traffic: multimodal requests to Gemini, everything else to DeepSeek, one router in front. That is more work than picking one model, and for a pipeline where 90% of requests are text it usually pays for itself in the first month.

When to Pick DeepSeek V4 Flash 0731

Text-only workloads at volume, where the bill is a real line item. Anything with a high cache hit rate benefits disproportionately, because $0.0028/M cache reads are a 98% discount on fresh input, a 50x reduction. Long single generations favor it as well: 384K max output is six times Gemini's ceiling. It is also the only one of the three with published weights, MIT-licensed on Hugging Face, so if the plan is to prototype on an API and self-host later, this is the one with a path.

Turn thinking off for bounded work. It is the difference between the $15.60 and the $44.16 rows above.

When to Pick Gemini 3.6 Flash

Whenever a non-text modality is involved, which settles it before price enters the conversation. Also when latency is user-visible: 219.6 output tokens per second put it third of 185 models on AA's speed ranking at snapshot, and 15.11 seconds to first token is fast for a reasoning model. And when you want a third party to have measured the thing you are about to depend on, since AA has published speed and latency for Gemini and had not for the 0731 build.

The batch tier is underrated. At $0.75 / $3.75 for work that tolerates delay, Gemini's effective distance from DeepSeek halves.

When to Pick GPT-5.6 Luna

When you want the highest index score of the three and vision in the same model, and the 80% price cut has made that combination affordable in a way it was not three weeks ago. Luna at $0.20 / $1.20 is now closer to DeepSeek than to Gemini on price while scoring a point higher than both.

Two things to check first. The 121.89 second time to first token that AA measured is the max-effort configuration, and max effort is not an interactive setting; if you use Luna in a UI, use a lower effort level. And confirm which route your gateway puts you on, because the pre-cut Azure tier is 5x the OpenAI list price. Our GPT-5.6 tier guide covers how Sol, Terra and Luna divide the work.

When None of the Three Is the Right Answer

If your workload is small, none of this matters. At a few million tokens a month the difference between the cheapest and most expensive option here is a rounding error against an hour of engineering time, and you should pick on capability and move on.

If you are chasing zero, a hosted API is the wrong tool. The free and self-hosted paths for this model family are a separate exercise with real caps attached, covered in DeepSeek V4 Flash free: four zero-cost paths. Those paths were verified against the build that preceded 0731, so recheck the caps before relying on them. The self-host route has changed since: the 0731 weights are now on Hugging Face under MIT, so the license-free option applies to the current build rather than the April one.

And if the job is deep multi-step agentic work with tool calls in the double digits, none of these three flash-tier models is an obvious fit. That is frontier-tier territory, and the honest answer is to benchmark on your own traces rather than on anyone's index. Our earlier Gemini Flash Lite vs DeepSeek V4 Flash agent-loop comparison walks through how tool-call reliability changes the math at depth.

Try All Three via ofox: A/B in One Loop

All three run on one OpenAI-compatible endpoint, so the comparison is a string swap rather than three integrations. The model IDs are deepseek/deepseek-v4-flash, google/gemini-3.6-flash and openai/gpt-5.6-luna.

Python

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_API_KEY")

MODELS = [
    "deepseek/deepseek-v4-flash",
    "google/gemini-3.6-flash",
    "openai/gpt-5.6-luna",
]

prompt = "Refactor this function to remove the nested loop. Return only code."

for model in MODELS:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(f"{model:32} in={u.prompt_tokens:6} out={u.completion_tokens:6}")

Log completion_tokens and not just latency. That column is where the verbosity difference shows up on your own traffic, and it is the number the sticker price does not tell you.

Node

import OpenAI from "openai";

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

const models = [
  "deepseek/deepseek-v4-flash",
  "google/gemini-3.6-flash",
  "openai/gpt-5.6-luna",
];

for (const model of models) {
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: "Summarize this changelog in 3 bullets." }],
  });
  console.log(model, r.usage.prompt_tokens, r.usage.completion_tokens);
}

The call DeepSeek cannot run

Same client, same endpoint, one content block that changes everything. Send this to google/gemini-3.6-flash or openai/gpt-5.6-luna and you get an answer. Send it to deepseek/deepseek-v4-flash and there is no price at which it works.

import base64

img = base64.b64encode(open("screenshot.png", "rb").read()).decode()

r = client.chat.completions.create(
    model="google/gemini-3.6-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Which element is misaligned?"},
            {"type": "image_url",
             "image_url": {"url": f"data:image/png;base64,{img}"}},
        ],
    }],
)
print(r.choices[0].message.content)

Alternatives

If none of the three fits, the neighbors worth checking are on the same endpoint. DeepSeek V4 Pro at $0.435 / $0.87 list, which the ofox listing rounds to $0.45 / $0.88, is now the more expensive and lower-scoring sibling on AA's index, though it remains the right call if you have workload-specific evidence that it wins on your traces. GPT-5.6 Terra sits above Luna when the flash tier is genuinely not enough. Outside the ofox catalog, the same models are available first-party from DeepSeek, Google AI Studio and the OpenAI API, which is the right choice if you only ever need one vendor and want the price cut the day it lands rather than whenever the route catches up.

Model pages with live pricing: DeepSeek V4 Flash, Gemini 3.6 Flash, GPT-5.6 Luna.

Sources

Originally published on ofox.ai/blog.

Codex CLI 401 Unauthorized: 9 Tested Causes and Lookalikes

Owen — Sat, 01 Aug 2026 11:37:09 +0000

TL;DR: Codex CLI auth breaks in nine distinct ways, and only some of them arrive as a literal 401, which is exactly why the status code is the least useful part of the output. The message body is what identifies the cause. Missing bearer or basic authentication in header means nothing was sent, and the surprise there is that exporting OPENAI_API_KEY does not help on the default provider. Incorrect API key provided means your key arrived and was rejected. You didn't provide an API key means the header was dropped in transit, almost always because the value ends with a newline. A local Missing environment variable error is not a 401 at all, and neither is a 404 from a base_url that lost its /v1. Every case below was reproduced on Codex CLI 0.146.0 on 2026-07-30.

The 30-Second Diagnosis

Three checks, in this order. Most people skip the first one and spend twenty minutes re-issuing a key that was fine.

Check	Command	What it tells you
1. Did a request even happen?	Look for `Missing environment variable` in the output	If present, Codex never made a network call. Your config points at a variable that is unset or empty.
2. What does the 401 body say?	Read the text after `401 Unauthorized:`	Three distinct messages, three distinct causes. See the table below.
3. Does the key work at all?	`curl -s -o /dev/null -w "%{http_code}" -X POST https://api.ofox.ai/v1/responses -H "Authorization: Bearer $YOUR_KEY" -H "Content-Type: application/json" -d '{"model":"openai/gpt-5.5","input":"hi","max_output_tokens":16}'`	200 means the key is good and the problem is in your Codex config. 401 means the key itself is the problem.

One trap in step 3 worth calling out early, because half the troubleshooting advice on the internet gets it wrong: do not use /v1/models as a key check on an aggregator. Tested on 2026-07-30, https://api.ofox.ai/v1/models returns 200 with the full catalog when sent with a bogus key, and also with no Authorization header at all. The model catalog is public. OpenAI's own api.openai.com/v1/models does return 401 without a key, which is where the habit comes from, but the habit does not transfer. Use an endpoint that actually runs inference.

When to Fix This, When to Switch, and When to Stop

Auth failures are cheap to fix when you know which one you have, and expensive when you guess. Rough rule:

Fix it when the message names a specific cause: Missing environment variable, Incorrect API key provided, or anything mentioning a refresh token. These have deterministic one-step fixes and take under two minutes each.
Switch the auth path when you are three attempts deep on the ChatGPT login flow. The API key path has fewer moving parts (no refresh tokens, no browser round trip, no 8-day refresh window), and if you are automating anything, it is the only path that survives a container restart.
Stop and check something else if you get 404 instead of 401, or if the CLI refuses to start with a config error. Those are not auth problems and no amount of key rotation will move them. Same if the error mentions a usage limit rather than authorization.

The one case where re-issuing a key is the right first move is Incorrect API key provided with the masked suffix shown in the error matching the key you think you are using. If the suffix does not match, you have a config problem, not a key problem, and a new key will fail identically.

Reading the 401: Three Messages, Three Causes

This is the core table. Every row was reproduced against a live endpoint.

Message body	What actually happened	Where it comes from	Fix
`Missing bearer or basic authentication in header`	No credential was attached to the request	Default OpenAI provider with no login, or with only `OPENAI_API_KEY` exported	`printenv OPENAI_API_KEY \
{% raw %}`Incorrect API key provided: sk-proj-****7890`	Header arrived, server rejected the value	Wrong, revoked, or cross-account key in auth.json	Re-issue the key, or log out and log in with the right one
`Invalid or expired API key`	Same as above, gateway-side wording	Custom provider whose `env_key` value is wrong or quote-wrapped	Check the variable's exact bytes, not just that it is set
`You didn't provide an API key. You need to provide your API key in an Authorization header using Bearer auth`	Header was malformed and dropped	Newline embedded in the key value	Strip the trailing newline from the variable
`Your access token could not be refreshed...`	ChatGPT OAuth refresh failed	Expired, reused, or revoked refresh token	`codex logout` then sign in again
`Missing environment variable: 'X'`	Not a 401. No request was made	`env_key` names a variable that is unset or empty	Export the variable in the shell that launches Codex

Two details from the test runs that make the output easier to read. On the default OpenAI provider, Codex first tries a WebSocket transport against wss://api.openai.com/v1/responses, retries five times, then falls back to HTTPS and retries five more, so a single auth failure produces roughly ten error lines before the real message. On a custom provider, WebSocket transport is off (codex doctor reports supports websockets: false), so you get one retry loop and a cleaner failure. If you are staring at a wall of Reconnecting... 4/5, scroll to the bottom; the last line is the one that matters.

Cause 1: You Exported OPENAI_API_KEY and Assumed That Was Enough

This is the single most common one, and it is counterintuitive enough that it deserves the top slot.

export OPENAI_API_KEY="sk-proj-..."
codex exec "say hi"
# ERROR: unexpected status 401 Unauthorized: Missing bearer or basic
# authentication in header, url: https://api.openai.com/v1/responses

Note what the server said: Missing bearer. Not "your key is wrong". Nothing was sent. The default provider in Codex 0.146.0 reads credentials from $CODEX_HOME/auth.json, not from the environment. Setting the variable changes nothing.

The single-variable proof: take the exact same invalid key, write it into auth.json instead of the environment, and the message changes.

echo "sk-proj-invalidkeyfortesting1234567890" | codex login --with-api-key
codex exec "say hi"
# ERROR: unexpected status 401 Unauthorized: Incorrect API key provided:
# sk-proj-**************************7890 ... auth error code: invalid_api_key

Same key, different message. The first run never sent it; the second did and got it rejected. That difference is the whole diagnostic.

Write the key where Codex will actually look for it:

printenv OPENAI_API_KEY | codex login --with-api-key

Environment variables do work, but only through a custom provider's env_key field, which is a different mechanism covered further down.

Cause 2: You Used the Old --api-key Flag

If you followed a tutorial written before mid-2026:

codex login --api-key "sk-proj-..."
# The --api-key flag is no longer supported. Pipe the key instead,
# e.g. `printenv OPENAI_API_KEY | codex login --with-api-key`.

The message is clear, but it exits without writing anything, and in a setup script the output scrolls past. The next command then fails with Missing bearer and the key gets blamed. Check that auth.json exists and contains what you expect:

cat ~/.codex/auth.json
# {
#   "auth_mode": "apikey",
#   "OPENAI_API_KEY": "sk-proj-..."
# }

Cause 3: env_key Points at a Variable That Is Not Set (Not a 401)

With a custom provider block, Codex reads the key from the environment variable you name:

model = "openai/gpt-5.5"
model_provider = "ofox"

[model_providers.ofox]
name = "Ofox"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"

If OFOX_API_KEY is unset, you do not get a 401. You get a local error and no network call at all:

ERROR: Missing environment variable: `OFOX_API_KEY`.

An empty string produces the identical error, which matches the source: model-provider-info/src/lib.rs filters the variable with !v.trim().is_empty() before using it. So export OFOX_API_KEY="" and never exporting it are the same thing as far as Codex is concerned.

This one bites hardest in launchd, systemd, and Docker, where the shell that starts Codex is not the shell where you exported the variable.

Cause 4: A Newline in the Key Value

This is the nastiest of the set, because the error accuses you of not providing a key that you can see with your own eyes in printenv.

export OFOX_API_KEY="$(cat ~/keys/ofox.txt)"   # file ends with a newline
codex exec "hi"
# ERROR: unexpected status 401 Unauthorized: You didn't provide an API key.
# You need to provide your API key in an Authorization header using Bearer
# auth (i.e. Authorization: Bearer YOUR_KEY). [ofox.ai]

The header was built with a newline inside it and dropped on the floor. The server genuinely never saw a credential, so its message is accurate; it just sounds like you forgot to set anything.

Worth knowing what is not a cause here, because it is the obvious suspect and it is innocent: a trailing space is fine. Tested with export OFOX_API_KEY="$REAL " and the request succeeded. Note that Codex is not cleaning it up for you: the trim() in api_key() is an emptiness check only, and the value it returns is the raw one, trailing space included. Something downstream tolerates it. A newline, by contrast, breaks the header outright. Either way, do not spend time hunting for stray spaces.

A quoted value, on the other hand, does fail, with different wording:

export OFOX_API_KEY='"sk-..."'   # literal quote characters in the value
# ERROR: unexpected status 401 Unauthorized: Invalid or expired API key

That one is common when a .env file is loaded with a naive export $(cat .env | xargs) that keeps the quotes.

Strip the offending bytes at export time and confirm the length:

export OFOX_API_KEY="$(tr -d '\n\r"' < ~/keys/ofox.txt)"
printf '%s' "$OFOX_API_KEY" | wc -c   # confirm the byte count matches the key length

Cause 5: The Provider Block Is Missing env_key Entirely

The quietest failure of the nine. Delete one line from the config above:

[model_providers.ofox]
name = "Ofox"
base_url = "https://api.ofox.ai/v1"
wire_api = "responses"
# env_key line deleted

Codex does not complain. It falls back to the credential in auth.json, which for most people is an OpenAI key, and sends that to the gateway. The gateway rejects it:

ERROR: unexpected status 401 Unauthorized: Invalid or expired API key,
url: https://api.ofox.ai/v1/responses

Your environment variable is set correctly. Your key is valid. The error says the key is invalid, because a different key was sent. Tested both ways on the same shell: with env_key present the request returns a normal completion, with the line deleted it 401s.

The inverse is also worth knowing, and it is good news: when env_key is present, it wins over auth.json. Tested with a deliberately bogus key stored in auth.json and a valid one in the environment variable, the request succeeded. You do not need to log out before configuring a custom provider.

Cause 6: The ChatGPT Login Path Expired

If you signed in with a ChatGPT subscription rather than an API key, the failure looks completely different:

ERROR: Your access token could not be refreshed. Please log out and sign in again.

Note the endpoint in the surrounding log lines: wss://chatgpt.com/backend-api/codex/responses, not api.openai.com. The two login modes talk to different backends, which is a fast way to tell which one you are actually on.

Codex 0.146.0 prints one of five variants here, and they are not interchangeable. From login/src/auth/manager.rs at tag rust-v0.146.0:

Variant	What it means in practice
`...because your refresh token has expired`	Genuine expiry. Sign in again.
`...because your refresh token was already used`	Two clients raced on the same auth.json. Copied config or a shared container image.
`...because your refresh token was revoked`	Session killed server-side, often by a password change or a sign-out elsewhere.
`...could not be refreshed.` (no reason)	Refresh endpoint returned something unclassified. Sign in again.
`...because you have since logged out or signed in to another account`	The stored account no longer matches the active one.

The "already used" variant is the one that surprises people. Refresh tokens are single-use, so baking an auth.json into a Docker image or syncing ~/.codex across two laptops gives you an auth setup that works on whichever machine refreshes first and breaks on the other. The same source file sets TOKEN_REFRESH_INTERVAL to 8 days, so a machine idle for more than a week will attempt a proactive refresh on its next run, which is usually when the conflict surfaces.

There is one fix and it is the blunt one:

codex logout
codex login          # browser flow
# or, for anything automated:
printenv OPENAI_API_KEY | codex login --with-api-key

For unattended environments, prefer the API key path. It has no refresh semantics to get out of sync.

Cause 7: codex login status Told You Everything Was Fine

It lies, in two different ways, and both were reproduced.

With a hand-built auth.json containing an expired ChatGPT token, every request failed with the refresh error above, while:

codex login status
# Logged in using ChatGPT

And under a custom provider, status reports the key sitting in auth.json, which is not the key being used for requests at all:

codex login status
# Logged in using an API key - sk-proj-***n-999

Both outputs describe the contents of a file. Neither performs a network check. Use them to answer "is a credential stored", never "does my auth work". For the latter, run the curl from the 30-second diagnosis, or just run codex exec "hi" and read the last line.

codex doctor is more useful here. Its Configuration section shows which config.toml was loaded and whether it parsed, the auth storage mode, and which auth environment variables it can see; its Connectivity section reports the active provider, wire API, whether WebSocket transport applies, and whether the endpoint is reachable. It still does not validate the credential, but it will tell you within a second if Codex is reading a different config file than the one you have been editing, which is a surprisingly frequent root cause when CODEX_HOME is set.

Cause 8: auth.json Is Corrupt (Not a 401)

Rarer, but it produces an error that looks nothing like an auth problem, which is exactly why it costs time. A truncated or hand-edited auth.json:

codex exec "hi"
# EOF while parsing a value at line 2 column 0

No mention of authentication, no HTTP status, no file path. This happens after an interrupted codex login, a partially synced file, or a hand edit that dropped a closing brace. The file is small enough to inspect directly:

python3 -m json.tool ~/.codex/auth.json > /dev/null && echo "valid JSON"

If it does not parse, delete it and log in again. There is nothing in it worth recovering; it is either an API key you can re-paste or OAuth tokens that will be reissued.

Cause 9: Codex Is Reading a Different Config Than the One You Edited

CODEX_HOME relocates both config.toml and auth.json. If it is set in your shell profile, in a wrapper script, or by a tool that launched Codex for you, every edit you make to ~/.codex/config.toml is going into a file Codex never opens. The symptom is a 401 that survives changes that should have fixed it.

codex doctor answers this in one line, under its state section:

CODEX_HOME  /private/tmp/codex401/home7 (dir)

and under Configuration:

config.toml  /private/tmp/codex401/home7/config.toml
config.toml parse  ok

If that path is not the file you have been editing, stop debugging the key.

The same command flags a second version of this problem. On a machine where Codex is installed both globally and locally, doctor prints:

✗ install   npm install -g @openai/codex would update a different install
✗ updates   update would target a different npm install

Read literally, that means the update command targets a different package root than the binary you are running, so an upgrade meant to pick up an auth fix can leave the running copy untouched. Worth resolving before you conclude that a version bump did not help.

One thing exit codes will not tell you

Every failure mode in this article exits 1. No credential, missing environment variable, config parse error, corrupt auth.json, rejected key: all 1. If you are wrapping Codex in a script and branching on the exit status, you cannot distinguish "your key is wrong" from "your config file has a typo". Capture stderr and match on the message text instead:

out=$(codex exec "ping" 2>&1) || {
  case "$out" in
    *"Missing environment variable"*) echo "config points at an unset variable" ;;
    *"Missing bearer"*)               echo "no credential was sent" ;;
    *"Incorrect API key"*|*"Invalid or expired API key"*) echo "credential rejected" ;;
    *"could not be refreshed"*)       echo "ChatGPT session expired, log in again" ;;
    *) echo "other failure: $out" ;;
  esac
}

Two Things That Look Like 401 and Are Not

A base_url missing its /v1 gives you a 404, not a 401:

ERROR: unexpected status 404 Not Found: 404 page not found,
url: https://api.ofox.ai/responses

If you see 404 page not found with a URL that is missing a path segment you expected, fix the URL and stop looking at credentials.

wire_api = "chat" fails before any request, at config load:

Error loading config.toml: `wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.
More info: https://github.com/openai/codex/discussions/7782

The chat value was removed; the enum has a single Responses variant left. Any gateway you point Codex at has to expose a Responses-compatible endpoint. This trips people migrating from older configs, and because it kills the process at startup it sometimes gets filed as "auth broke after upgrade". It did not.

A third near-miss: if you are behind a corporate proxy, the failure mode is usually a TLS or connect error rather than 401, and the fix is a different one entirely.

Fixes by Auth Mode

The same symptom needs a different fix depending on how you authenticate. This is the table to bookmark.

Auth mode	Where the credential lives	Most likely 401 cause	Fix
ChatGPT subscription	`auth.json` OAuth tokens	Refresh token expired or reused across machines	`codex logout` then `codex login`
OpenAI API key	`auth.json` `OPENAI_API_KEY` field	Key never written (old `--api-key` flag, or only exported to the env)	`printenv OPENAI_API_KEY \
Custom gateway provider	Environment variable named by {% raw %}`env_key`	Variable unset in the launching shell, newline in the value, or `env_key` line missing from the config	Export in the right shell, strip newlines, confirm the line exists
Automated or container	Environment variable, injected at runtime	Baked-in `auth.json` with single-use refresh tokens	Use the API key path, inject the key as an env var, never ship auth.json in an image

For container and CI setups specifically: mount nothing from ~/.codex, set the variable in the container environment, and use a custom provider block with env_key. That combination has no refresh state and no file to go stale.

Common Failure Patterns, With What Each One Actually Prints

Everything above, in one grid. Reproduced on Codex CLI 0.146.0 on 2026-07-30, macOS, against api.openai.com for default-provider rows and api.ofox.ai for custom-provider rows.

#	Setup	Result	Output
1	No credential anywhere	401	`Missing bearer or basic authentication in header`
2	`OPENAI_API_KEY` exported, default provider	401	`Missing bearer or basic authentication in header` (identical to #1)
3	Invalid key written via `--with-api-key`	401	`Incorrect API key provided: sk-proj-****7890`, `auth error code: invalid_api_key`
4	`codex login --api-key` (old flag)	exits	`The --api-key flag is no longer supported`
5	Custom provider, `env_key` variable unset	local error	`Missing environment variable: 'OFOX_API_KEY'`
6	Custom provider, `env_key` variable empty string	local error	identical to #5
7	Custom provider, invalid key	401	`Invalid or expired API key`
8	Custom provider, key wrapped in literal quotes	401	`Invalid or expired API key`
9	Custom provider, key with trailing space	200	request succeeds, the trailing space is tolerated downstream
10	Custom provider, key with trailing newline	401	`You didn't provide an API key...`
11	Custom provider, `env_key` line deleted from config	401	`Invalid or expired API key` (auth.json key sent instead)
12	Bogus key in auth.json, valid key in `env_key`	200	`env_key` takes precedence
13	ChatGPT auth.json, stale refresh token	refresh error	`Your access token could not be refreshed...`
14	`base_url` missing `/v1`	404	`404 page not found`
15	`wire_api = "chat"`	config error	`wire_api = "chat" is no longer supported`

Rows 9 and 12 are the two that save time by ruling things out. If you have been hunting for whitespace or assuming you need to log out before configuring a gateway, both of those are dead ends.

When You Cannot Fix the Credential: Alternatives That Work Now

If the auth path itself is the obstacle rather than a typo, you have a few options.

Option	What it solves	Trade-off
API key instead of ChatGPT login	Removes refresh tokens, browser flows, and the 8-day refresh window	Metered per token instead of covered by a subscription
A gateway provider with `env_key`	One key, one variable, works in containers and CI without a login step	Requires a Responses-compatible endpoint, so per-model support varies
A second provider block as a manual fallback	Lets you switch with `--config model_provider=...` when one credential dies	Manual, not automatic
A different agent	OpenCode reads provider credentials straight from environment variables with no login step	Different tool, different defaults

The gateway route is the one that removes the most moving parts for automated setups, because there is no login step to expire. Ofox works as one: it exposes /v1/responses, so the wire_api = "responses" requirement is satisfied, and a single OFOX_API_KEY reaches models from several vendors, which means a credential problem with one upstream does not leave you with nothing to run. Support is per model rather than per gateway, so check the model you want before committing. The setup block is the one shown in Cause 3.

How to Keep This From Recurring

A few habits that prevent most repeat incidents:

Verify with a real request, not a catalog call. Put this in your setup script rather than a /v1/models ping:

code=$(curl -s -o /dev/null -w "%{http_code}" -X POST https://api.ofox.ai/v1/responses \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-5.5","input":"ping","max_output_tokens":16}')
[ "$code" = "200" ] || echo "auth check failed: HTTP $code"

Guard against the newline at the point of export, not after the fact:

export OFOX_API_KEY="$(tr -d '\n\r' < ~/keys/ofox.txt)"

Never ship auth.json in an image or sync it between machines. Single-use refresh tokens make that a race by design. Inject a key through the environment instead.

Run codex doctor after any config change. It catches the wrong-CODEX_HOME and config-did-not-parse cases in about a second, which are the two failures most likely to make you doubt a perfectly good key.

Originally published on ofox.ai/blog.

OpenCode vs Codex CLI: Terminal AI Coding Agent Compared (2026)

Owen — Fri, 31 Jul 2026 11:36:06 +0000

OpenCode vs Codex CLI: Terminal AI Coding Agent Compared (2026)

OpenCode (190k stars, MIT, any model) vs Codex CLI (Rust, Apache-2.0, GPT-5-Codex). One is model-agnostic, one is OpenAI-native. Pick by your stack.

TL;DR: Which One Should You Pick?

Skip the essay if you already know your constraints. Here is the decision by scenario.

Scenario	Pick	Why
You run Claude, GPT, and open-weight models depending on the task	OpenCode	Model-agnostic by design, swap without restarting
You are all-in on OpenAI and want GPT-5-Codex tuned in	Codex CLI	First-party defaults, no gateway needed
You auto-approve shell commands and need real isolation	Codex CLI	OS-level sandbox is more hardened
You want a desktop app and IDE extension, not just a TUI	OpenCode	Ships TUI, desktop, and editor surfaces
You want one API key for every model	OpenCode	Codex needs the Responses API, which not every proxied model exposes
You care about avoiding single-vendor lock-in	OpenCode	Community-governed, MIT, no default vendor
You migrate from Claude Code and want an import path	Codex CLI	Built-in import of Claude Code and Cursor config

Both are free and open source. Both run in your terminal. The split is philosophy, not price.

The Five-Minute Comparison

The specs that change how each one feels day to day, verified against each project's repository and docs on 2026-07-29.

	OpenCode	Codex CLI
Maintainer	Anomaly (community, formerly sst)	OpenAI (first-party)
Repository	`anomalyco/opencode` (old `sst/opencode` links 301 here)	`openai/codex`
Language	TypeScript	Rust
License	MIT	Apache-2.0
Latest release	v1.18.9 (2026-07-28)	0.146.0 (2026-07-29)
GitHub stars	~190,800	~102,400
Install	`npm i -g opencode-ai`	`npm i -g @openai/codex`
Default model	None, you choose	OpenAI GPT-5-Codex family
Model support	Any of 75+ providers via models.dev	OpenAI, plus gateways that expose the Responses API
Config file	`~/.config/opencode/opencode.json`	`~/.codex/config.toml`
Project instructions	`AGENTS.md`	`AGENTS.md`
Surfaces	TUI, desktop app, IDE extension	TUI, non-interactive exec, mobile remote
Sandbox	Permission prompts	OS sandbox (seatbelt / Landlock) plus approvals

Two lines in that table carry most of the weight. "Default model: none" is the whole OpenCode thesis. "Default model: GPT-5-Codex" is the whole Codex thesis. Everything else follows from those two facts.

OpenCode: The Model-Agnostic Harness

OpenCode treats the model as a runtime argument, not a product decision. It ships with no default provider. On first run you connect one, and from there the model is a thing you pick per session, or per message, from a list of 75+ providers wired in through models.dev. Claude, GPT, Gemini, GLM, a local Ollama build, they are all just entries in /models.

That design has a few real consequences.

You are not tied to anyone's roadmap. When a new model lands and shows up in the models.dev registry, it shows up in OpenCode without a client update. The harness does not care who made the model, which is the point.

It is a full agent, not a thin wrapper. OpenCode runs a plan agent and a build agent, switchable with a keystroke. Plan mode is read-only and proposes an approach without touching files; build mode executes. It integrates Language Server Protocol servers, so for TypeScript, Python, Rust, Go, and a long tail of other languages, the model sees real type information and compiler diagnostics rather than guessing from raw text. It speaks MCP, supports custom tools, and runs multiple sessions in parallel on the same project.

It is not only a terminal tool. Alongside the TUI there is a desktop app and an IDE extension. If you want the agent loop but not the terminal, OpenCode has a surface for you. Codex leans harder into the terminal and the exec pipeline.

Where it bites: model-agnostic means you own the model decision, including the failure modes. Point OpenCode at a weak or misconfigured provider and you get weak or misconfigured output, and the harness will not save you from a bad routing choice. There is also a known rough edge in the provider registry. On a brand-new install, a freshly added provider can fail to appear on the very first invocation because the registry cache has not been written yet. Run the models command once to warm it, and it resolves. Worth knowing before you script a setup and assume the first call is authoritative.

OpenCode treats the model as a runtime argument, not a product decision. That single choice is why it wins the multi-model case and loses the "just works out of the box" one.

Codex CLI: OpenAI's First-Party Agent

Codex CLI comes from OpenAI, and it shows in every design decision. It is written in Rust, so it is a fast single binary rather than a Node process. It ships pointed at OpenAI's own endpoint and the Codex-tuned GPT-5 models, and for the default user that means zero configuration: install, authenticate with your ChatGPT account or an API key, and start coding.

The strengths cluster around trust and safety.

The sandbox is the best in this comparison. Codex isolates command execution with OS-level primitives, seatbelt on macOS, Landlock and seccomp on Linux, and puts approval modes on top. You choose how much rope the agent gets: suggest only, auto-edit within the workspace, or full auto inside the sandbox. An agent-run rm is confined by construction, not by the model choosing to behave. If you auto-approve tasks or run anything you did not write, that isolation is the feature you are actually buying.

It is a first-party citizen of the OpenAI stack. The /review command does inline code review without touching your working tree. Subagents parallelize work. Codex Remote lets you drive a connected Mac or Windows host from the ChatGPT mobile app. The /import command pulls Cursor and Claude Code settings, MCP servers, plugins, and commands into Codex, which makes migration a command rather than a weekend.

It is not locked to OpenAI, despite the defaults. Add a [model_providers.<id>] block to ~/.codex/config.toml pointing at a compatible gateway and Codex will call whatever that gateway serves. The door is there. You just have to open it by hand, which is the honest difference from OpenCode, where the door is open by default.

The catch is which protocol counts as compatible, and the answer changed. Codex used to accept wire_api = "chat", meaning any Chat Completions endpoint. That value is gone. In the 0.146.0 source the WireApi enum has exactly one variant left, Responses, and passing chat is not ignored, it is a hard startup error:

wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses" in your provider config.

That message links to discussion #7782, filed under the title "Deprecating chat/completions support in Codex," which is about as unambiguous as deprecations get. Chat Completions is the near-universal dialect. The Responses API is not. Every tutorial written before that change now produces a config that will not load, and every gateway that only proxies Chat Completions is now out of reach.

Where it bites: the OpenAI-first defaults are a comfort until you want to leave. Model freedom in Codex is a config task, not a menu, and the protocol boundary is real and has moved in OpenAI's favor. You cannot point base_url at Anthropic's native API and expect it to work, because that is not the Responses API. You route non-OpenAI models through a Responses-capable gateway or you do not route them at all, and as the next section shows, "Responses-capable" turns out to be a per-model property rather than a per-gateway one.

Head-to-Head: The Differences That Change Your Day

Six dimensions, and who takes each. "Winner" here means "better for most people optimizing for that axis," not a universal verdict.

Dimension	OpenCode	Codex CLI	Winner
Model freedom	Any provider, swap live	OpenAI default, others only if served over Responses	OpenCode
Sandbox and safety	Permission prompts	OS-level sandbox plus approvals	Codex CLI
Out-of-box setup	Choose a provider first	Install and go on OpenAI	Codex CLI
Surfaces	TUI, desktop, IDE	TUI, exec, mobile remote	Tie
Governance and lock-in	Community, MIT, no vendor	First-party OpenAI	OpenCode
Migration from Claude Code	Shared AGENTS.md convention	Built-in import command	Codex CLI

If you scan that column, the pattern is clear. OpenCode wins on freedom and independence. Codex wins on safety and on being turnkey inside one vendor. There is no dimension where one is strictly ahead on everything, which is exactly why the recommendation is conditional rather than a single name.

Setup and Daily Workflow, Measured

Forget invented quality scores. The honest, checkable differences are in how many steps each tool needs to do the same job, and where the friction sits.

Getting to a first response with a non-default model. In OpenCode, you export the provider's key, open the TUI, run /models, and pick. No file to edit. In Codex, a non-OpenAI model means writing a model_providers block in config.toml first, then checking that the model you want is actually served over the Responses API, then selecting it. OpenCode is fewer steps for the multi-model case by design; Codex is fewer steps if the model you want is OpenAI's, because then there are zero steps.

Switching models mid-task. OpenCode swaps live through /models inside a running session. Codex changes model with --model per invocation, or by loading a named profile, which is closer to picking a lane than nudging the wheel. If your workflow is "reason with the expensive model, then let a cheap one grind the edits," OpenCode makes that a two-second toggle.

Running a shell command. OpenCode asks for permission. Codex runs it inside the sandbox under whichever approval mode you set, so the isolation holds even when you say yes. Same prompt on the surface, very different blast radius underneath.

Project instructions. Both read AGENTS.md, the same convention Cursor and others adopted, so a repo that already has one works in either agent with no changes. This is the quiet win of the last year: your project's agent instructions are now portable across tools.

First Run, Side by Side

The fastest way to feel the difference is to install both and reach a first response. OpenCode, with a model you supply:

npm i -g opencode-ai
export OFOX_API_KEY=sk-your-key      # any OpenAI-compatible provider works
cd your-project
opencode                              # /models to pick, Tab to toggle plan/build

Codex, on OpenAI's defaults, which is the case it optimizes for:

npm i -g @openai/codex
cd your-project
codex                                 # authenticates with ChatGPT or OPENAI_API_KEY

Notice what each command assumes. OpenCode's happy path expects you to name a provider, and rewards you with a menu. Codex's happy path expects you to be an OpenAI user, and rewards you with zero setup. Neither is wrong. They are optimizing for different first users, and the install experience tells you which user each team pictured.

Extensibility: MCP, Skills, and Subagents

Past the model question, both agents are extensible in similar shapes, with different maturity in each corner. This is where "first-party" starts to show as polish rather than philosophy.

Capability	OpenCode	Codex CLI
MCP servers	Yes	Yes, namespaced registration
Reusable prompts	Custom tools and agents	Skills and slash commands
Subagents / parallelism	Parallel sessions	Subagents (multi-agent)
Read-only analysis	Plan agent, Tab to switch	`/review`, no working-tree edits
Remote / mobile	Desktop app, IDE, `/share`	Codex Remote from the ChatGPT app
Theming	Yes	Limited

Both speak MCP, so the same context servers and tool integrations plug into either one. Codex leans into a structured extension model, skills, namespaced MCP, and slash commands that feel governed by a team that ships a product. OpenCode leans into surfaces, giving you the same agent in a terminal, a desktop window, and your editor, plus a /share flow for handing a session to a teammate. The read-only story is a nice mirror of their philosophies: OpenCode gives you a dedicated plan agent you flip into, while Codex gives you a /review command that critiques without touching your tree. Same goal, two idioms.

One practical note on speed. Codex is a Rust binary, so it starts fast and stays light. OpenCode runs on Node, which is not slow in any way you will notice while a model is thinking, but it is a heavier process at rest. For most people the model's latency dwarfs the tool's, and this never matters. If you script a fleet of headless agents, it can.

One Key, Two Very Different Model Menus

Here is the part where the two philosophies stop being abstract, and where we stopped guessing and ran the thing. Both agents accept a gateway base URL, so one key can cover the billing for Claude, GPT, Gemini, and open-weight models. What one key does not guarantee is that both agents can reach all of them. We set both up against ofox.ai on 2026-07-29 and the results were not symmetric.

OpenCode: one environment variable, zero config file. Because ofox is a built-in provider in the models.dev registry, OpenCode discovers it the moment the key is present.

export OFOX_API_KEY=sk-your-key
opencode            # /models now lists ofox/... entries, pick one

That is the whole setup. No file, no provider block, and because OpenCode talks Chat Completions, everything the gateway serves is on the menu.

Codex CLI: one config block, and a shorter menu than you expect. Codex needs the gateway declared once in ~/.codex/config.toml.

model = "openai/gpt-5.5"
model_provider = "ofox"

[model_providers.ofox]
name = "ofox.ai"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"
requires_openai_auth = false

wire_api = "responses" is not a preference, it is the only value current Codex releases accept, so your gateway has to expose a Responses-compatible endpoint rather than just Chat Completions. requires_openai_auth = false is the default and keeps Codex from showing the ChatGPT login flow, so it reads the key from env_key instead. Full key list is in the Codex config reference.

What actually ran

We pointed Codex 0.146.0 at that config and asked each model to reply with one word, using codex exec --sandbox read-only. This is the result we did not expect going in.

Model	Codex CLI via gateway	What came back
`openai/gpt-5.5`	Works	Normal completion, 12.7k tokens billed for the turn
`anthropic/claude-sonnet-5`	Fails	`tools.0.custom.strict: Extra inputs are not permitted`
`deepseek/deepseek-v4-pro`	Fails	`Encrypted content is not supported with this model.`
`x-ai/grok-4.3`	Fails	Same encrypted-content error
`z-ai/glm-5.2`	Fails	HTTP 503, `No providers support endpoint 'responses'`

Note the asymmetry, because it is the most useful thing in this piece. GLM is the only one of the four the catalog flagged as unsupported ahead of time. Claude, DeepSeek, and Grok are all listed under /v1/responses and failed anyway. The endpoint list is a pre-filter, not a guarantee.

Three different failures, one theme. GLM never reaches the model at all because the gateway does not proxy it under /v1/responses. DeepSeek and Grok are reachable but reject the reasoning.encrypted_content field Codex attaches to every request, and that field is hard-coded in client.rs rather than exposed as a setting, so there is no config escape hatch. Claude is reachable and accepts encrypted content, but chokes on the shape of Codex's freeform apply_patch tool.

We then ran the identical prompt through OpenCode 1.18.9 on the same key, same gateway, same machine. All four of the models Codex could not reach answered normally, and so did a plain chat/completions call from the SDK. That is the tell: this is a protocol seam between Codex and the gateway layer, not a model problem and not a gateway being down.

How to check before you commit. The gateway's model list reports which endpoints each model is served under, so you can screen ahead of time instead of debugging a config:

curl -s https://api.ofox.ai/v1/models \
  -H "Authorization: Bearer $OFOX_API_KEY" \
| jq -r '.data[] | select(.supported_endpoints | index("/v1/responses")) | .id'

On 2026-07-29 that returned 67 model IDs. The catalog carries 123 entries, but 18 of those are image, video, embedding, and transcription models that expose neither text endpoint, so the denominator that matters is 105 text models: 102 served over chat completions, 67 over Responses. Those two sets overlap almost completely without nesting. 64 models offer both, and exactly three are Responses-only (openai/gpt-5.2-codex, openai/gpt-5.3-codex, openai/gpt-5.4-pro).

Counted by family, the Claude, GPT, DeepSeek, Doubao, and Grok text models were covered end to end. Qwen (10 of 21), MiniMax (7 of 9), and Kimi (2 of 5) were covered in part, so per-model checking matters even inside a family you assume is supported. Gemini and GLM had no Responses entry at any version, and neither did Kimi K3. Treat that list as the outer bound of what Codex could reach and then test the specific model, because as the table above shows, being listed is necessary and not sufficient.

None of this touches OpenCode, which is the practical argument for it if your model strategy is genuinely mixed. It is also worth saying plainly: this is a Codex-side protocol decision, it broke every Chat-Completions-only gateway at once, and it will presumably shake out as gateways build fuller Responses shims. It is a true thing about today, not a permanent verdict.

The same key works from code too, which is how you A/B two models on the same task without either agent in the loop. Same base URL, swap one string, no protocol seam to worry about.

Python: run the same task on two models

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-ofox-key",
    base_url="https://api.ofox.ai/v1",
)

task = "Refactor this function to remove the nested loop, keep behavior identical."

for model in ["anthropic/claude-sonnet-5", "z-ai/glm-5.2"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": task}],
    )
    print(f"\n=== {model} ===")
    print(resp.choices[0].message.content)

Node: same shape

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "sk-your-ofox-key",
  baseURL: "https://api.ofox.ai/v1",
});

const task = "Write a Postgres migration to add a nullable created_by column.";

for (const model of ["anthropic/claude-sonnet-5", "openai/gpt-5.5"]) {
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: task }],
  });
  console.log(`\n=== ${model} ===`);
  console.log(resp.choices[0].message.content);
}

The model IDs are literal. They are what you paste into OpenCode, and what you paste into Codex for whichever subset it can currently reach. That is the honest version of the portability pitch: the agent is the harness and the model is a variable, but only one of these two agents lets you change that variable freely today.

What that costs

Gateway pricing on the three models used above, read from the ofox model pages on 2026-07-29. These are per million tokens.

Model	ofox model ID	Input	Output
Claude Sonnet 5	`anthropic/claude-sonnet-5`	$2 / M	$10 / M
GLM-5.2	`z-ai/glm-5.2`	$1.4 / M	$4.4 / M
GPT-5.5	`openai/gpt-5.5`	$4 / M (list $5)	$24 / M (list $30)

GPT-5.5 was carrying a 20% promotional discount on the day we checked, so the $4 and $24 figures are the ones you would actually be billed and the struck-through $5 and $30 are the list prices. Promos expire; read the model page rather than trusting this table in six months. The other two had no discount applied.

The point of the table is not the absolute numbers, it is the spread. GLM-5.2 costs roughly a fifth of GPT-5.5 on output at promo pricing, so the "reason with the strong model, grind with the cheap one" workflow is a real bill difference, not a rounding error. OpenCode makes that toggle a keystroke. Codex, per the test above, could not reach two of these three models at all, which is the same finding arriving as a line on an invoice rather than an error string: the cost lever exists only for the agent that can pull it.

When to Pick OpenCode

Choose OpenCode if any of these describe you. You route work across multiple model vendors and want that to be a menu, not a migration. You are wary of tying your daily driver to a single company's pricing and roadmap. You want the agent outside the terminal too, in a desktop app or your editor. You value that the project is MIT-licensed and community-governed, with no default vendor collecting a toll. The model-agnostic design is the reason to be here, and if you would not use it, you are paying for flexibility you do not need.

When to Pick Codex CLI

Choose Codex CLI if you are already inside the OpenAI world and want the defaults to just work, if you auto-approve or batch-run tasks and need the OS-level sandbox that Codex has hardened more than anyone else in this category, or if you are migrating off Claude Code and want the import command to do the boring part. The Rust binary is fast, the safety story is the strongest here, and the first-party integration with the ChatGPT app and Codex Remote has no equivalent on the OpenCode side. If you rarely reach past OpenAI's own models, the config work that unlocks other providers is work you will never do, and that is fine. If you do expect to reach past them, read the protocol section above before you build a plan on it, because today that door opens onto a smaller room than the docs imply.

When Neither Is the Right Call (and What to Use Instead)

If you barely leave your editor, a terminal agent is a tax on your workflow, and a Cursor or a Zed with an inline assistant will fit your hands better. If your job is a fixed pipeline, generate this, review that, ship on a schedule, you do not want an interactive agent at all, you want a script calling a model API directly, which is why the code examples above call the gateway without either CLI in the loop. And if you are comparing four agents rather than two, our four-way terminal agent comparison covers Claude Code and DeepSeek TUI alongside Codex, with the price and daily-driver angles laid out.

The terminal agent is a specific tool for a specific taste: you want the model in your shell, watching your files, running your commands. If that is not the taste, neither of these is your answer, and reaching for the wrong shape of tool is a more common mistake than picking the wrong one of the two.

References

github.com/anomalyco/opencode (the former sst/opencode path 301s here)
github.com/openai/codex
codex-rs/model-provider-info/src/lib.rs at rust-v0.146.0
openai/codex discussion #7782
opencode.ai/docs
Codex CLI config reference
models.dev
ofox model pages

Originally published on ofox.ai/blog.

fal vs WaveSpeed vs AtlasCloud: Video Generation API Compared (2026)

Owen — Wed, 29 Jul 2026 11:36:20 +0000

fal, WaveSpeed and AtlasCloud run per-second video APIs but price differently: floors from $0.01/s, $0.045/s and $0.05/s. Match the model, then compare.

Which One Should You Pick?

There is no single winner here, and any comparison that crowns one is selling you something. fal, WaveSpeed, and AtlasCloud are all serverless generative-media APIs that bill per output. They differ on three axes that actually decide the call: how wide the model catalog is, how fast and reliable the inference is, and how the per-second price lands for the exact model you ship.

Your priority	Pick
Widest catalog + production track record	fal
Lowest latency, cheap fast variants, easiest free start	WaveSpeed
Lowest per-second video + one bill across LLM/image/video + compliance	AtlasCloud
Same models on one key without three separate accounts	An aggregator (see the last section)

If you already know your model and resolution, skip to the pricing section. If you are choosing a platform for a pipeline you have not built yet, read the positioning and billing sections first, because the billing model will surprise you more than the sticker price.

What Each One Actually Is

fal calls itself a generative-media platform for developers: one API in front of 1,000+ image, video, audio, and 3D models, plus serverless GPU deployment and dedicated compute for teams running their own weights. Its differentiator is not only breadth. fal leans on a proprietary inference stack it says is up to 10x faster on diffusion models, and it has the commercial track record to back a production bet: a $140M Series D led by Sequoia at a $4.5B valuation in December 2025, 1.5M+ developers, and named customers including Canva, Perplexity, and Poe (which fal says it powers for 40% of its image and video bots). It is SOC 2 compliant.

WaveSpeed is built around one word: speed. It bills itself as the fastest AI inference platform for images and video, and the headline product claims are sub-1-second average inference, zero cold starts, and a 99.99% uptime SLA. The company is younger and smaller, founded in 2024, based in Singapore, and angel-funded, with a founding team that comes out of open-source inference-optimization work. The catalog spans image, video, audio, 3D, and LLMs, though the exact model count is quoted inconsistently across its own pages (anywhere from 600+ to 1,000+), so treat any single figure loosely.

AtlasCloud is the broadest of the three by product surface. It is a multimodal aggregator, chat, image, video, audio, and 3D behind one API, and it also rents raw GPUs by the second (H100 at $2.95/GPU-hr, H200 at $3.50/GPU-hr). It advertises 400+ models and competes on price, with marketing that repeatedly claims industry-low rates. It is the only one of the three that lists both SOC 2 and HIPAA compliance, which matters if your video pipeline touches regulated data.

Head-to-Head Specs

Read this as positioning, not a benchmark. The counts and claims below come from each provider's own pages; the "Best for" column is a use-case tag, not a scored winner.

Dimension	fal	WaveSpeed	AtlasCloud	Best for
Positioning	Dev media platform	Fastest inference	Low-price multimodal + GPU	n/a
Catalog size (self-reported)	1,000+	600+ to 1,000+	400+	fal / breadth
Video billing unit	Per second or per video	Per image / second / token	Per second (video)	n/a
Also offers	GPU compute (hourly)	Serverless GPU	GPU rental (H100 $2.95/hr)	AtlasCloud / range
Speed claim (vendor)	Engine up to 10x faster	Sub-1s avg, zero cold start	0 to 800 GPUs, 90% cold-start cut	n/a
Free to start	Prepaid credits	$1 credit, no card	Trial credits	WaveSpeed / entry
Minimum top-up	Pay-as-you-go	Any amount	$25	fal / WaveSpeed
Compliance	SOC 2	99.99% uptime SLA	SOC 2 + HIPAA	AtlasCloud / regulated
Scale signal	Series D, 1.5M+ devs	Founded 2024, angel	Founded 2024	fal / maturity

How Each One Bills

The sticker price is the part people read. The billing unit is the part that changes the invoice. All three charge per output rather than per token-of-compute for their curated media models, but the unit shifts by modality and sometimes by model, and two of the three also expose raw GPU rental on a completely different meter.

Three video-API billing models compared

Same output, three billing mental models. Units change per model.

fal

Per output, or hourly GPU
Per second of video, or a flat rate per video
Wan 2.5: $0.05/s (480p)
Veo 3: $0.20/s (no audio), $0.40/s (audio)
Or rent compute: H100 $3.99/hr list
Not charged for 500 errors or queue wait
Read the model page for the unit

WaveSpeed

Per successful generation
Per image, per second, or per million tokens
Wan 2.2 Ultra Fast: $0.01/s
Veo 3.1 Fast: $0.15/s
$1 free credit on signup, no card
No subscription, no stated minimum
Tiers scale with cumulative top-up

AtlasCloud

Per modality + GPU rental
Video per second, LLM per million tokens
Seedance 2.0 Mini: $0.045/s
HappyHorse-1.1: $0.14/s
Rent GPUs: H100 $2.95/hr, H200 $3.50/hr
$25 minimum top-up, credits expire 365 days
One bill across LLM, image, video

fal states its dual model plainly: choose per-output pricing for serverless model calls, or hourly GPU pricing if you deploy your own model on Compute. WaveSpeed bills per successful generation and does not charge for failures. AtlasCloud splits by modality, per-second for video, per-million-tokens for LLMs, per-image for stills, and layers GPU rental on top for teams that want to run their own stack. The practical takeaway: two providers can quote the "same" model and still bill it in different units, so a headline rate is only comparable once you know what a unit buys.

Video Pricing: You Have to Match the Model

Here is the honest part most comparison posts skip. You cannot line up a single dollar-per-second number across these three and declare a winner, because the cheapest listing on each platform is a different model at a different fidelity, and sometimes a different mode (text-to-video versus image-to-video, standard versus a "fast" variant). The only fair comparison fixes the model, the resolution, and the mode first. Our deeper breakdown of that trap lives in the fal vs Replicate vs Ofox video pricing piece; the short version is below.

Start with each provider's cheapest verified per-second video floor. These are not the same model, which is the point.

Provider	Cheapest verified per-second video	Model	What you are actually buying
WaveSpeed	$0.01/s	Wan 2.2 Ultra Fast	A speed-optimized, lower-fidelity variant
AtlasCloud	$0.045/s	Seedance 2.0 Mini	Recently a 20% promo off $0.056
fal	$0.05/s	Wan 2.5 (480p)	Steps to $0.10/s (720p), $0.15/s (1080p)

Now a near-match, so you see how the gap moves when the model holds roughly still. On Wan 2.5, fal charges $0.05/s at 480p, $0.10/s at 720p, and $0.15/s at 1080p for text-to-video. WaveSpeed's Wan 2.5 image-to-video Fast variant is $0.068/s at 720p and $0.102/s at 1080p, lower than fal at those resolutions, but it is a different mode, so treat it as adjacent, not identical. AtlasCloud does not publish a Wan 2.5 per-second rate on its rate page as of this writing, so verify it on the model page before you budget around it.

At the premium end the ranking shifts again. fal cut its Veo 3 pricing to $0.20/s without audio and $0.40/s with audio (down from $0.50/$0.75 earlier in 2025), while WaveSpeed lists Veo 3.1 Fast at $0.15/s. Different Veo generations, so again, not a clean race, but it shows why "who is cheapest" has no stable answer across a whole catalog.

Why we do not crown a price winner

Because a second of a 480p fast variant is not a second of a 1080p flagship, and an image-to-video call is not a text-to-video call. On a single provider the same model steps up cleanly with resolution. Across providers you are comparing different models wearing the same family name. Fix the model, resolution, and mode, convert each to cost per identical clip, then compare. Anyone who hands you a single "$/s cheapest" verdict skipped that step.

Monthly Bill: What "Cheapest" Costs in Practice

Say you ship 2,000 clips a month at 5 seconds each. That is 10,000 output-seconds. At each provider's cheapest verified per-second video rate, the monthly bill looks like this, and the labels matter more than the bars.

Monthly bill: 10,000 output-seconds — 2,000 clips at 5s each, at each provider's cheapest verified rate

$100 — WaveSpeed Wan 2.2 Ultra Fast, $0.01/s
$450 — AtlasCloud Seedance 2.0 Mini, $0.045/s
$500 — fal Wan 2.5 480p, $0.05/s

Different models at different fidelities. Read the labels, not just the bars.

The $100 bar is real, and it is also a trap if you read it as "WaveSpeed is 5x cheaper." Wan 2.2 Ultra Fast is a speed variant, not a flagship, so you are buying lower fidelity for that rate. Move everyone up to a 720p working tier and the picture flattens: fal's Wan 2.5 at 720p is $1,000/month for the same 10,000 seconds, WaveSpeed's Wan 2.5 Fast at 720p is about $680, and AtlasCloud's HappyHorse-1.1 lip-sync model at $0.14/s would run $1,400. The cheapest floor and the cheapest thing-you-actually-ship are rarely the same line.

Image and LLM Pricing

Video is the headline, but all three also generate images, and AtlasCloud reaches further into language models, so if your pipeline mixes modalities the non-video rates matter too. The same rule applies: these are list rates pulled from each provider's pricing pages in July 2026, and the cheapest listing is usually a lower-fidelity variant. Confirm on the model page before you budget.

Provider	Image example (list)	Also meters
fal	Flux dev $0.025/img, Seedream V4 $0.03/img	Per megapixel on some models (Qwen $0.02/MP)
WaveSpeed	Flux 2 Klein $0.008/img, Nano Banana 2 $0.07/img	Per second (video), per million tokens (LLM)
AtlasCloud	Flux Schnell from $0.003/img	LLM tokens: Grok 4.5 $2/$6, Kimi K3 $3/$15 per 1M

The structural difference worth calling out: AtlasCloud is the only one of the three that also meters LLM tokens the way an OpenAI-style API does, which is why it pitches a single bill across chat, image, and video rather than a media-only shop. fal and WaveSpeed keep their center of gravity on generative media. If your product needs both a language model and a video model behind one invoice, that narrows the field before you even look at video rates.

Renting Raw GPUs

Two of the three will also rent you the metal. This matters if you plan to deploy your own weights or run a model that is not in the catalog, and it is a different meter from the per-output pricing above: you pay for GPU time whether a job renders in one second or ten.

GPU	fal (list / as low as)	AtlasCloud
H100 (80GB)	$3.99/hr / $1.89/hr	$2.95/GPU-hr
H200 (141GB)	$4.50/hr / $2.10/hr	$3.50/GPU-hr

fal's Compute product bills per second with a list-versus-committed spread, so the effective rate depends on how much you commit up front. AtlasCloud's on-demand rate is flat per GPU-hour with per-second billing and no minimum, and it advertises scaling from zero to hundreds of GPUs for burst work. WaveSpeed also offers serverless GPU billed per compute-second, though it does not publish a clean rate card, so price it in the dashboard rather than trusting a summary. If you never plan to leave the curated model APIs, skip this section; it only matters once you outgrow the catalog.

Speed and Reliability

Two of these three sell speed as the headline, so weigh the claims for what they are: vendor numbers, not independent benchmarks.

fal points to its Inference Engine, which it measures as up to 10x faster on diffusion models, and to production scale: 100M+ daily inference calls, billions of requests a day, 99.99%+ uptime by its own reporting. The scale is the more useful signal, because it is a track record rather than a lab number.
WaveSpeed advertises sub-1-second average inference and zero cold starts, plus a 99.99% uptime SLA. A press claim of "up to 6x faster" exists, but it comes from a B200-versus-H100 framing in a funding announcement, not a product-page benchmark.
AtlasCloud talks scale-out rather than raw latency: scaling from 0 to 800 GPUs in seconds and a 90% cold-start reduction on its serverless tier.

None of these is third-party verified. If latency is your deciding factor, run your own model in your own region against each and measure the p50 and p95 yourself. A homepage number tells you what a provider optimized for, not what your workload will see.

Accounts, Credits, and the Fine Print

The onboarding terms decide how painful a proof-of-concept is, and they vary more than the prices.

	fal	WaveSpeed	AtlasCloud
Sign-in	GitHub, Google, SSO	Google, GitHub	Email / account
Free to start	Prepaid credits (promo terms unconfirmed)	$1 credit, no card required	Trial credits
Minimum top-up	Pay-as-you-go	Any amount (moves you off Bronze)	$25
Credit expiry	Not stated	Not stated	365 days
Account model	Personal, Team, Org	Bronze to Ultra by top-up	Pay-as-you-go
Not charged for	500 errors, queue wait	Failed generations	n/a
Compliance	SOC 2	99.99% uptime SLA	SOC 2 + HIPAA

WaveSpeed is the lowest-friction start: sign in with Google, take the $1 credit, no card. One catch worth knowing is that a key created before your first top-up will not activate, so add any amount before you expect calls to work. AtlasCloud asks for a $25 minimum and expires credits after a year, but gives you compliance certs and GPU rental in the same account. fal is pay-as-you-go on prepaid credits, and its concurrency limit scales with how much you have purchased, which is worth knowing if you plan to burst.

Each of these is a separate account, a separate API key, and a separate prepaid balance with its own request schema. That is fine for one provider. It gets tedious the moment you want to A/B the same model across two of them.

Where a Multi-Model Aggregator Fits

If you find yourself running the same underlying models (Seedance, Wan) across more than one of these providers, you are also maintaining more than one integration, one per vendor schema, one per prepaid balance. An aggregator collapses that. Ofox, for instance, fronts the same models behind one OpenAI-style endpoint, so bytedance/seedance-2.0 and alibaba/wan-2.7 are a one-string swap on a single key, billed per output second by resolution (Seedance 2.0 at $0.07/s for 480p up to $0.34/s at 1080p, Wan 2.7 at $0.10/s for 720p). It is not a replacement for going direct when you have settled on one model and one provider, but it removes the three-accounts tax while you are still comparing.

import requests

# One key, one endpoint, swap the model string to A/B the same clip
resp = requests.post(
    "https://api.ofox.ai/v1/videos",
    headers={"Authorization": "Bearer $OFOX_API_KEY"},
    json={
        "model": "bytedance/seedance-2.0",   # or "alibaba/wan-2.7"
        "prompt": "a paper boat drifting down a rain gutter, cinematic",
        "resolution": "1080p",
        "duration": 5,
    },
)
job = resp.json()   # 202 + polling_url; poll GET /v1/videos/{id} until completed

When to Pick Each

When to Pick fal

Pick fal when you want the widest catalog, a proprietary speed engine, and a provider with a production track record you can point a stakeholder at. The Series D scale, the 1.5M+ developers, and customers like Canva and Perplexity are the reason fal is the low-risk default for a pipeline you are betting a product on. You pay for that maturity in per-second rates that are rarely the cheapest.

When to Pick WaveSpeed

Pick WaveSpeed when latency is the product and you want the cheapest possible start. The $1 free credit with no card is the easiest proof-of-concept of the three, the fast model variants are genuinely low-cost, and the whole platform is tuned for speed. Weigh the vendor speed claims against your own measurement, and accept that a younger, angel-funded company is a slightly higher operational bet than fal.

When to Pick AtlasCloud

Pick AtlasCloud when you want the lowest per-second video and a single bill across LLMs, images, and video, ideally with compliance attached. The SOC 2 plus HIPAA posture and the built-in GPU rental make it the pick for a team that wants media generation and model hosting under one roof. The $25 minimum and 365-day credit expiry are the trade for that breadth.

When None of the Three Fits

If you have settled on exactly one model at scale, price it directly against the model maker's own API and whichever host is cheapest for that specific model, resolution, and mode, and ignore the catalog breadth you will not use. And if the friction you actually feel is maintaining several accounts to compare the same models, that is the aggregator case above, not a fourth provider to sign up for.

Sources Checked for This Refresh

WaveSpeed pricing page: https://wavespeed.ai/pricing
WaveSpeed Wan 2.5 image-to-video Fast model page: https://wavespeed.ai/models/alibaba/wan-2.5/image-to-video-fast
WaveSpeed platform overview: https://wavespeed.ai/landing/introduce
AtlasCloud video model pricing: https://www.atlascloud.ai/pricing/models
AtlasCloud GPU pricing: https://www.atlascloud.ai/pricing/gpu
AtlasCloud LLM pricing: https://www.atlascloud.ai/models/llm
AtlasCloud about / compliance: https://www.atlascloud.ai/about
fal pricing page: https://fal.ai/pricing
fal Wan 2.5 model page: https://fal.ai/models/fal-ai/wan-25-preview/text-to-video
fal Veo 3 model page: https://fal.ai/models/fal-ai/veo3
fal model-API pricing docs: https://fal.ai/docs/documentation/model-apis/pricing
TechCrunch: fal's $140M Series D at a $4.5B valuation
ByteDance Seed: the Seedance model
Wan project site
Ofox Seedance 2.0 model page
Ofox Wan 2.7 model page
Ofox video models and pricing

How to Choose a Video Generation API by Use Case (2026)

Owen — Wed, 29 Jul 2026 04:33:41 +0000

The hard part of video generation is not the API call, it is picking the model. "Best" depends entirely on the job. A character who has to stay recognizable across three cuts, a spokesperson who lip-syncs to a voiceover, and a throwaway draft you will regenerate ten times each point to a different model. ofox puts three model families behind one POST /v1/videos endpoint and one key: Seedance 2.0, Wan, and HappyHorse. Because they share the endpoint, choosing between them is a model string change, not a new integration. This guide maps the common use cases to the right model, with the real per-second pricing for each.

Model	Best for	Price per output second	Max res	Clip length
`bytedance/seedance-2.0`	Multi-shot consistency, cinematic, up to 4K	$0.07 (480p) to $0.34 (1080p) to $1.37 (4K)	4K	4 to 15s
`bytedance/seedance-2.0-mini`	Cheap drafts at volume, capped at 720p	$0.04 (480p) / $0.08 (720p)	720p	4 to 15s
`alibaba/wan-2.7`	Budget quality, short loops, open-weights lineage	$0.10 (720p) / $0.15 (1080p)	1080p	2 to 15s
`alibaba/happyhorse-1.1`	Audio-driven avatars and lip-sync	$0.13 (720p) / $0.17 (1080p)	1080p	3 to 15s

Pick by use case, not by a leaderboard. Consistent characters across cuts point to Seedance 2.0. A talking head that lip-syncs to your audio points to HappyHorse. A 2-second loop or the lowest 1080p bill points to Wan. Cheap throwaway drafts point to Seedance Mini. All four are one model string on the same /v1/videos key.

Consistent characters and multi-shot scenes: Seedance 2.0

Seedance 2.0's signature is native multi-shot generation with subject consistency. The same character, product, or set holds its look across separate cuts inside one job, which is exactly the thing that breaks when you stitch clips from a model that redraws the subject every render. It reaches 4K, runs 4 to 15 seconds, and does text-to-video, image-to-video, and video-to-video.

Cost scales with resolution: $0.07/s at 480p, $0.16/s at 720p, $0.34/s at 1080p, and $1.37/s at 4K for text-to-video. Video-to-video is a higher tier on the same model ($0.09/s at 480p, $0.20/s at 720p, $0.45/s at 1080p, $1.70/s at 4K), so budget for the mode you actually run, not just the resolution. If your deliverable is a short branded sequence where one hero has to survive several shots, this is the model to reach for. If you are only choosing between its own Mini, Fast, and flagship tiers, the Seedance 2.0 tier comparison covers that split in detail.

Talking heads and avatars: HappyHorse 1.1

When the deliverable is a person speaking, an avatar, a spokesperson, or a lip-synced explainer, HappyHorse is the model built for it. It is the audio-driven avatar and lip-sync specialist: give it a reference image and an audio track and it returns a clip whose mouth matches the sound. It also handles multi-image reference, runs 3 to 15 seconds, and reaches 1080p.

Pricing is $0.13/s at 720p and $0.17/s at 1080p. Seedance and Wan both generate audio, so they are fine for scenes where sound is ambient, but neither is a lip-sync engine. If a face has to say specific words on cue, HappyHorse is the one that is designed for it rather than approximating it.

Budget, short loops, and open-weights lineage: Wan 2.7

Wan is the value pick. It is $0.10/s at 720p and $0.15/s at 1080p, flat by resolution with no premium tiers to reason about, and it supports text-to-video, image-to-video, and video-to-video up to 1080p. Two things it wins outright among the three families. First, it accepts a 2-second minimum clip where every Seedance tier floors at 4 seconds, so 2 to 3 second loops and stingers are only possible here. Second, its open-weights lineage makes it the natural choice if you want the option of parity between a hosted API and a model you can inspect. The Seedance 2.0 vs Wan comparison walks the full head-to-head.

Cheap drafts at volume: Seedance Mini

When you will regenerate a shot ten times before you like it, do not pay flagship rates to iterate. Render drafts on bytedance/seedance-2.0-mini at $0.04/s for 480p and $0.08/s for 720p, the lowest 720p rate on the platform, then promote the winning prompt to the flagship for the final master. Because the tiers share the endpoint and differ only by the model string, the promotion is a one-line change, not a rewrite.

The pricing reality: per second, by resolution

Every model here bills per output second, and the rate rises with the resolution you request. The "from" figure next to each model in the catalog is the resolution floor, not a flat rate, which is the single most common budgeting mistake. Match the model to the job first, then match the resolution to where the clip actually lands.

Here is the same 8-second clip across the three families at 1080p:

Model	1080p rate	8-second clip
`alibaba/wan-2.7`	$0.15/s	$1.20
`alibaba/happyhorse-1.1`	$0.17/s	$1.36
`bytedance/seedance-2.0`	$0.34/s	$2.72

Those rates are text-to-video. Seedance also runs video-to-video at a higher tier, where 1080p is $0.45/s and the same 8-second clip is $3.60 rather than $2.72, so price the mode, not just the resolution. Seedance costs more per second at 1080p because it is the only one of the three that also reaches 4K, and its multi-shot consistency is doing more work per frame. For a feed that downscales to 720p anyway, the gap narrows, and Seedance Mini at $0.08/s undercuts everything.

Where Sora, Veo, Kling, and Hailuo fit

Plenty of strong video models sit outside these three families. Sora, Veo, Kling, and Hailuo are all capable, and for some shots they are the right answer. On ofox they are listed as coming next rather than live, so for now each still runs on its own native API with its own SDK, auth, and billing. The point of a single endpoint is what happens when they land: adding one becomes a one-line model string on the same /v1/videos key, not a fresh integration to build and maintain. If your pipeline needs one of them today, the Sora vs Veo vs Kling comparison covers running them as separate integrations in the meantime. This guide is about the three families you can drive through a single ofox key right now.

One key, every model

The reason choosing is cheap is that switching is cheap. Every model here uses the same request: POST /v1/videos with a model ID and a prompt, poll the job, then read the clip from unsigned_urls[0]. The Seedance 2.0 API access guide walks that full request and response cycle, and it is identical across all three families.

Try all three on the key you already have. Start on the ofox video API: one key, USD billing, pay only for the seconds you render, and swap Seedance, Wan, or HappyHorse with a single string.

FAQ

Which video model should I use for a talking-head avatar? HappyHorse 1.1. It is the audio-driven avatar and lip-sync specialist: feed it an image and an audio track for a synced talking clip, up to 1080p, at $0.13/s (720p) or $0.17/s (1080p).

What is the cheapest way to generate video on ofox? bytedance/seedance-2.0-mini at $0.04/s (480p) and $0.08/s (720p). Use it for drafts, then re-render the winner on the flagship.

Which model can make a 2-second clip? Wan, which accepts a 2-second minimum. Seedance tiers floor at 4 seconds; HappyHorse starts at 3.

Do these models all cost the same? No. Per output second by resolution: Wan $0.10 to $0.15, HappyHorse $0.13 to $0.17, Seedance $0.07 to $1.37 across 480p to 4K.

Can I use one API key for all of them? Yes. All three sit behind POST /v1/videos on one ofox Bearer key. Switching is a model string change.

Sources Checked for This Guide

Originally published on ofox.ai/blog.

How to Access the Seedance 2.0 Video Generation API (2026)

Owen — Wed, 29 Jul 2026 00:33:25 +0000

How to Access the Seedance 2.0 Video Generation API (2026)

Seedance 2.0 is ByteDance's text-to-video and image-to-video model, and the fastest way to call it is through ofox: one API key, USD billing, and a single async REST endpoint. You POST https://api.ofox.ai/v1/videos with a model ID and a prompt, get back a polling_url, poll until the status is completed, then read the clip from unsigned_urls[0]. No per-vendor account, no separate SDK. The rest of this guide is the working quickstart: auth, a text-to-video call in Python and Node, the async lifecycle, image and reference inputs, and what a clip actually costs.

Endpoint

POST https://api.ofox.ai/v1/videos (async)

Auth

one ofox Bearer key

Model IDs

bytedance/seedance-2.0, -fast, -mini

Time to first clip

about 5 minutes

Get the result

poll GET /v1/videos/{id}, read unsigned_urls[0]

What You Need

Three things, and you already have two of them if you use ofox for chat or image calls.

An ofox API key. The base URL is https://api.ofox.ai/v1 and auth is a standard Authorization: Bearer header. The same key you use for OpenAI-compatible chat and image requests also submits video jobs, so there is no separate account or vendor SDK to set up.
The endpoint. Everything runs through POST /v1/videos and GET /v1/videos/{id}. That is the whole surface.
A model ID. bytedance/seedance-2.0 is the flagship: text-to-video, image-to-video, video-to-video, synced audio, clips from 4 to 15 seconds, up to 4K. bytedance/seedance-2.0-fast and bytedance/seedance-2.0-mini are the cheaper tiers and both cap at 720p.

Set the key once:

export OFOX_API_KEY="sk-..."

Your First Request: Text-to-Video

Video generation is not a blocking call the way a chat completion is. The clip takes render time, so POST /v1/videos returns 202 Accepted right away with a polling_url, and you poll that URL until the job reaches a terminal state. The mode is inferred from the fields you send: no image field means text-to-video.

Here is a complete round trip in Python. It submits the job, polls at a sane cadence, and pulls the clip from unsigned_urls[0].

import os, time, requests

BASE = "https://api.ofox.ai/v1"
HEAD = {"Authorization": f"Bearer {os.environ['OFOX_API_KEY']}"}
TERMINAL = {"completed", "failed", "cancelled", "expired"}

job = requests.post(f"{BASE}/videos", headers=HEAD, json={
    "model": "bytedance/seedance-2.0",
    "prompt": "A red kayak cuts through morning fog on a still lake, slow dolly forward.",
    "duration": 8,
    "resolution": "1080p",
    "aspect_ratio": "16:9",
})
job.raise_for_status()                     # 202 Accepted
task_url = job.json()["polling_url"]

while True:
    task = requests.get(task_url, headers=HEAD).json()
    if task["status"] in TERMINAL:         # break on ALL four terminal states
        break
    time.sleep(2)                          # poll every 1-2s, not in a tight loop

if task["status"] == "completed":
    print("clip:", task["unsigned_urls"][0])   # there is no output_url field
    print("billed:", task["usage"]["video_cost"], "USD",
          "for", task["usage"]["video_seconds"], "s")
else:
    print("job ended as:", task["status"])

The same shape in Node with fetch:

const BASE = "https://api.ofox.ai/v1";
const HEAD = {
  Authorization: `Bearer ${process.env.OFOX_API_KEY}`,
  "Content-Type": "application/json",
};
const TERMINAL = ["completed", "failed", "cancelled", "expired"];

const job = await fetch(`${BASE}/videos`, {
  method: "POST",
  headers: HEAD,
  body: JSON.stringify({
    model: "bytedance/seedance-2.0",
    prompt: "A red kayak cuts through morning fog on a still lake, slow dolly forward.",
    duration: 8,
    resolution: "1080p",
    aspect_ratio: "16:9",
  }),
});
const { polling_url } = await job.json();          // 202 Accepted

let task;
do {
  await new Promise((r) => setTimeout(r, 2000));   // poll every 1-2s
  task = await (await fetch(polling_url, { headers: HEAD })).json();
} while (!TERMINAL.includes(task.status));

if (task.status === "completed") {
  console.log("clip:", task.unsigned_urls[0]);     // not output_url
  console.log("billed:", task.usage.video_cost, "USD");
}

Two things trip up first-time callers. The first is reaching for resp["output_url"], which does not exist and returns None in Python or undefined in Node. The clip lives in unsigned_urls[0]. The second is a poll loop that only checks for completed. A job that ends in failed or expired never sets completed, so a loop that ignores the other terminal states spins forever. Break on all four.

Handling the Async Lifecycle

A Seedance job moves through a fixed set of states. Three are transient and four are terminal. There is no processing state, so do not check for one.

Status	Phase	What to do
`pending`	Accepted, not yet queued	Keep polling every 1-2s
`queued`	Queued for render	Keep polling every 1-2s
`in_progress`	Rendering	Keep polling every 1-2s
`completed`	Done, URLs attached	Download from `unsigned_urls[0]`
`failed`	Generation error	Read the error, retry or fall back
`cancelled`	You cancelled it	Stop polling
`expired`	Task aged out	Resubmit

Poll cadence matters. GET /v1/videos/{id} no faster than once per second; roughly every one to two seconds is the sweet spot. Hammering it in a tight loop wastes quota and gets you nothing sooner, since the clip is rendering upstream regardless.

The result URLs have a shelf life, so treat completed as your cue to download. unsigned_urls expire about 24 hours after the job finishes. mirror_urls are persistent, but each signed link still carries its own TTL. In practice: when the status flips to completed, pull unsigned_urls[0] into your own bucket (S3, R2, GCS) immediately rather than storing the API URL and serving it to clients later.

For production you usually want a webhook instead of a polling thread. Pass a callback_url at creation and ofox posts an HMAC-signed payload when the job reaches a terminal state. The address must be public HTTPS; a private, loopback, or otherwise unreachable host is rejected at submit time with a 400 invalid_callback_url. Polling and webhooks are not mutually exclusive, so a common pattern is a webhook for the happy path plus a slow poll as a backstop.

Need to stop a job early? DELETE /v1/videos/{id} cancels it, and the task settles into cancelled.

Image-to-Video and Reference Images

You do not switch endpoints to animate a still or steer generation with reference frames. Same POST /v1/videos, same polling. The request mode is inferred from which fields you include.

No image field gives text-to-video, the call above.
frame_images gives image-to-video. Pass one URL for a single starting frame, or a first and last frame for interpolation between them.
input_references gives reference-guided generation, where you supply images that anchor identity, style, or a product's look.

Image-to-video from a starting frame:

job = requests.post(f"{BASE}/videos", headers=HEAD, json={
    "model": "bytedance/seedance-2.0",
    "prompt": "The logo tilts up and catches a rim light, subtle rotation.",
    "frame_images": ["https://your-cdn.com/first-frame.png"],
    "duration": 8,
    "resolution": "1080p",
    "aspect_ratio": "16:9",
})

Everything downstream is identical: 202, a polling_url, the same status set, and the clip in unsigned_urls[0]. Audio is generated across all three tiers, so name the sound you want in the prompt or you inherit whatever the model infers.

Pricing: Per Resolution, Not Flat

This is the number people get wrong. The from $0.07/s next to Seedance 2.0 on the catalog is a 480p floor, not a flat rate. Price scales with the resolution you request, so the real cost of a clip is the per-second rate at your resolution times the clip length. Here is the flagship text-to-video rate card:

Resolution	`bytedance/seedance-2.0` (text-to-video)
480p	$0.07/s
720p	$0.16/s
1080p	$0.34/s
4K	$1.37/s

Billing is per output second, and the completed response tells you the exact charge in usage.video_cost. So an 8-second 1080p clip is 8 x $0.34 = $2.72, and the same clip at 4K is 8 x $1.37 = $10.96. Video-to-video runs a little higher per second than text-to-video at each resolution, which the model page spells out in full.

The cheaper tiers trade resolution for cost and both cap at 720p: bytedance/seedance-2.0-fast is $0.06/s at 480p and $0.13/s at 720p, while bytedance/seedance-2.0-mini is $0.04/s at 480p and $0.08/s at 720p. If most of your output lands on a feed that downscales to 720p anyway, Mini at $0.08/s is the lowest 720p rate of the three.

Because all three tiers share the same endpoint and differ only by the model string, you can route drafts to Mini and reserve the flagship for masters. For the full head-to-head, including when Fast is worth its premium over Mini, read the Seedance 2.0 tier comparison and the Seedance 2.0 model page for the complete per-resolution matrix.

One Key, Every Video Model

The reason this quickstart is short is that ofox collapses the whole video stack into one auth and one schema. You already have the pattern: submit to /v1/videos, poll, download. Swapping models is a string change.

Generate on Seedance 2.0 with the key you already have. Start on the ofox video API: one key, USD billing, pay only for the seconds you render, no per-vendor signup.

If Seedance is not the right fit for a given clip, the same endpoint reaches the rest of the catalog. Alibaba's Wan starts at a 2-second minimum where Seedance floors at 4 seconds; the Seedance 2.0 vs Wan comparison covers that trade. The exact request and response fields, including every optional parameter, live in the ofox video API reference.

FAQ

How do I call the Seedance 2.0 API? Send POST https://api.ofox.ai/v1/videos with a Bearer ofox key and a JSON body of model, prompt, duration, resolution, and aspect_ratio. It returns 202 with a polling_url. Poll GET /v1/videos/{id} every 1-2 seconds until status is completed, then read the clip from unsigned_urls[0].

Why is the video URL empty when I read output_url? There is no output_url field. The clip is in unsigned_urls (an array, so use unsigned_urls[0]) or in mirror_urls. Reading resp["output_url"] returns None every time.

How long do Seedance 2.0 result URLs stay valid? unsigned_urls expire about 24 hours after completion. mirror_urls are persistent, but each signed link carries its own TTL. Download the file as soon as the status is completed.

How much does the Seedance 2.0 API cost? Per output second by resolution, not a flat rate. Flagship text-to-video is $0.07/s at 480p, $0.16/s at 720p, $0.34/s at 1080p, and $1.37/s at 4K. An 8-second 1080p clip is $2.72.

Can Seedance 2.0 generate video from an image? Yes. Pass frame_images for image-to-video or input_references for reference-guided generation. The mode is inferred from the fields; no image means text-to-video.

What is the cheapest Seedance 2.0 model? bytedance/seedance-2.0-mini, at $0.04/s for 480p and $0.08/s for 720p. It caps at 720p, as does -fast. Only the flagship reaches 1080p and 4K.

Sources Checked for This Refresh

Originally published on ofox.ai/blog.

GLM-5.2 in Cline: Setup, Thinking, Cost vs Sonnet 5 (2026)

Owen — Tue, 28 Jul 2026 14:39:38 +0000

Cline bills by the token, and it is not shy about spending them. Every turn it resends your file tree, the open buffers, and the running task log, so the model you pick shows up on the invoice within a day. GLM-5.2 is the model a lot of teams reach for to make that loop cheaper without dropping to something that can’t hold a refactor together. This guide wires it into Cline in about five minutes.

Two things trip people up, and neither is the part people worry about. The first is that GLM-5.2 is not a Claude model, so it does not go in the slot most Cline guides point you at. The second is the thinking toggle, which does not behave the way the Sonnet 5 one does. Both are below, along with the cost comparison that decides whether GLM-5.2 is actually the right call over Claude Sonnet 5.

What You Can Do After This Setup (And What You Can’t)

After this you will have GLM-5.2 driving Cline as an agent: reading files, proposing diffs, running commands, across a full 1M-token context. Here is the honest scope before you spend the five minutes.

Question	Answer
Can GLM-5.2 act as a full Cline agent?	Yes, through the OpenAI Compatible provider it gets tool use.
Does it use the Anthropic provider slot?	No. That slot is for Claude. GLM goes through OpenAI Compatible.
Can I control reasoning depth?	Partly. Cline sends a reasoning-effort hint; you can’t turn GLM’s thinking off.
Does the full 1M context work?	Yes, if you set the context window to 1000000 in Cline.
Is it cheaper than Claude Sonnet 5?	On raw rates yes, about 1.6-1.9x. Caching narrows it.
Will tool use be as clean as Claude’s?	Not always. GLM has documented tool-call parsing quirks in Cline.

Decision Frame: When to Run GLM-5.2 in Cline (and When Not)

GLM-5.2 is a genuine value play for coding, not a downgrade. But it is not the automatic pick, and choosing it in the wrong situation costs you either money or a morning of debugging tool calls.

When to use GLM-5.2

Your Cline sessions are long and file-heavy, so token volume, not peak reasoning, sets the bill, and a lower output rate compounds fast.
You want a coding-first model with a real 1M window for large-repo work.
You already route mixed models through one OpenAI-compatible endpoint and want to add a cheap default without a second integration.

When NOT to use it

You are a Claude shop and value native tool use, cache controls, and the effort dial. Sonnet 5 on Cline’s Anthropic provider keeps all three, and the ~1.6x price gap may not pay for the rougher integration.
The task is a gnarly cross-file refactor or a subtle concurrency bug where a stronger model finishes in one pass instead of three. Save the escalation for those and let GLM handle the other 80%.
You need a hard off-switch for reasoning on trivial turns. GLM keeps thinking on by default from Cline, which you cannot change from the UI (covered below).

The stop rule

If your goal is just to point Cline at a cheap coding model, do Steps 1 through 5, set the context window, and stop. The thinking and cost sections are for people tuning spend against quality, not for the basic connect.

System Requirements

VS Code with the Cline extension installed from the marketplace, on a current release. GLM tool-call handling has improved across recent versions, so an old build is a common source of trouble.
An API key for a backend that serves GLM-5.2. This guide uses ofox, an OpenAI-compatible gateway, so one key also reaches Claude, GPT, and the rest when you want to escalate a hard turn.
Network reach to your endpoint. Behind a corporate TLS proxy, fix the certificate first; the same Node rules from our Claude Code SSL certificate error guide apply to Cline.

Step-by-Step: GLM-5.2 in Cline

The whole setup is five fields and a test message. The one decision that matters is Step 1, and it is the opposite of the Claude answer.

Step 1: Pick the provider slot (not the Claude one)

Cline offers two ways in. Most guides tell you to use the Anthropic provider, because most guides are about Claude. GLM-5.2 is not Claude, so that slot is wrong here.

Provider slot	Base URL	Use it for
OpenAI Compatible	`https://api.ofox.ai/v1`	GLM-5.2 and any non-Claude model
Anthropic	`https://api.ofox.ai/anthropic`	Claude models only

Pick OpenAI Compatible. The gateway does expose GLM-5.2 over an Anthropic-protocol endpoint too, which matters if you drive it from Claude Code, but inside Cline the OpenAI Compatible slot is the path that behaves.

Step 2: Open Cline settings and select the provider

Click the Cline icon in the VS Code Activity Bar, then the gear icon at the top of the panel. Under API Provider, select OpenAI Compatible.

Step 3: Set the base URL and key

Paste the base URL and your API key.

Base URL: https://api.ofox.ai/v1
API Key:  sk-ofox-...

Expected result: the fields save and Cline stops warning about a missing key.

Step 4: Set the Model ID

Set the Model ID to the namespaced id, prefix included:

z-ai/glm-5.2

A bare glm-5.2 fails on a gateway, because the catalog is namespaced by provider. If you have seen glm-5.2[1m] elsewhere, that alias is a Claude Code convention on Z.ai’s own coding endpoint for switching on the 1M window; it is not what Cline’s OpenAI Compatible field wants. Here the model ID and the context setting do that job separately. The full set of access paths and where each ID applies is in our GLM-5.2 access guide.

Step 5: Set the context window and test

In the OpenAI Compatible model settings, set the context window to 1000000. GLM-5.2 ships a 1M-token window; leave Cline on a smaller default and it will quietly drop earlier tool-call steps on a long task, which reads as the model “losing the plot” mid-refactor.

Then send a short message in the Cline chat, such as “list the files in this project.” If Cline reads the tree and replies, the wire is connected. Point it at something small next, like “add input validation to the parseConfig function and a test for it,” and watch that it reads files on its own, proposes a diff you approve, and runs the test. If it reads but never writes, that is a known GLM behavior, not your config; the errors section covers it.

You can confirm GLM-5.2’s live model ID and per-token rates on its ofox model page before you commit a project to it.

The Thinking Toggle: What Cline Actually Sends GLM-5.2

This is the section that surprises people coming from a Claude setup, so it is worth being precise.

GLM-5.2 is a reasoning model with thinking on by default. Z.ai’s docs are explicit that thinking is “activated by default in GLM-5.2 … series” (the same line covers GLM-5.1, GLM-5, and GLM-4.7). The documented way to change that is a thinking object on the request:

"thinking": { "type": "disabled" }

Here is the catch. Cline’s OpenAI Compatible provider does not send that object. Its Model Configuration has a Reasoning Effort selector that defaults to none; set it to low, medium, or high and Cline sends a reasoning object ({enabled: true, effort}) instead. Those are two different controls, and GLM’s on/off switch is the one Cline never touches.

What this means in practice:

Control	Cline OpenAI Compatible	GLM-5.2 native
Turn thinking on/off	Not exposed	`thinking: {type: enabled/disabled}`, default on
Tune reasoning depth	Reasoning Effort selector, `none` default (low/medium/high)	Gateway-dependent mapping (unverified per gateway)
Reasoning output	Returned as `reasoning_content`	Returned as `reasoning_content`
Send any reasoning hint	Move the selector off its `none` default	On by default

Two consequences worth internalizing. First, if you want any reasoning hint to reach the model, you have to move the Reasoning Effort selector off its none default; left at none, Cline sends no reasoning parameter at all. Second, whether that reasoning object actually changes GLM’s behavior depends on the gateway translating it into GLM’s own thinking control, and it will not disable thinking regardless. GLM thinks; you pay for those tokens as output. Plan for it rather than trying to switch it off.

GLM-5.2 vs Claude Sonnet 5: The Cost Math

This is the comparison that decides the setup. Both models are coding-capable, both carry a 1M context, and on ofox both sit behind the same key, so the choice is real rather than a migration.

Model	Input	Output	Cache read	Context	Model ID
GLM-5.2	\$1.4/M	\$4.4/M	\$0.26/M	1M	`z-ai/glm-5.2`
Claude Sonnet 5	\$2/M	\$10/M	\$0.20/M	1M	`anthropic/claude-sonnet-5`

The Sonnet 5 rates above are Anthropic’s introductory pricing, in effect through August 31, 2026 per Anthropic’s pricing docs; the standard rate afterward is \$3/M input and \$15/M output, which widens GLM’s lead. The current per-token numbers match the ofox model pages.

Blend those at a 2:1 input-to-output ratio, which is typical for coding turns: GLM-5.2 lands near \$2.40 per million tokens, Sonnet 5 near \$4.67. That is roughly a 1.9x gap on raw rates, and it holds around 1.6x once you account for Sonnet 5’s cheaper cache reads. Note the one place Sonnet wins: its cache read at \$0.20/M actually undercuts GLM’s \$0.26/M, so for the resent context Cline leans on every turn, Sonnet’s caching is slightly more efficient per cached token.

Put real numbers on a session. Say a working session moves roughly 2M input and 200K output across many turns:

Scenario	GLM-5.2	Claude Sonnet 5
Session, no caching	~\$3.68	~\$6.00
Session, ~70% context cached	~\$2.08	~\$3.48
Team month (5 devs x 20 days, cached)	~\$208	~\$348

So GLM-5.2 is meaningfully cheaper, on the order of 1.6x for realistic cached workloads, not the 5x you see when comparing a value model against a flagship. That gap is real money at team scale, and it is the whole case for GLM as the default driver. It is also small enough that if you are already a Claude shop getting native tool use and cache controls out of Cline’s Anthropic provider, staying on Sonnet 5 is a defensible call. For the deeper per-token breakdown against the other frontier models, see our GLM-5.2 vs GPT-5.5 cost analysis, and for the Claude side of this exact setup, the Claude Sonnet 5 in Cline guide.

Common Errors During Setup (and Fixes)

GLM’s open-weight lineage means its Cline integration is rougher than Claude’s, and most of the friction is well-documented rather than mysterious.

Symptom	Cause	Fix
`model not found`	Bare ID, or the `glm-5.2[1m]` alias on the wrong endpoint	Use `z-ai/glm-5.2` on the OpenAI Compatible slot
Reads files, never edits	GLM re-parses the file without emitting an edit call (Cline #7486, GLM-4.6/MiniMax-M2, closed)	Keep tasks small and context at 1M; escalate stubborn turns
Tool tags shown as plain text, then stalls	Thinking tokens leak into `content`, Cline treats it all as reasoning (Cline #5843, GLM-4.5, closed)	Update Cline to a build that parses GLM’s `reasoning_content`
Reasoning hint has no effect	Reasoning Effort left at its `none` default sends no reasoning params (Cline #6581, gpt-5, closed)	Set Reasoning Effort to low/medium/high in the model options
Model forgets earlier steps mid-task	Context window left at Cline’s default	Set the context window to `1000000`
`401 Unauthorized`	Key is for a different gateway, or blank	Paste the key that matches your base URL

If a model ID resolves but responses feel truncated, check that Cline’s max-output setting is not clipping the answer before the reasoning pass and the actual reply both fit. GLM-5.2 supports up to 128K output tokens, but Cline’s default cap is much lower.

Team / Multi-Developer Configuration

For a team the win is one endpoint and one model policy instead of everyone wiring their own keys against their own GLM subscription. Register a single gateway, hand each developer a key through your secret manager, and standardize the Cline provider settings so everyone routes z-ai/glm-5.2 through the same base URL. Billing lands in one place, and switching the whole team’s default is a one-line change to the shared Model ID rather than a fleet of individual reconfigurations.

The habit that pairs with this is model tiering: run GLM-5.2 as the cheap default for the bulk of turns and escalate only the genuinely hard ones to a stronger model. Because ofox exposes GLM, Claude, and the rest on the same key, escalation is a single Model ID swap, not a new integration. The routing logic is the same one in our \$30 AI coding stack guide, and the general endpoint mechanics are in the Cline API configuration guide.

Alternatives: Other Ways to Run GLM-5.2

Cline through ofox is the setup this guide recommends, because one key covers GLM plus every model you would escalate to. It is not the only path.

ofox (OpenAI Compatible), recommended. z-ai/glm-5.2 at https://api.ofox.ai/v1, pay-as-you-go, and the same key reaches Claude and GPT for the hard turns.
Z.ai directly. Z.ai’s own API and Coding Plan serve GLM-5.2 natively, including the glm-5.2[1m] alias for the 1M window on the coding endpoint. Cheapest if you only ever use GLM and want the native thinking controls. The GLM-5.2 access guide walks through it.
OpenRouter. Also exposes z-ai/glm-5.2 behind an OpenAI-compatible slot, useful if you already route everything through it. See openrouter.ai/z-ai/glm-5.2.
Self-hosting the open weights. GLM-5.2’s weights make a local vLLM deployment possible if your workload justifies the hardware. We costed that out in self-hosting GLM-5.2 on vLLM, and the free-tier paths are in GLM-5.2 free: the \$0 routes.

FAQ

How do I run GLM-5.2 in Cline? Open Cline settings, pick the OpenAI Compatible provider, set the Base URL to https://api.ofox.ai/v1, paste your key, set the Model ID to z-ai/glm-5.2, and set the context window to 1000000. Send a test message.

What model ID does Cline use for GLM-5.2? z-ai/glm-5.2 through the gateway, prefix included. A bare glm-5.2 fails, and the glm-5.2[1m] alias belongs to Z.ai’s coding endpoint, not Cline’s OpenAI Compatible field.

Does GLM-5.2 work with Cline’s agent mode? Yes, through OpenAI Compatible it reads files, writes diffs, and runs commands. Tool use runs through a translation layer and GLM has documented parsing quirks, so keep command approval on.

How do I turn off GLM-5.2’s thinking in Cline? You can’t from the UI. Thinking is on by default and the off switch is the thinking: {type: disabled} parameter, which Cline’s OpenAI Compatible path does not send. The Reasoning Effort selector (default none) tunes depth, not on/off.

Is GLM-5.2 cheaper than Claude Sonnet 5? On raw rates yes, about 1.6-1.9x (\$1.4/\$4.4 vs \$2/\$10 on ofox). Sonnet 5’s cheaper cache reads and native Cline integration narrow the practical gap.

Why does GLM read files but never edit them? The same behavior was tracked for earlier GLM builds (GLM-4.6) in Cline issue #7486, now closed; it can still surface with 5.2 on the compatible path. Keep tasks small and context at 1M; escalate the turn if it persists.

Why do I see <think> tags or raw reasoning in the output? GLM’s reasoning_content is leaking into the main stream and Cline stalls on tool use. Update Cline to a build that parses the reasoning field.

What context window should I set? 1000000. GLM-5.2 has a 1M window and up to 128K output; a smaller setting drops earlier steps on long tasks.

Sources Checked for This Refresh

Z.ai thinking-mode documentation. Confirms thinking is on by default for GLM-5.2, the thinking: {type} parameter, and clear_thinking (verified 2026-07-28).
Z.ai GLM-5.2 model reference. Source for the 1M context, up to 128K output, and the reasoning_content field.
Cline repository and issues #5843 (GLM-4.5), #6581 (gpt-5), #7486 (GLM-4.6/MiniMax-M2), all closed. Reasoning-effort handling and GLM tool-call behavior on the compatible path.
ofox model pages for z-ai/glm-5.2 and anthropic/claude-sonnet-5. Per-token rates \$1.4/\$4.4 and \$2/\$10, cache reads \$0.26/M and \$0.20/M (verified 2026-07-28).
Anthropic pricing documentation. Source for the Sonnet 5 introductory window through August 31, 2026 and the standard \$3/\$15 rate afterward.

Originally published on ofox.ai/blog.

Claude Opus 5 vs GPT-5.6 Sol (2026): Benchmarks + Real Bill

Owen — Mon, 27 Jul 2026 04:36:11 +0000

Claude Opus 5 vs GPT-5.6 Sol (2026): Benchmarks + Real Bill

TL;DR. Claude Opus 5 and GPT-5.6 Sol are two frontier models priced within a rounding error of each other, and the "cheaper" one depends on where you buy. On vendor list price they match on input ($5/M) and cache ($0.50/M), and differ only on output: $25/M on Opus 5 versus $30/M on Sol, so on list Opus 5 is ~17% cheaper. On ofox as of July 27, 2026, Sol is on a -20% promo ($4/$24/$0.40) while Opus 5 sits at list, which flips it: on ofox, Sol is currently cheaper on every line. On the one third-party benchmark that scores both on the same harness, the Artificial Analysis Intelligence Index v4.1, Opus 5 leads by two points (61 vs 59 at max effort). Every other launch number is vendor-reported on a different harness and cannot be lined up. Sol streams tokens ~1.4x faster (75.9 vs 52.8 tok/s); Opus 5 reaches first token ~1.9x faster (69.7s vs 129.5s). Both live on one ofox key, so the honest way to decide is a one-line A/B on your own tasks. This post gives you the numbers that are real, flags the ones that aren't, and hands you the harness.

TL;DR: Which One Should You Pick?

Your job	Pick	Why
Cheapest on ofox right now	Sol	ofox runs Sol at -20% ($4/$24/$0.40); cheaper on every line while the promo holds
Cheapest on vendor list price	Opus 5	Output $25/M vs $30/M; input and cache identical
Highest score on a neutral composite	Opus 5	AA Intelligence Index 61 vs 59 at max effort
Latency-sensitive interactive turns	Opus 5	~69.7s to first token vs ~129.5s on the same test
Streaming a long answer as fast as possible	Sol	~75.9 output tok/s vs ~52.8
You already run the OpenAI Responses API and want Pro/Ultra	Sol	Heavy-compute modes are Sol-only
Computer use and desktop automation	Opus 5	Anthropic's OSWorld/AutomationBench framing (vendor, unverified)

One sentence: Opus 5 wins the one comparable benchmark and starts faster; Sol streams faster, owns the heavy-compute ceiling, and is the cheaper model on ofox while its promo lasts. These two are close enough that the tie-breaker is your own workload, so keep both on one key and A/B them.

Quick Specs Comparison

Both models are current flagships, both went live within three weeks of each other (Sol at GA on July 9, Opus 5 on July 24). The table below lists vendor list price and the ofox price separately, because they differ: ofox is running Sol on a 20% promo. All figures verified against each model's ofox page on July 27, 2026.

Spec	Claude Opus 5	GPT-5.6 Sol
ofox model ID	`anthropic/claude-opus-5`	`openai/gpt-5.6-sol`
Input (list)	$5.00 / M	$5.00 / M
Output (list)	$25.00 / M	$30.00 / M
Cached input (list)	$0.50 / M	$0.50 / M
ofox price (Jul 27)	$5 / $25 / $0.50 (list, no promo)	$4 / $24 / $0.40 (-20% promo)
Context window	1,000,000 tokens	1,000,000 tokens
Max output	128,000 tokens	128,000 tokens
Reasoning control	Adaptive thinking + effort `low`–`max`	`reasoning_effort` `none`–`xhigh` (chat); Responses API for `max`
Heavy-compute mode	Fast Mode (speed), no parallel-subagent tier	Pro / Ultra (Sol only, Responses API)
Native API	Anthropic Messages	OpenAI Responses / chat

On paper the two nearly match: same context, same output cap, and the same $5 list input. The two spots that actually separate them are price (identical on list except output, but currently reshuffled by ofox's Sol promo) and which native API you reach for reasoning control. The pricing section below works both prices through a real bill.

The One Number You Can Actually Compare

Here is the trap in every GPT-5.6-vs-Opus-5 post you will read this week: they build a big table with Terminal-Bench in one row and CursorBench in the next and a SWE-Bench number below that, as if those figures came off the same ruler. They did not. Anthropic ran Opus 5 on Anthropic's harness. OpenAI ran Sol on OpenAI's. A benchmark name is not a shared measurement.

The one place both models are scored by the same third party, on the same tasks, with the same grader, is the Artificial Analysis Intelligence Index v4.1. That index is a weighted composite of nine evaluations, including GDPval-AA v2, Terminal-Bench v2.1, SciCode, Humanity's Last Exam, GPQA Diamond, and AA-LCR, weighted roughly 34% toward agents, 24% coding, 24% scientific reasoning, and 18% general intelligence. Because Artificial Analysis runs both models itself, on its own harness, its composite is the closest thing to an apples-to-apples read that exists right now, and the eval mix leans toward exactly the agentic and coding work most people are choosing between these two for.

Artificial Analysis Intelligence Index v4.1	Claude Opus 5	GPT-5.6 Sol
Intelligence Index, max effort	61	59

Source: Artificial Analysis comparison page, read July 27, 2026. Opus 5 is scored in Adaptive Reasoning at max effort; Sol at max. AA is a rolling benchmark, so the exact figures can shift, re-read the page on publish day.

Opus 5 leads by two points at max effort. That is a real, reproducible, same-harness result, and it is the strongest single fact in this comparison. It is also small. For context, the same index puts Claude Fable 5 at 60 (max), which means AA's composite rates Opus 5 a hair above Anthropic's own larger flagship, and rates Sol a hair below it. Read that carefully before you over-invest in it. A two-point gap on a nine-eval composite is not a knockout. It tells you Opus 5 is at least Sol's equal on a broad neutral test, and probably a shade better, but it does not tell you which one is better at your refactor, your migration, or your agent loop. That is what the A/B at the end is for.

Why the Launch Benchmarks Don't Line Up

Both vendors published launch numbers. They are worth reading, as long as you read them as two separate marketing decks and never as a shared table. Split by source:

Anthropic's Opus 5 figures (Anthropic internal, unverified, from the Opus 5 announcement):

Benchmark	Anthropic's claim
Frontier-Bench v0.1	Surpasses all other models; more than doubles Opus 4.8
CursorBench 3.2	Within 0.5% of Fable 5's peak, at half the cost
ARC-AGI-3	Roughly 3x the next-best model
OSWorld 2.0 (computer use)	Beats Fable 5 at one-third the cost
GDPval-AA (economic work)	State of the art

OpenAI's GPT-5.6 Sol figures (OpenAI's own harness, from the GA launch):

Benchmark	OpenAI's claim
Terminal-Bench 2.1	88.8% base, 91.9% in Ultra mode
Agents' Last Exam	53.6 (medium beats Fable 5 by 11.4 pts at ~1/4 cost)
SWE-Bench Pro	64.6%

You cannot subtract one table from the other. Notice what happens if you try: OpenAI's own SWE-Bench Pro line has Sol at 64.6%, while Anthropic reports Fable 5 at 80% on the same-named benchmark, which would suggest the Claude family is well ahead on that one. But those two figures also come from different harness runs, so even that comparison is soft. The honest position is that the launch decks establish each model is frontier-class in its vendor's own tests, and nothing more. Two more points worth keeping straight, because loose paraphrases are already circulating:

91.9% is Ultra, not base. The Terminal-Bench headline that gets quoted as "GPT-5.6 hits 91.9%" is Sol running the heavy-compute Ultra mode, a parallel-subagent architecture that is not the default and costs a lot more per task. Base Sol is 88.8%. The 3.1-point Ultra gain rarely pays for itself outside the hardest agent problems.
The "half the price of Fable 5" line is Anthropic's, and it is about Opus 5, not Sol. Opus 5's pitch is near-Fable-5 intelligence at half the Fable price. Do not attach it to GPT-5.6.

For a fuller walkthrough of how the Claude flagship tier actually lands on coding tasks, the Fable 5 vs Opus 4.8 vs GPT-5.5 SWE-Bench breakdown splits the harnesses the same way this post does.

Pricing Math: List Price Says Opus 5, ofox Currently Flips It

There are two prices here and they disagree, so keep them apart.

Vendor list price. Anthropic lists Opus 5 at $5 input / $25 output / $0.50 cached per million tokens. OpenAI lists Sol at $5 / $30 / $0.50. Input and cache match exactly, so on list pricing the only line that differs is output, and the whole dollar gap is your output volume at a flat $5/M. On list, Opus 5 is the cheaper model, by 17% on output and nothing else. Artificial Analysis, blending at its own cache/input/output profile, agrees: about $3.85 per 1M for Opus 5 versus $4.35 for Sol.

ofox price today. This is where it flips. As of July 27, 2026, ofox runs GPT-5.6 Sol at a 20% discount, $4 input / $24 output / $0.40 cached, against its $5/$30/$0.50 list. Opus 5 sits at list, $5/$25/$0.50, no promo. So on ofox right now, Sol is the cheaper model on every single line: input $4 < $5, output $24 < $25, cache $0.40 < $0.50. The list-price verdict inverts. Promos move, so re-check both model pages the day you commit a route.

Put real ofox numbers on it. A coding-agent fleet at 100,000 requests a day, 4K input and 2K output per request:

Line item	Opus 5 ($5/$25)	Sol -20% ($4/$24)
Input: 4K × 100K/day	$2,000/day	$1,600/day
Output: 2K × 100K/day	$5,000/day	$4,800/day
Daily total (no cache)	$7,000	$6,400
Monthly (×30)	~$210,000	~$192,000
Difference	-$18,000/mo on Sol

Turn on a realistic 70% input cache hit rate and the ordering holds, just tighter. Opus 5's effective input rate drops to about $1.85/M and Sol's to about $1.48/M, landing Opus 5 near $172,000/month and Sol near $162,000, roughly $10K/month apart. The gap narrows under caching because Sol's cheaper input matters less once most input is already cached, but on ofox Sol stays ahead as long as the promo is live.

So the cost answer has a shelf life. On vendor list price Opus 5 wins; on ofox as of late July, Sol's promo makes it cheaper outright. If you buy through ofox, treat price as a point for Sol until the discount ends, and let the AA index lead, the latency split, and the API shape be what actually separate the two.

Two adders the base rate hides, and they do not cancel evenly. A web-search tool call is billed per request, and it is not equal: on ofox, Sol charges $0.035 per search versus $0.015 for Opus 5, so search-heavy agents tilt back toward Opus 5. And the speed premiums are separate line items: Opus 5's Fast Mode runs the same model at up to 2.5x output speed for double the base rate, and Sol's Pro and Ultra modes cost more tokens per task. Model those into your own numbers rather than the base table.

Speed and Latency: They Win Different Races

Cost is a near-tie that depends on where you buy. Speed is a genuine split, and which model is "faster" depends entirely on what you are measuring. Artificial Analysis benchmarked both under load (read July 27, 2026; these are rolling figures):

Metric (AA, max effort)	Claude Opus 5	GPT-5.6 Sol
Output speed	52.8 tok/s	75.9 tok/s
Time to first token	69.7 s	129.5 s

Sol streams about 1.4x faster once it is producing tokens, so for a long generated answer where the user watches it stream, Sol finishes sooner. Opus 5 reaches the first token roughly 1.9x faster, so for short interactive turns, tool-calling loops, and anything where perceived responsiveness matters, Opus 5 feels quicker. (Both time-to-first-token numbers are large because these are reasoning models under a heavy-effort test; the ordering, not the absolute seconds, is the point.) If you run an interactive coding assistant, low first-token latency usually beats raw throughput, which tilts toward Opus 5. If you run batch generation of long documents, throughput wins, which tilts toward Sol.

The API Reality: What Actually Breaks When You Switch

The benchmarks are a near-tie; the API shapes are not. This is where the two models feel genuinely different, and it is the part most comparison posts skip. If you are migrating a real codebase, these are the things that will actually cost you an afternoon.

Reasoning control lives in different places. Opus 5 uses Anthropic's model: adaptive thinking is on by default, and you steer depth with an effort ladder from low to max (defaulting to high). Sol uses OpenAI's reasoning_effort parameter, which accepts none through xhigh on /v1/chat/completions; OpenAI routes the Pro and Ultra modes, and recommends max effort, through the Responses API. So dialing Opus 5 to maximum reasoning is a one-word change, while Sol's heaviest modes generally mean moving to a second endpoint.

Opus 5 turns thinking on by default; that can truncate you. On Opus 4.8 a request with no thinking field ran without thinking. On Opus 5 the same request reasons, and because max_tokens caps thinking plus visible output together, a workload tuned for silent 4.8 can truncate. Set thinking: {"type": "disabled"} to restore the old behavior, or raise max_tokens. One catch that surprises people: on the Anthropic API, disabling thinking is only allowed at effort high or below, so disabled plus xhigh/max returns a 400.

Sol 404s on the bare ID. On ofox, openai/gpt-5.6 does not resolve; you must pass openai/gpt-5.6-sol (or -terra/-luna). If you A/B by string-swapping the model field, use the explicit tier or you will spend ten minutes debugging a not-found error. Our GPT-5.6 tier guide covers the full Sol/Terra/Luna split if you want the cheaper tiers in the same routing table.

For the complete Opus 5 migration checklist, including the cache-minimum drop to 512 tokens and the sampling-param rejections that carry over from 4.8, the Opus 5 API guide walks through every change.

When to Pick Claude Opus 5

Reach for Opus 5 when:

You buy at vendor list price and output dominates your bill. Agentic coding, long code generation, verbose tool-use loops. On list, the 17% output discount is real money at scale and predictable to model. (On ofox, note Sol's promo currently undercuts this; see the pricing section.)
You want the highest neutral score. Opus 5 leads the AA Intelligence Index 61 vs 59 at max effort. It is a two-point lead, but it is the only same-harness lead anyone has.
First-token latency matters. Interactive assistants and tool-calling agents feel snappier at ~69.7s TTFT versus ~129.5s.
You are on Claude Code or the Anthropic protocol already. Opus 5 is a drop-in model-string change from 4.8, same $5/$25 list pricing, and it slots into anthropic/claude-opus-5 on ofox with no new SDK.
Computer use and desktop automation are in scope. Anthropic's OSWorld 2.0 and AutomationBench framing is the strongest part of its deck (still vendor-reported, so verify).

When to Pick GPT-5.6 Sol

Reach for Sol when:

You buy on ofox and want the lowest bill right now. While ofox's -20% promo holds, Sol is cheaper than Opus 5 on every price line ($4/$24/$0.40). Re-check before you commit, since promos expire.
You stream long answers and throughput is the bottleneck. 75.9 tok/s versus 52.8 is a 1.4x edge on sustained generation.
You need Pro or Ultra heavy-compute. The parallel-subagent Ultra mode that posted 91.9% on Terminal-Bench has no Opus 5 equivalent. If your hardest agent tasks genuinely benefit from that mode, it lives only on Sol.
Your stack is already OpenAI-native. If you are deep in the Responses API, tool schemas, and OpenAI's ecosystem, Sol is the zero-friction upgrade and the max effort path is already wired.
You want tier flexibility on one family. Sol, Terra, and Luna share a generation, so you can drop to Terra at half the price for bulk traffic and keep Sol for the hard tail, all on the same key.

When NOT to Pick Either

Some workloads should not be paying flagship rates at all. If your task is high-volume classification, routing, short chat glue, or anything where a bounded, well-specified prompt gets a short answer, both of these models are overkill and overpriced. Send that traffic to a cost tier: on ofox, GPT-5.6 Luna runs about $0.80/$4.80 per M and Claude Sonnet 5 about $2/$10, and keep Opus 5 or Sol for the reasoning-heavy tail. The most expensive mistake in production LLM routing is running every request through a flagship because one hard case needed it. Route by difficulty, not by default. If you want a structured way to decide, Best AI Model for Coding 2026 and Best AI Model for Agents 2026 lay out the full tiering.

Here is the same decision as a routing table:

If the request is…	Route to	Because
Bounded, short, high-volume (classification, routing)	Luna or Sonnet 5	Flagship rates are wasted on short bounded answers
Reasoning-heavy, and the lowest ofox bill matters now	Sol	The -20% promo makes it cheaper on every line
Reasoning-heavy, buying at vendor list price	Opus 5	17% cheaper output; leads the AA index
Interactive, first-token latency matters	Opus 5	~1.9x faster to first token
Long streamed output, throughput matters	Sol	~1.4x higher tokens/sec
Needs Pro or Ultra heavy-compute	Sol	No Opus 5 equivalent

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

The only comparison that settles this is the one you run on your own tasks, and the friction of running it is usually what stops people. On ofox both models sit on the same OpenAI-compatible endpoint under one key, so an A/B is a loop over two model strings. Same SDK, same billing line, no second account. The two IDs are anthropic/claude-opus-5 and openai/gpt-5.6-sol.

Python — A/B both models in one loop

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="your-ofox-key")

MODELS = ["anthropic/claude-opus-5", "openai/gpt-5.6-sol"]
task = "Refactor this module for testability and explain the two riskiest changes:\n\n<paste your real code>"

for model in MODELS:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": task}],
    )
    usage = r.usage
    print(f"\n=== {model} ===")
    print(r.choices[0].message.content)
    print(f"[in={usage.prompt_tokens} out={usage.completion_tokens}]")

Run it across 20-30 of your real tasks, not one toy prompt, and log completion_tokens per model. Multiply that count by each model's output rate (whichever price you actually pay, list or the current ofox promo) and you are measuring quality and cost in the same loop.

Node — same shape

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: "your-ofox-key" });

const models = ["anthropic/claude-opus-5", "openai/gpt-5.6-sol"];
const task = "Find the race condition in this service and propose a fix:\n\n<paste your real code>";

for (const model of models) {
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: task }],
  });
  console.log(`\n=== ${model} ===`);
  console.log(r.choices[0].message.content);
  console.log(`[in=${r.usage.prompt_tokens} out=${r.usage.completion_tokens}]`);
}

To exercise Opus 5's adaptive thinking or Sol's reasoning_effort, point the Anthropic-native calls at https://api.ofox.ai/anthropic with model claude-opus-5, and the Sol max-effort calls at the OpenAI Responses API. For a plain quality-and-cost A/B, the chat/completions loop above is enough, and it is the fastest way to replace a launch-day benchmark argument with a number from your own workload.

The Honest Verdict

Strip away the launch-week noise and the picture is narrow. On the one benchmark that measures both models the same way, Opus 5 is two points ahead at max effort (61 vs 59). On price the answer depends on where you buy: at vendor list price Opus 5 is ~17% cheaper on output, but on ofox right now Sol's -20% promo makes it cheaper on every line. On latency Opus 5 starts faster (~1.9x to first token); on throughput Sol streams faster (~1.4x). Everything else, the CursorBench numbers, the Terminal-Bench 91.9%, the "beats Fable 5" claims, is vendor-reported on a private harness and should move your decision by roughly nothing until you reproduce it.

That makes this a genuinely close call, not a blowout. Opus 5 has the durable edges: the neutral-composite lead, the lower first-token latency, and the drop-in path from Claude Code and Opus 4.8. Sol counters with faster streaming, the Pro and Ultra heavy-compute modes that have no Claude equivalent, and, while the promo lasts, the cheaper ofox bill. Neither should be handling your bulk classification or routing traffic; that belongs on a cost tier.

The two-point index gap is not a reason to migrate a production route on its own, and neither is a promo that can expire next week. Both are reasons to run the A/B, because the case for either model is built from small, real edges, and the only thing that turns that into a decision is your own eval. Both models are one string apart on the same key. Spend the afternoon.

References

Related: Claude Opus 5 API guide — pricing, the 4.8→5 changes, and how to call it. GPT-5.6 tiers: Sol, Terra, Luna — which tier for which job. GPT-5.6 Terra vs GPT-5.5 — the half-price mid tier. Fable 5 vs Opus 4.8 vs GPT-5.5 on SWE-Bench — the Claude flagship tier on coding.

Originally published on ofox.ai/blog.

Claude Opus 5 API: Fable 5-Class at Half Price, Complete Guide

Owen — Sun, 26 Jul 2026 04:33:50 +0000

Claude Opus 5 (claude-opus-5) shipped July 24, 2026 at $5/$25 — half Fable 5's price. Benchmarks, the Opus 4.8 to 5 API changes, and how to call it via ofox.

What Anthropic Shipped

Claude Opus 5 is Anthropic's new recommended default for complex agentic coding and enterprise work. The model ID is claude-opus-5 with a fixed, dateless snapshot and no version suffix. It carries a full 1M-token context window, 128K maximum output tokens (expandable to 300K through Message Batches API with beta header), and May 2026 knowledge cutoff.

The pricing represents a significant capability-to-cost ratio: "a thoughtful and proactive model that comes close to the frontier intelligence of Claude Fable 5 at half the price." Fable 5 costs $10/$50 per million tokens; Opus 5 lists at $5 input/$25 output—matching Opus 4.8's rate since May and undercutting Fable 5 by fifty percent. Fast Mode runs the same model at up to 2.5x output speed for double the base cost.

Fable 5 remains Anthropic's most capable model. Opus 5 targets users seeking most of that capability without the Fable premium.

Benchmarks: Anthropic's Own Numbers

All figures presented are Anthropic internal and unverified vendor launch numbers, not third-party results. Treat them as best-case scenarios and run independent evaluations before commitment.

Benchmark	Anthropic internal figure (unverified)
Frontier-Bench v0.1	Surpasses all other models; more than doubles Opus 4.8's score
CursorBench 3.2	Within 0.5% of Fable 5's peak, at half the cost
ARC-AGI 3	Roughly 3x the next-best model
OSWorld 2.0 (computer use)	Beats Fable 5's result at one-third the cost
Zapier AutomationBench	Pass rate ~1.5x the next-best model
GDPval-AA (real economic work)	State of the art

The consistent theme spans agentic and computer-use work—long-horizon coding, desktop control, real-task automation—where Opus 5 either matches Fable 5 for substantially less money or outperforms competing models. Anthropic acknowledges one honest limitation: Opus 5 stays behind Mythos 5 on cybersecurity-exploitation and biology-research tasks, handled by a separate model line for defensive use. Non-applicable workloads face no gap.

What Changed from Opus 4.8 (the part that breaks code)

Opus 5 maintains the same request surface as 4.8 in most respects, but three changes will surprise users swapping the model string without additional modifications.

1. Adaptive thinking is on by default

On Opus 4.8, a request without a thinking field ran without thinking. On Opus 5, the identical request now runs with adaptive thinking. Since max_tokens is a hard cap on total output—thinking plus visible response—workloads tuned for no-thinking 4.8 can truncate. Revisit max_tokens, or pass thinking: {"type": "disabled"} to retain the old behavior.

2. Disabling thinking is capped at `high` effort

This is the new 400 error users don't expect. You can disable thinking, but only at effort high or below. Combining thinking: {"type": "disabled"} with effort xhigh or max triggers rejection:

# Rejected on Opus 5 — 400 error
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "xhigh"},   # xhigh/max + disabled = 400
    messages=[{"role": "user", "content": "..."}],
)

# Fix: either re-enable thinking at high effort...
output_config={"effort": "xhigh"}         # thinking on by default
# ...or keep it off and drop to high or below
thinking={"type": "disabled"}, output_config={"effort": "high"}

3. The cache minimum drops to 512 tokens

Cache thresholds decreased from 1,024 on 4.8. Short system prompts previously too small to cache now create cache entries without code modification—a small, free win on prompt-caching expenses.

Two additional considerations: mid-conversation tool changes are now possible without invalidating the prompt cache (beta header mid-conversation-tool-changes-2026-07-01), and Opus 5 ships cybersecurity safety classifiers, requiring handling of stop_reason: "refusal" with optional automatic model fallbacks (fallbacks: "default", beta header server-side-fallback-2026-07-01).

Unchanged elements: pricing, the 1M context window, 128K output, and hard rejections from 4.8—non-default temperature/top_p/top_k, manual budget_tokens, and assistant prefill all return 400. Priority Tier remains unsupported.

Effort and Prompting Notes

Opus 5 supports the complete effort ladder—low, medium, high, xhigh, max—defaulting to high on Claude API and Claude Code. Anthropic recommends running a fresh effort sweep rather than carrying over 4.8 settings, and testing max for capability-critical work (allocate large max_tokens, starting around 64K, for xhigh or max).

Two behavioral shifts warrant prompt review. Opus 5 verifies its own work without explicit instruction, so explicit "double-check your output" directives now cause over-verification—remove them. Default responses run longer than 4.8's; lowering effort trims thinking but not visible length, so prompt for conciseness or target length directly for shorter output.

How to Call Opus 5 Through ofox

The model ID on ofox.ai is anthropic/claude-opus-5, on the same OpenAI-compatible endpoint as every other model—no separate Anthropic account or billing. Point your existing OpenAI SDK at the ofox base URL and change two strings:

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="your-ofox-key")

response = client.chat.completions.create(
    model="anthropic/claude-opus-5",
    messages=[{"role": "user", "content": "Refactor this module for testability..."}],
)

To use adaptive thinking and the effort parameter, call the Anthropic-native endpoint instead—the model ID drops the provider prefix:

import anthropic

client = anthropic.Anthropic(
    base_url="https://api.ofox.ai/anthropic",
    api_key="your-ofox-key",
)

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=8000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},   # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": "Audit this service for race conditions..."}],
)

Running through one gateway makes the migration question empirical: put identical prompts through Opus 5, Opus 4.8, and Fable 5 on one key and compare quality and token counts on your workload before switching production.

Opus 5 vs Fable 5 vs Sonnet 5: Which to Pick

Claude Opus 5 ($5/$25)—the new default for agentic coding, computer use, and long-horizon enterprise tasks. Best capability-per-dollar in the lineup right now.
Claude Fable 5 ($10/$50)—the ceiling. Reach for it only when a task genuinely needs the most capable model and cost is secondary; on many agentic benchmarks Opus 5 is within a rounding error at half the price.
Claude Sonnet 5 ($3/$15)—the speed-and-cost tier. Near-Opus quality on coding for high-volume or latency-sensitive work where you don't need Opus-level reasoning depth.

For Opus 4.8 users, this is a clean migration: same price, higher scores, one model-string change plus the three gotchas above.

Verdict

Opus 5 is another Opus upgrade with no asterisk on price—same $5/$25, materially higher scores across coding and computer-use, and Anthropic's claim of near-Fable-5 capability at half the cost holds up across a broad benchmark set. The caveats are narrow and honest: benchmark numbers are Anthropic internal and unverified (run your own evals), disabling thinking now conflicts with high effort levels, and default output runs longer so watch your max_tokens and latency budgets.

For new projects, start on Opus 5. For anything in production on 4.8, change the model string, revisit max_tokens, audit any request that disables thinking, and ship.

Originally published on ofox.ai/blog.

Qwen Image 3.0 Pro Free API (2026): Setup, Caps, and 429s

Owen — Sat, 25 Jul 2026 04:35:18 +0000

Alibaba released Qwen Image 3.0 Pro on 2026-07-21, and it went up on ofox at $0. Not $0 tokens with a per-image charge hiding underneath, which is how most image models on this gateway are priced. Nothing per image either. It is a real zero, not a trial credit that quietly drains.

It is also not the kind of free you should build a product on this week, and the reason is written on the model card in Chinese where most English coverage has skipped past it: "本版本为限时免费体验版，目前为限量体验阶段" (Limited-time free trial version, currently in a limited-quota phase). Two separate constraints, and the second one is the one that will actually interrupt your afternoon.

Here is what the free tier gives you, what it takes away, and the three integration details that will break code you copied from a gpt-image-2 tutorial. Every image in this post is raw output from the model, generated on 2026-07-23.

What You Can Do After This Setup (And What You Can't)

What you can do

Generate images at $0, tokens and per-image both, through an OpenAI-compatible endpoint, text-to-image, at arbitrary sizes

Time required

About 3 minutes if you already have an ofox key

What you need

An ofox API key, Python 3.8+ or Node 18+, and the openai SDK you probably already have installed

What you can't do

Run a batch. Plan around a published quota. Assume the price holds next month. Get base64 back. Use reference images (see below)

Decision Frame: When to Use This (and When NOT)

Use it when:

You are evaluating image models and want to test Qwen 3.0 Pro's text rendering against your own prompts before committing budget anywhere.
You generate images occasionally and interactively, a few per hour, where a 429 costs you a retry rather than a failed job.
You need Chinese text inside images and your current model mangles it. This is the capability where Qwen is genuinely differentiated, and it costs nothing to verify.

Don't use it when:

You are generating in bulk. The quota phase makes throughput unpredictable, and unpredictable throughput in a batch job is worse than a known price.
You have a latency SLA. Backoff on a 429 is measured in tens of seconds here, not hundreds of milliseconds.
You are writing something that must still work in three months without anyone looking at it. The free listing is explicitly time-boxed.

Stop rule

If all you wanted was to know whether the text rendering claim is real, read the four test images below and skip the rest of this guide. The short version is that it holds for words and fails for sequences, and you do not need to integrate anything to benefit from knowing that.

System Requirements

An ofox API key from the ofox dashboard.
Python 3.8 or later with openai>=1.0, or Node 18+ with the openai package. No Alibaba account, no DashScope key, no separate region config.
Somewhere to write files. The endpoint hands you a URL, not bytes, and that URL does not live forever.

Step-by-Step Setup

Step 1: Point the SDK at ofox

from openai import OpenAI

client = OpenAI(
    base_url="https://api.ofox.ai/v1",
    api_key="YOUR_OFOX_KEY",
)

Expected result: no output. If the import fails, upgrade with pip install -U openai.

Step 2: Call the model

resp = client.images.generate(
    model="bailian/qwen-image-3.0-pro:free",
    prompt="A ceramic mug on a linen cloth, morning light, shallow depth of field",
    size="1024x1024",
    n=1,
)
print(resp.data[0].url)

Expected result: an https://dashscope-*.oss-accelerate.aliyuncs.com/... URL printed to stdout.

Node, if that is your stack:

import OpenAI from "openai";

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

const r = await client.images.generate({
  model: "bailian/qwen-image-3.0-pro:free",
  prompt: "A ceramic mug on a linen cloth, morning light",
  size: "1024x1024",
  n: 1,
});
console.log(r.data[0].url);

Step 3: Download the bytes before they expire

import urllib.request

urllib.request.urlretrieve(resp.data[0].url, "out.png")

Expected result: out.png on disk, typically 1 to 1.5 MB at 1024x1024.

This step is not optional housekeeping. Read the next section before you write the URL into a database.

The Two Integration Details That Break Copied Code

It returns a URL, not base64

Most image-generation tutorials in circulation are written against gpt-image-2, which returns b64_json. Qwen 3.0 Pro on this endpoint returns url and leaves b64_json empty. Code that does this:

raw = base64.b64decode(resp.data[0].b64_json)   # TypeError on Qwen

fails on a None. Handle both shapes if you route across models:

item = resp.data[0]
raw = (base64.b64decode(item.b64_json) if item.b64_json
       else urllib.request.urlopen(item.url).read())

The URL points at Alibaba's OSS and carries a signed expiry. Persist the bytes. A URL stored in your database is a broken image later.

The free quota is per-moment, not per-day

There is no published requests-per-minute number, so we measured what we could observe. Firing requests back to back returned 429 Requests rate limit exceeded on the second call. Running two generation processes concurrently caused both to 429 and neither to progress until one was killed. A single sequential worker with escalating backoff starting at 45 seconds completed every request it attempted.

That shape, immediate 429 under any concurrency, generous success when strictly serial, is what a limited-quota trial phase looks like from the outside. It is not an outage and retrying harder makes it worse.

Call pattern	Result
Two requests back to back	Second returns 429 immediately
Two processes in parallel, same key	Both 429, neither completes until one is killed
One worker, 45s backoff, 20s gap between jobs	Every request completed
Same pattern, four jobs in a row	All four completed, no 429 after the first clear

The practical reading: the limiter cares about concurrency and burst far more than about total volume. A single-threaded loop with a pause is not a workaround, it is the intended usage shape.

import time, openai

def generate(prompt, size="1024x1024", tries=6):
    for i in range(tries):
        try:
            r = client.images.generate(
                model="bailian/qwen-image-3.0-pro:free",
                prompt=prompt, size=size, n=1)
            return r.data[0].url
        except openai.RateLimitError:
            time.sleep(45 * (i + 1))
    raise RuntimeError("quota never cleared")

# Through the OpenAI SDK a 429 arrives as openai.RateLimitError.
# You only catch urllib's HTTPError(429) if you call the HTTP endpoint directly.

Does the Text Rendering Claim Hold Up?

Alibaba's pitch for this generation is typography: small text staying legible, long prompts staying coherent, multiple scripts in one frame. Those are checkable, so we checked them. Every image below is raw model output at the size given, no retouching and no cherry-picking across attempts.

Test 1: small print in a spec table

The prompt asked for four labelled rows with exact values and a fine-print serial line at the bottom.

Every value landed: Pressure 9 bar, Boiler 1.6 L, Weight 12.4 kg, Warranty 24 months. The bottom line reads Serial AT-2026-0731 / Made in Suzhou, correct down to the slash and the hyphenated serial. At 1024x1536 that fine print is roughly 8pt equivalent. No dropped glyphs, no invented characters, no melted letterforms in the small sizes, which is where image models usually give themselves away.

Test 2: two scripts in one frame

Mixed English and Chinese on a single sign, each with its own line and a shared numeric field.

Both scripts are correct. 开发者专场 and 注册签到 are properly formed characters, not the character-shaped noise that most image models produce for CJK. The Latin and Chinese lines share a consistent weight and the 09:00 matches on both rows.

For anyone who has tried to get a usable Chinese-language poster out of a Western image model, this is the interesting result in the whole post, and it is the one you can verify yourself for nothing.

Test 3: a technical diagram with many labelled parts

This is the case that usually collapses. The prompt named five strings that had to appear (CLIENT, GATEWAY, MODEL, RESPONSE, and a legend of auth / route / inference) and left the captions under each block unspecified.

All five specified strings rendered correctly and in the right positions. What the model did unprompted is the part worth noting: it added a title, numbered the arrows 1. Request / 2. Forward / 3. Output, and wrote its own captions that are technically coherent rather than lorem-ipsum shaped ("Validates authentication / Routes to endpoint" under the gateway). The spelling holds throughout.

That makes it plausible for first-draft documentation diagrams. It does not make it reliable, because the captions it invents are its own guesses about your architecture and it will state them just as confidently when they are wrong.

Test 4: where it actually breaks

We asked for a code editor screenshot with a file tree, syntax-highlighted Python, and visible line numbers 1 through 14.

The chrome is close to perfect. Filenames are correct and correctly icon-matched, the status bar reads UTF-8 CRLF Python 3.12 Ln 8, Col 22 Spaces: 4 exactly as prompted, the menu bar is coherent, and the syntax highlighting assigns plausible colours to keywords, strings and function names.

Now read the gutter. The line numbers run 1, 3, 3, 4, 6, 7, 9, 8, 0, 8, 11, 11, 12, 13, 14. There is no 2, no 5, no 10, several duplicates, and a stray 0. Then look at the last line of code: if __name__ = "__main__":, with a single equals sign where Python needs two.

This is the honest boundary of the model. Words and labels, including small ones and Chinese ones, come out right. Sequences and code operators do not. A line-number gutter is the purest test of monotonic counting there is, and the model produced something that looks like counting from a distance and falls apart on inspection. The same weakness shows up as the = where == belongs.

Practical rule: use it for anything where a human reads the text as language. Do not use it for screenshots that a reader will treat as literally correct code, or for charts where the axis labels have to be a real sequence. That is not a prompt engineering problem you can fix with a better prompt, it is what the model is currently bad at.

Sizes: There Is No Aspect Ratio Enum

Several image endpoints accept a fixed list of sizes and reject anything else, which is why so much generation code carries a lookup table mapping "widescreen" to whatever string that particular vendor blessed. This one does not appear to work that way.

Size passed	Returned	Use
`1024x1024`	As requested	Default square
`1024x1536`	As requested	Portrait, posters and spec cards
`1664x928`	As requested	Widescreen, close to 16:9

Every value we passed came back at exactly that resolution. If you are generating blog heroes or social cards at a fixed aspect ratio, you can ask for the final dimensions directly instead of generating square and cropping, which is one fewer place for a composition to get its head cut off.

The caveat is that this is observed behaviour rather than a documented contract. Validate the dimensions of what comes back rather than assuming, especially if you are feeding the output into a layout that breaks on the wrong ratio.

Reference Images: We Could Not Get Them to Work

The model card lists reference-image input alongside text-to-image. We could not make it work through this endpoint, and the way it fails is worth documenting because it fails quietly.

Three shapes tried, all against the same source image (the espresso poster from Test 1) with a prompt asking for an ink-sketch restyle that preserved the layout and spec values:

Attempt	Result
`images.generate(..., image="data:image/png;base64,...")`	HTTP 200, image returned, reference ignored entirely
`images.generate(..., image_url="data:image/png;base64,...")`	HTTP 200, image returned, reference not reproduced
`POST /images/edits`	HTTP 400 `You must provide a model parameter`, with `model` present in the body

The first attempt is the clearest. Given a photograph-style poster of an espresso machine, it returned a botanical serum advertisement. Correct style, entirely unrelated subject. Nothing from the reference survived.

The second attempt looked closer at a glance and is more instructive on inspection. That is on-topic, but only because the prompt named the subject in words. Compare the numbers against Test 1. The source poster says boiler 1.6 L and weight 12.4 kg; this one says 2.0 L and 28 kg. The four-row table became an eight-cell grid, the product shot became a cutaway with callouts, and the warranty row vanished. The one value that matches, 9 bar, is the standard pressure for every espresso machine ever built, so it is not evidence of anything.

In other words the model generated a fresh image from the prompt text and did not use the reference. The third attempt is worse than either, because a 400 complaining about a missing model parameter that is demonstrably present will send you debugging your own serialization for twenty minutes.

What we can say precisely: reference-image input is documented for this model, and we did not find a parameter shape that delivers it through ofox's OpenAI-compatible image endpoint. It may work through Alibaba's native DashScope API, or the correct parameter name may be something we did not try. What it does not do is fail loudly, so if you build on it, verify that the output actually reflects your input rather than assuming a 200 means it worked.

Common Errors During Setup

Error	What it means	Fix
`429 Requests rate limit exceeded`	Free-tier quota, not an outage	Serialize requests, back off 45s and up. Do not parallelize
`TypeError: expected str, got None` on `b64_json`	You copied gpt-image-2 code	Read `data[0].url` and fetch it
Image URL 403s later	OSS signed URL expired	Download at generation time, store the bytes
`model_not_found`	Missing the `:free` suffix	The ID is `bailian/qwen-image-3.0-pro:free`, colon included
Empty `data` array	Prompt hit a content filter	Rephrase. The endpoint does not always return an explicit refusal reason

Team / Multi-Developer Configuration

The quota behaviour has a consequence that matters more for teams than for individuals: your developers throttle each other. Two people iterating on prompts against the same free model at the same time is the concurrency case that reliably 429s.

Three ways to handle it, in increasing order of effort:

One key, one queue. Put generation behind a single-worker job queue rather than letting each developer's laptop call the endpoint directly. This is the change that actually fixes it.
Split by model, not by key. Qwen is the only free image model on ofox, so this means moving bulk work onto a paid model and keeping Qwen for the typography cases where it wins. Seedream 5.0 Lite at $0.035/image is the cheapest place to put that bulk work.
Fall back automatically. Catch the 429 and retry against a paid model with real throughput. At $0.035 to $0.05 per image, a handful of unblocked images costs less than an engineer waiting.

Because everything sits behind one base URL and one key, option 3 is a model string change rather than a second integration.

CHAIN = [
    "bailian/qwen-image-3.0-pro:free",   # $0, quota-capped
    "volcengine/doubao-seedream-5.0-lite",  # $0.035/image
    "openai/gpt-image-2",                # $4/M in, $24/M out
]

def generate_with_failover(prompt, size="1024x1024"):
    for model in CHAIN:
        try:
            r = client.images.generate(
                model=model, prompt=prompt, size=size, n=1)
            return model, r.data[0]
        except Exception as e:
            if "429" not in str(e):
                raise
    raise RuntimeError("all providers throttled")

Return the model name alongside the image. When you later wonder why one batch looks different from another, knowing which model actually served each request saves an hour.

Planning for the Day the Free Window Closes

"Limited-time" with no published end date is a scheduling problem disguised as a pricing note. The failure mode is not that you get a bill. It is that one morning the model ID stops resolving, or starts resolving to a paid variant, and whatever you wired it into stops working for reasons nobody on your team remembers.

Three cheap precautions, none of which take longer than the setup itself:

Keep the model ID in config. One string in an environment variable, not scattered through six call sites. This is the whole mitigation for most teams.
Log which model served each image. If output quality shifts, you want to know whether the model changed under you before you start blaming your prompts.
Know your fallback's price before you need it. The alternatives table below exists so that the decision is already made when the 429s turn permanent.

If you are archiving generated images, this matters more than it sounds. The signed OSS URLs expire on their own schedule, so an image you generated for free and linked rather than downloaded is a broken asset waiting to happen regardless of what the pricing does.

Alternatives When Qwen Throttles You

Model	ofox price	Notes
`bailian/qwen-image-3.0-pro:free`	$0, nothing per image	The only genuinely free one. Quota-capped, time-boxed
`volcengine/doubao-seedream-5.0-lite`	$0.035/image	Cheapest per-image option. Bills per image, not per token
`volcengine/doubao-seedream-4.5`	$0.04/image	Previous generation of the same family
`volcengine/doubao-seedream-5.0-pro`	$0.05/image	Top Seedream tier. Natural first failover if you want a Chinese lab
`google/gemini-3.1-flash-lite-image`	$0.25/M in, $1.50/M out	Token-billed. Predictable throughput
`google/gemini-3.1-flash-image`	$0.50/M in, $3.00/M out	Token-billed, larger tier
`openai/gpt-image-2`	$4/M in, $24/M out (cache $1/M)	Most predictable. See our GPT-Image-2 release guide

Read that table carefully, because the pricing pages are easy to misread and we misread them ourselves on the first pass. Image models do not all bill the same way. The Seedream entries show $0/M on both token rows, which looks free and is not: they bill per generated image, and the Per Image line is the one that reaches your invoice. A $0/$0 token row on an image model tells you nothing.

That leaves Qwen Image 3.0 Pro as the only image model on ofox that currently costs nothing at all, per token or per image. Which cuts against the comfortable version of this story: there is no free failover. When the quota throttles you, the alternative costs money, somewhere between $0.035 and $0.05 an image on the cheap end. That is not much, but it is not zero, and a pipeline you designed around "free" needs to know which one it is.

The Seedream models are still the natural first hop. Same base URL, same key, one string to change. But they are a different family and we have not run the same four typography tests against them, so treating them as a drop-in for Qwen's text rendering would be an assumption, not a finding.

Prices verified by fetching the ofox model pages on 2026-07-23. One thing we hit while checking: for gpt-image-2 the /v1/models API returned $5/M and $30/M against our key, which is the struck-through list price the model page shows next to ofox's discounted $4/M and $24/M. We have only tested this on one key, so treat it as a reason to read the page rather than a documented rule.

The paid options earn their price in exactly one dimension that matters here, which is that you can predict them. A pipeline that must finish in a known window wants a rate limit it can read in documentation, not one it has to infer from 429s.

If you want the paid-tier comparison in depth, we have written up Seedream 4.5 and Flux 2 Max separately, and the GPT-Image-2 failure modes post covers what slow generations and 504s usually mean.

What We Could Not Verify

Being straight about the gaps, since a lot of the coverage of this release is not:

No benchmarks. Alibaba shipped this generation without a technical report or published eval numbers. Any ranking you see for Qwen Image 3.0 Pro is somebody's vibe check, including ours.
No open weights. Earlier Qwen-Image generations had downloadable weights. This one does not, so self-hosting is not an escape hatch from the quota.
No published rate limit. The numbers above are observed behaviour from one key on one afternoon, not documented limits. Yours may differ and Alibaba can change them without telling anyone.
No end date on the free pricing. "Limited-time" with no date is the entire disclosure.
The long-prompt claim is untested here. Alibaba advertises prompt handling in the thousands of tokens. Our test prompts ran to a few dozen words each, which tells you nothing about whether a 4,000-token scene description stays coherent. The quota made a proper stress test impractical in one sitting, so we are not going to pretend we ran one.
Sample size is four. Four prompts, one attempt each, no retries and no cherry-picking. That is enough to demonstrate that small-text rendering works and that number sequences break. It is not enough to put a percentage on either.

The reason to spell this out: most of the coverage of this release repeats Alibaba's capability list as though it were measured. A capability list is a claim. The four images above are four data points, which is more than a claim and much less than a benchmark.

Sources Checked for This Refresh

Originally published on ofox.ai/blog.

LLM API Rate Limits Compared (2026): 5 Vendors, 5 Rulebooks

Owen — Sat, 25 Jul 2026 00:36:19 +0000

LLM API Rate Limits Compared (2026): 5 Vendors, 5 Rulebooks

Five LLM APIs, five rate-limit rules: Anthropic caps tokens/min (10M, cache free), DeepSeek caps concurrency (500), OpenAI/Google went dashboard-only.

TL;DR. There is no single table that ranks LLM API rate limits, because the five biggest vendors do not measure the same thing. Anthropic caps requests, input tokens, and output tokens per minute, and cache reads do not count against you. Moonshot and OpenAI raise your ceiling as you spend more. DeepSeek ignores per-minute rate entirely and caps how many requests you can have running at once. Google and OpenAI have both pulled their per-model numbers off the public docs and into a dashboard. The useful question is not "who has the highest RPM." It is which limit design matches the way your app actually calls the API, and how you route around whichever one hits first.

A rate limit is not one number you can rank. Anthropic counts tokens per minute, DeepSeek counts requests in flight, OpenAI counts how much you have paid. Lining them up in one column is a category error.

Here is which limit tends to bite which kind of workload, so you can jump to the vendor design that fits.

Your workload	The limit that bites first	Design that fits
Many small, fast calls (chat UI, autocomplete)	RPM (requests/min)	Anthropic Scale, OpenAI Tier 4-5
A few huge-context calls (RAG, long docs)	Input tokens/min (ITPM / TPM)	Anthropic (cache reads free of ITPM)
Bursty parallel agents	Concurrency	DeepSeek (caps in-flight directly, 2,500 on Flash)
Steady production at real scale	Monthly spend cap	Anthropic Scale or OpenAI Tier 5 ($200k)
Just starting, tight budget	Entry-tier ceiling	Moonshot T0-T1, Gemini Free

The One Table Everyone Wants (and Why It Won't Line Up)

Every "rate limits compared" post promises a grid where you scan a column and pick the winner. The grid falls apart on contact, because the vendors disagree about what a limit even is. Here is the honest version: the same five columns, filled with the fact that the columns don't match.

Vendor	Tier is set by	What it actually caps	429 signal	Per-model numbers public?
Anthropic	Usage history (Start / Build / Scale / Custom)	RPM + input tokens/min + output tokens/min, per model class	`429` + `retry-after`	Yes, full table per tier
Moonshot / Kimi	Cumulative top-up ($1 to $3,000)	Concurrency + RPM + TPM + tokens/day	`429`	Yes, full T0-T5 table
DeepSeek	Flat (account level)	Concurrency only (in-flight requests)	`429`	Yes, per model
OpenAI	Cumulative paid ($5 to $1,000)	RPM + RPD + TPM + TPD + images/min	`429` + `x-ratelimit-*`	No, moved to dashboard
Google Gemini	Billing + spend + time	RPM + TPM + RPD, plus a 10-min spend gate	`429 RESOURCE_EXHAUSTED`	No, in AI Studio panel

Read across any row and the shape changes. Three vendors will show you exact per-model numbers; two will not. Two gate on tokens, one gates on requests in flight, two gate mostly on how much money you have moved through the account. That mismatch is the real finding, and the rest of this post is what each cell means when you are the one getting the 429.

All numbers below were pulled from each vendor's official rate-limit documentation on 2026-07-22. Where a vendor no longer publishes per-model figures, this post says so rather than guessing.

Anthropic: Three Axes, and Cache Reads Are Free

Anthropic is the most transparent of the five and also the most multi-dimensional. Every model class is limited on three axes at once: requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Exceed any one and you get a 429 with a retry-after header telling you exactly how long to wait. The bucket refills continuously (token bucket), so you are not waiting for a fixed reset.

Tiers are Start, Build, Scale, and Custom. You do not buy your way onto a tier directly; organizations move up automatically based on usage history and account standing. Each tier carries a monthly spend cap:

Tier	Monthly spend cap
Start	$500
Build	$1,000
Scale	$200,000
Custom	None (arranged with account team)

The per-model numbers are where Anthropic actually publishes detail. For Claude Opus 4.x, which shares one combined bucket across Opus 4.8, 4.7, 4.6, and 4.5:

Tier	RPM	Input tokens/min (ITPM)	Output tokens/min (OTPM)
Start	1,000	2,000,000	400,000
Build	5,000	5,000,000	1,000,000
Scale	10,000	10,000,000	2,000,000

The standout, and the reason Anthropic's ceiling is higher than it looks, is the cache-aware ITPM rule. For most Claude models, cache_read_input_tokens do not count toward ITPM. Tokens written to cache and normal input tokens still count, but tokens read back from cache are free of the rate limit. Anthropic's own worked example: a 2,000,000 ITPM limit with an 80% cache hit rate lets you push about 10,000,000 total input tokens per minute, because the 8M cached tokens don't register against the limit. Claude Haiku 3.5 is the one exception that still counts cache reads.

If a big share of your input is a stable system prompt or a long document you send on every call, that rule changes your effective throughput more than a tier bump would. We worked through the money side of this in the prompt-caching cost math; the rate-limit side is the same lever pointed at throughput instead of the bill.

Two footnotes that catch teams off guard: the Message Batches API has its own separate limits, and so do Managed Agents (300 RPM for create endpoints, 1,200 RPM for read). Hitting a wall on batch traffic does not mean your Messages API limit is spent.

Moonshot / Kimi: Pay to Climb, Four Dimensions at Once

Moonshot is the most explicit pay-to-tier ladder of the group. Your tier is set purely by cumulative top-up, from $1 to $3,000, and each tier moves four dials together: concurrency, RPM, TPM, and tokens per day (TPD).

Tiers on the international platform (platform.kimi.ai), billed in USD:

Tier	Cumulative top-up	Concurrency	RPM	TPM	TPD
Tier 0	$1	1	3	500,000	1,500,000
Tier 1	$10	50	200	2,000,000	Unlimited
Tier 2	$20	100	500	3,000,000	Unlimited
Tier 3	$100	200	5,000	3,000,000	Unlimited
Tier 4	$1,000	400	5,000	4,000,000	Unlimited
Tier 5	$3,000	1,000	10,000	5,000,000	Unlimited

One trap worth knowing before you compare these numbers against anything else: Moonshot runs two separate platforms with two separate ladders. The international platform (platform.kimi.ai, also reachable as platform.moonshot.ai) meters in USD and requires a $1 top-up before you can call anything. The mainland platform (platform.moonshot.cn) has its own RMB ladder that starts at ¥0 and steps through ¥50 / ¥100 / ¥500 / ¥5,000 / ¥20,000. Those are not currency conversions of each other, and the entry conditions differ: one gates you behind a first payment, the other does not. Check which platform your key belongs to before assuming a tier.

The jump from Tier 0 to Tier 1 is the one to notice: $9 of extra top-up takes you from 3 RPM and a single concurrent request to 200 RPM and 50 concurrent, and removes the daily token ceiling entirely. Tier 0 is really just a "prove you are real" floor, not a place to build anything.

One thing the tier table does not show: individual models can be capacity-constrained on top of your tier. A freshly launched model such as Kimi K3 can return 429 from upstream capacity even when you are nowhere near your tier limits, because the constraint is the provider's total headroom for that model rather than your account's rate. When that happens, buying a higher tier does not help; the fix is a fallback to a different model, which is the routing pattern later in this post.

DeepSeek: No RPM at All, Just Concurrency

DeepSeek is the outlier that breaks every comparison grid. It does not publish RPM or TPM limits. It caps concurrency, the number of requests you can have in flight at one time, at the account level:

Model	Concurrency cap
deepseek-v4-pro	500
deepseek-v4-flash	2,500

Stay under the cap and you can fire requests as fast as the model returns them. Cross it and you get a 429. There is no per-minute budget to pace against, which is genuinely easier to reason about for parallel workloads: you size your worker pool to the concurrency cap and stop worrying about tokens per minute.

DeepSeek also handles overload differently. Instead of rejecting a request when the servers are busy, it keeps the connection alive, sending empty lines for non-streaming calls or SSE : keep-alive comments for streaming ones, and only closes the connection if inference has not started after 10 minutes. Accounts with expanded quotas can also use the user_id parameter to isolate concurrency per end user, which matters if you are multiplexing many customers through one key. If you run DeepSeek in an agent loop, our DeepSeek V4 Pro real-cost breakdown covers how the concurrency model interacts with cache misses and thinking tokens on the bill.

OpenAI: Tier by Spend, Numbers Behind Glass

OpenAI still gates by cumulative amount paid, across six tiers:

Tier	Qualifies at	Monthly usage cap
Free	Allowed geography	$100
Tier 1	$5 paid	$100
Tier 2	$50 paid	$500
Tier 3	$100 paid	$1,000
Tier 4	$250 paid	$5,000
Tier 5	$1,000 paid	$200,000

The dimensions are broad: RPM, RPD, TPM, TPD, images per minute, and audio minutes per minute for some streaming models. When you are inside the limit, responses carry x-ratelimit-limit-requests, x-ratelimit-remaining-requests, and their token equivalents, so you can watch your headroom in real time.

Here is the catch that breaks the grid: OpenAI's rate-limit docs no longer list the specific RPM or TPM numbers per model. The page sends you to the models page or your account dashboard for the actual figures. That is not an oversight to complain about; it is a data point. OpenAI has decided per-model rate limits move often enough that a static table would mislead, so the numbers live in a dashboard tied to your account and tier. Any post that prints exact OpenAI per-model RPM as if it were fixed is quoting a snapshot that may already be stale.

Google Gemini: Tiers, Time Gates, and a 10-Minute Spend Window

Gemini's tiers combine billing status, spend, and elapsed time:

Tier	Qualifies at	Spend cap
Free	Active project or free trial	None
Tier 1	Billing account linked	$250
Tier 2	$100 paid + 3 days since first payment	$2,000
Tier 3	$1,000 paid + 30 days since first payment	$20,000 to $100,000+

The three-days and thirty-days requirements are unusual: even if you pay the money, you cannot skip the waiting period to reach Tier 2 or Tier 3. Gemini also layers a spend-based control on top of the usual RPM / TPM / RPD, enforced per rolling 10-minute window ($10 for Tier 1, $200 for Tiers 2 and 3), so a sudden burst of spend can throttle you even when your per-minute token rate is fine. Exceed a limit and you get 429 RESOURCE_EXHAUSTED.

Like OpenAI, Gemini keeps the per-model RPM / TPM / RPD numbers off the static docs and inside AI Studio, where you view your active limits. And the whole page applies only to the Gemini Developer API, not to Vertex AI, which runs its own quota system entirely.

Why the Units Don't Line Up (the Part Nobody Tables)

Step back and the incompatibility is the story. Here is what a single "unit" of headroom actually buys you at each vendor, and where that unit pinches.

Unit	Used by	What one unit of headroom buys	Where it pinches
RPM (requests/min)	All five, as one axis	N calls/min regardless of size	Many small calls
Input tokens/min (ITPM / TPM)	Anthropic, Moonshot, OpenAI, Google	N input tokens/min	Large context, RAG
Output tokens/min (OTPM)	Anthropic	N generated tokens/min	Long generations
Concurrency (in-flight)	DeepSeek, Moonshot	N requests running at once, any size	Parallel fan-out
Monthly spend cap	All five	A hard dollar ceiling per month	Sustained scale
10-min rolling spend	Google	Dollars per rolling 10 minutes	Spiky spend

A team that sends thousands of tiny classification calls hits RPM first and could not care less about ITPM. A team that pastes a 200k-token document into every request hits token-per-minute walls while its RPM sits near zero. A team running fifty parallel agents hits concurrency. These three teams cannot use the same "best rate limits" recommendation, because they are constrained by three different units, and no single ranking can serve all three.

A worked example makes the trap concrete. Say you run 50 workers, each sending a 30,000-token RAG request. On DeepSeek's deepseek-v4-pro that is 50 in-flight against a 500 concurrency cap, so you have ten times the headroom and never see a 429. Move the exact same workload to a vendor with a 2,000,000 input-tokens-per-minute limit and, if those 50 requests land inside the same minute, that is 1,500,000 input tokens in one burst, plus whatever else you are sending. You are suddenly at 75% of a limit you were not even tracking on DeepSeek, and a small traffic bump tips you over. Same concurrency, same request size, completely different wall.

This is why cross-vendor migration surprises people. The limit you were never watching becomes the one that bites, and the code path that ran clean for months starts throwing 429s the day you switch providers.

Which Limit Will Bite You First (Decision Frame)

Before you upgrade a tier or re-architect anything, figure out which wall you are actually hitting.

When to just upgrade the tier. Your 429s cluster on one axis (say, RPM), you are on a low tier, and the next tier's ceiling clears your peak with room to spare. Paying up is the cheapest fix. This is the common case for Moonshot and OpenAI, where tier is a spend dial.
When to cache instead of upgrade. You are on Anthropic, hitting ITPM, and a large slice of your input repeats across calls. Turning on prompt caching can lift effective throughput without a tier change, because cache reads do not count against ITPM. Try this before you request a limit increase.
When to route around it. Your limit is structural for the workload (a concurrency cap you keep saturating, or a model returning upstream-capacity 429s that no tier fixes). The fix is failover to a comparable model on a different provider, so a throttle degrades to a hop instead of an error. This is where the general 429 handling patterns and a multi-model router earn their keep.
Stop rule. If your 429 rate is under about 1% and clears on a single retry, you do not have a rate-limit problem, you have normal burst noise. Add jittered backoff and move on. Do not re-architect for a wall you are barely touching.

How to Read a 429 (Which Wall Did You Hit?)

A 429 is not self-explanatory, and the vendors tell you which wall you hit in different ways. Reading the response before you retry saves you from waiting out a limit you did not actually break.

Vendor	Signal to read	What it tells you
Anthropic	`retry-after` + `anthropic-ratelimit-requests-remaining` / `-input-tokens-remaining` / `-output-tokens-remaining`	Exactly which axis hit zero (requests, input, or output tokens) and how many seconds to wait
OpenAI	`x-ratelimit-remaining-requests` / `x-ratelimit-remaining-tokens`	Whether you ran out of requests or tokens for the window
DeepSeek	`429` with no documented `retry-after`	You are over your concurrency cap; reduce in-flight requests rather than just waiting
Google Gemini	`429 RESOURCE_EXHAUSTED`	Check whether it is the per-minute limit or the 10-minute spend gate
Moonshot / Kimi	`429`	Check which tier axis you crossed: concurrency, RPM, or TPM

The practical split is between "wait" limits and "slow down" limits. Anthropic, OpenAI, and Google give you a per-minute budget, so a retry-after or a remaining-tokens header near zero means back off for a few seconds and the bucket refills. DeepSeek's concurrency cap is a "slow down" limit: waiting does nothing if you keep the same number of requests in flight, because the wall is parallelism, not time. Retrying a concurrency 429 without shrinking your worker pool just re-hits the same wall. Get this distinction wrong and your backoff logic either sleeps when it should shed load, or sheds load when a one-second wait would have cleared it.

One Endpoint, Five Rulebooks

You cannot make Anthropic's ITPM or DeepSeek's concurrency cap disappear. What you can do is stop letting any one vendor's limit be a single point of failure. When five vendors each enforce a different rule, the practical defense is to put them behind one endpoint and fail a throttled request over to another vendor automatically. A gateway like ofox exposes all of them on one OpenAI-compatible API and one key, so "hit vendor A's limit" becomes "answered by vendor B" instead of a failed call. This is also the argument in why an LLM API gateway earns its place, applied specifically to rate limits.

The pattern is a short retry-then-hop loop. A 429 from any vendor triggers a couple of jittered retries, then a switch to the next model in a cross-vendor chain.

Python

import os, time, random, httpx

OFOX = "https://api.ofox.ai/v1/chat/completions"
HEADERS = {"Authorization": f"Bearer {os.environ['OFOX_API_KEY']}"}

# Same endpoint, different vendors. If one throttles, hop to the next.
CHAIN = ["deepseek/deepseek-v4-pro", "z-ai/glm-5.2", "moonshotai/kimi-k3"]

def ask(messages):
    for model in CHAIN:
        for attempt in range(3):
            r = httpx.post(OFOX, headers=HEADERS,
                           json={"model": model, "messages": messages}, timeout=60)
            if r.status_code == 429:              # any vendor's rate limit
                if attempt == 2:
                    break                         # give up on this vendor, try the next
                base = 2 ** attempt               # 1s, 2s, 4s
                time.sleep(base + random.uniform(0, base * 0.3))
                continue
            r.raise_for_status()
            return model, r.json()
    raise RuntimeError("every vendor in the chain is rate-limited right now")

Node

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOX_API_KEY });
const chain = ["deepseek/deepseek-v4-pro", "z-ai/glm-5.2", "moonshotai/kimi-k3"];
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

export async function ask(messages) {
  for (const model of chain) {
    for (let attempt = 0; attempt < 3; attempt++) {
      try {
        return { model, res: await client.chat.completions.create({ model, messages }) };
      } catch (e) {
        if (e.status !== 429) throw e;
        if (attempt === 2) break;                // hop to the next vendor
        const base = 2 ** attempt;               // 1s, 2s, 4s
        await sleep((base + Math.random() * base * 0.3) * 1000);
      }
    }
  }
  throw new Error("every vendor in the chain is rate-limited right now");
}

Swap the model string and everything else stays the same. That is the whole point: five vendors, five rulebooks, one code path. The gateway does not raise anyone's ceiling, and it will still return 429 when every vendor in the chain is full at once. It just turns "the vendor I picked is throttled" into a problem the loop solves instead of one your users see.

Alternatives: Ways to Handle Five Different Limits

ofox (unified endpoint + cross-vendor failover). One OpenAI-compatible API over Anthropic, DeepSeek, Moonshot, Google, and more, with model IDs like deepseek/deepseek-v4-pro and moonshotai/kimi-k3. Best when your real risk is any single vendor's limit stalling a request and you want the failover to be a config line, not a rewrite. It does not increase a vendor's ceiling.
Direct vendor keys, one per provider. The most control and the lowest per-token price, at the cost of integrating and monitoring each vendor's limit shape yourself. Reasonable if you are committed to one provider and its limit design fits your workload cleanly.
OpenRouter and similar aggregators. Also unify many models behind one endpoint. Compare on fee model and on how they handle provider-level versus model-level failover, since a single-provider model has nothing to route to. Match on your actual bottleneck rather than model count.
Roll your own router. A retry-and-failover layer like the loop above, maintained in-house. Full control, but you own every vendor's quirks: DeepSeek's keep-alive, Anthropic's separate batch limits, Google's 10-minute spend gate.

Whichever you pick, the rule holds: nothing deletes a vendor's rate limit. The choice is how gracefully you route around the one that hits first.

Sources Checked for This Refresh

Anthropic API rate limits (verified 2026-07-22)
Moonshot / Kimi API rate limits, international platform (verified 2026-07-22)
Moonshot / Kimi rate limits, archived copy
Moonshot mainland platform rate limits, RMB ladder (verified 2026-07-23)
DeepSeek API rate limits (verified 2026-07-22)
OpenAI API rate limits (verified 2026-07-22)
Google Gemini API rate limits (verified 2026-07-22)

Originally published on ofox.ai/blog.