pricing

Combined keys: stack your subscriptions into one credential

Jul 9, 2026

On an Unlimited subscription, the thing you’re actually shaping isn’t tokens — it’s capacity over time. Each subscription gives you a daily coverage window (the 8-hour blocks you reserve) and, within it, some number of requests you can run in parallel. Your real capacity is those two dimensions multiplied: parallel slots × hours.

Most people grow along both axes. You buy a second block to cover more of the day, or a second subscription to run more requests at once during your busy hours. The awkward part used to be the bookkeeping: every subscription minted its own key, so a serious setup meant three or four keys, each live at different times, each with its own capacity — and you juggling which one to paste where.

Combined keys remove the juggling. A combined key (it looks like sk-ci-meta-…) folds two or more of your subscriptions into a single credential, and it behaves like the union of everything underneath it.

Two rules, and that’s it

Coverage adds up. A combined key is live whenever any of its subscriptions has an open window. Reserve the Europe block on one subscription and the Americas block on another, combine them, and the one key covers both stretches of the day.

Overlap stacks parallel capacity. Where two subscriptions cover the same hour, their parallel slots add together. That’s the lever for concurrency: if you need to run more requests side by side during your peak hours, buy a second subscription over those hours and combine it in.

A concrete example. Say you hold one full-day (24h) subscription and add a second subscription on just the Europe block. The combined key gives you:

Double the parallel capacity during the Europe hours — the two subscriptions overlap there, so their slots stack.
Baseline capacity the rest of the day — only the 24h subscription is covering those hours.

Coverage is 24/7 (from the full-day subscription); parallel capacity is shaped to peak exactly when you work.

Allowances stay separate

Combining is about capacity, not billing. Each subscription keeps its own monthly allowance and its own renewal date — nothing is pooled or co-mingled. The practical upside is resilience: if one subscription lapses or you let it cancel, it simply drops out of the union. The combined key keeps working with whatever subscriptions remain — no dead key, no scramble to re-issue credentials.

It works across pools

Requests route by the model you ask for. So a combined key can span subscriptions on different pools — a Core Pool subscription and a Frontier Pool subscription under one key — and each request lands wherever its model lives. Ask for deepseek-v4-flash and it’s served from your Core subscription; ask for kimi-k2.7 and it’s served from your Frontier one. GET /v1/models on a combined key lists every model you can reach across all of them.

One credential per subscription

Combining a subscription into a key removes that subscription’s standalone key — each subscription has exactly one credential at a time. That’s deliberate: it means there’s never ambiguity about what capacity a given key carries. A key’s coverage and parallel capacity are always the exact sum of the subscriptions it holds, nothing more, nothing hidden. The dashboard walks you through it when you combine.

Creating one

In the Keys page, choose Create API Key and multi-select the subscriptions you want to combine. Before you commit, a preview shows the resulting daily coverage and peak parallel capacity, so you can see the shape you’re buying into. Prefer the API? The Management API does the same thing programmatically.

Full walkthrough in the combined keys guide. If you’re still deciding which blocks to reserve, the live menu and per-block prices are on the pools page.

CheapestInference serves frontier open-weights models — Kimi K2.7, Kimi K2.6, GLM 5.2, MiniMax M3 (Frontier Pool) and DeepSeek V4 Flash, MiMo v2.5 (Core Pool) — through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. See the pools or get started.

Qwen coding plans in 2026: what you actually get

Jul 9, 2026

Qwen3-Coder — Alibaba’s open-weights coder family — is one of the most capable coding models you can run over an API, and one of the most searched-for. If you want to run it as your daily coding model, you have a few realistic routes. As with Kimi and GLM, they differ less in headline price than in cost shape: what happens to your bill and your workflow when a heavy week hits.

Evaluating Qwen coding plans? Here’s how flat-rate unlimited access to comparable open-weights models stacks up. We don’t serve Qwen — but if what you’re really after is a fixed monthly bill for a capable open-weights coder, the same cost-shape question applies to models like Kimi K2.7, GLM 5.2, DeepSeek V4 Flash, MiMo v2.5, and MiniMax M3. Compare the flat-rate pools →

Route 1: the official Qwen Coding Plan

Alibaba Cloud sells a subscription Coding Plan on Model Studio aimed specifically at coding-tool usage of Qwen (plus a few third-party models). It’s first-party access, integrated with Qwen Code and compatible with Claude Code, Cline, and Cursor, and the Qwen coder models — qwen3-coder-plus, qwen3-coder-next, and the newer qwen3.x-plus line — arrive there first.

The trade-off is that the plan is quota-based: each tier grants a request allowance that resets on a schedule — with per-few-hours, weekly, and monthly request caps — and burning through it mid-refactor means waiting for the reset or moving up a tier. The tier lineup itself has already shifted once in 2026 (the entry-level Lite tier stopped accepting new orders), so any number printed here would go stale — check Alibaba’s Coding Plan page for the current tiers and quotas.

Good fit: you want first-party access to the newest Qwen coder models and your volume fits inside a tier’s request quota.

Route 2: per-token APIs

Qwen3-Coder is available per-token from Alibaba’s Model Studio / DashScope API and from several aggregators. No tiers, no resets — you pay for exactly the tokens you burn, which is ideal while you’re evaluating the model or your usage is light. New Model Studio accounts also get a time-limited free-token trial (region-restricted, expiring after a fixed window), useful for a first look — see Alibaba’s pricing page for the current allowance.

The catch is structural, not Qwen-specific: coding agents re-send their whole context on every tool call, so token volume compounds with every iteration. A capable coder will happily churn through long agent sessions — great for output, open-ended for the invoice. Per-token Qwen is cheap per request and unpredictable per month.

Good fit: a few million tokens a month, spiky schedules, or benchmarking before committing.

Route 3: unlimited time blocks on comparable open-weights models

The third shape is the one we sell, so apply the usual discount for self-interest — and note the honest caveat up front: we don’t serve Qwen. What we offer is the same cost shape for a lineup of comparable open-weights coders. You reserve one or more daily 8-hour time blocks and get unlimited usage during them: no token allowances, no request quotas, no resets — a monthly number that’s fixed the day you subscribe. Capacity is shaped by per-key concurrency instead of token or request budgets, so an agent that loops all afternoon changes nothing on the bill.

Two things matter if you’re weighing this against a Qwen plan:

Comparable models, one fee. A Frontier Pool block covers Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (1M context); the Core Pool covers DeepSeek V4 Flash and MiMo v2.5 — all open-weights, switchable per request. If you were choosing Qwen for capability-per-dollar, these are in the same class.
It runs in the same tools. The API speaks both the Anthropic and OpenAI formats, so it drops into Claude Code, Cline, Roo Code, or Qwen Code — no wrapper, just a base-URL change.

Current block pricing is on the pools page.

Good fit: you want a fixed monthly bill for a capable open-weights coder and predictable working hours — and you’re not locked to the Qwen name specifically.

The three routes at a glance

Route	Cost shape	Limits	Models	Best for
Official Qwen Coding Plan	Fixed monthly subscription	Request quotas that reset (per-few-hours / weekly / monthly)	First-party Qwen coder models (plus some third-party)	First-party Qwen, volume inside quota
Per-token API	Pay per token used	None — spend scales with usage	Any Qwen model on Model Studio / aggregators	Light, spiky, or exploratory use
Flat-rate time blocks (us)	Fixed monthly, per block	Concurrency-shaped; no token or request caps	Comparable open-weights (Kimi, GLM, DeepSeek, MiMo, MiniMax) — not Qwen	Predictable hours, fixed bill, model-agnostic

When to use what

Official Qwen Coding Plan — first-party access, day-one Qwen coder updates, your volume fits the request quota. Per-token — light, spiky, or exploratory usage; pay only for what you burn. Flat-rate time blocks — heavy daily coding in predictable hours where you want a constant bill and you’re open to a comparable open-weights model rather than Qwen specifically.

All three answer the same underlying question. It isn’t “which Qwen tier is cheapest” — it’s which cost shape matches how you work, and whether you need the Qwen name or just a capable open-weights coder at a fixed price.

CheapestInference serves Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier Pool) and DeepSeek V4 Flash and MiMo v2.5 (Core Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. We do not serve Qwen. See the pools or get started.

Kimi coding plans in 2026: K2.7, K2.6, and what you actually get

Jul 8, 2026

Kimi K2.7 — Moonshot AI’s open-weights flagship — is currently one of the most capable coding models you can run over an API, and its predecessor K2.6 remains a strong, cheaper-to-serve option. If you want Kimi as your daily coding model, you have three realistic routes. As with GLM, they differ less in headline price than in cost shape: what happens to your bill and your workflow when a heavy week hits.

Route 1: the official Kimi coding plan

Moonshot sells subscription plans aimed specifically at coding-tool usage of Kimi. It’s first-party access, tightly integrated with their own tooling, and the models arrive there first. The trade-off is that the plans are quota-based: each tier grants a usage allowance that resets on a schedule, and burning through it mid-refactor means waiting for the reset or moving up a tier. Tiers and allowances change often enough that any number printed here would go stale — check Moonshot’s pricing page for the current shape.

Good fit: you want first-party access and your coding volume fits comfortably inside a tier’s allowance.

Route 2: per-token APIs

Kimi K2.7 and K2.6 are available per-token from Moonshot’s open platform and from several aggregators. No tiers, no resets — you pay for exactly the tokens you burn, which is ideal while you’re evaluating the model or your usage is light.

The catch is structural, not Kimi-specific: coding agents re-send their whole context on every tool call, so token volume compounds with every iteration. A model as eager to work as K2.7 will happily churn through long agent sessions — great for output, open-ended for the invoice. Per-token Kimi is cheap per request and unpredictable per month.

Good fit: a few million tokens a month, spiky schedules, or benchmarking before committing.

Route 3: unlimited time blocks

The third shape is the one we sell, so apply the usual discount for self-interest — but the mechanics are easy to verify. You reserve one or more daily 8-hour time blocks and get unlimited Kimi usage during them: no token allowances, no resets, a monthly number that’s fixed the day you subscribe. Capacity is shaped by per-key concurrency instead of token budgets, so an agent that loops all afternoon changes nothing on the bill.

Three properties matter for coding specifically:

Both Kimis under one fee. A Frontier Pool block covers Kimi K2.7 and K2.6 (model ids kimi-k2.7, kimi-k2.6), switchable per request — use K2.7 for the hard problems and K2.6 where it’s already enough.
It runs inside Claude Code natively. The API speaks both the Anthropic and OpenAI formats, so Kimi drops into Claude Code, Cline, Roo Code, or whatever tool you already use — no wrapper, just a base-URL change.
The subscription isn’t Kimi-only. The same block also covers GLM 5.2 and MiniMax M3 (1M context). If Kimi is your main model but not your only one, that’s four coding plans for the price of one.

Current block pricing is on the pools page.

Good fit: Kimi is your daily driver, your working hours are roughly predictable, and you want the bill to be a constant instead of a variable.

When to use what

Official Moonshot plan — first-party access, day-one model updates, your volume fits the quota. Per-token — light, spiky, or exploratory usage; pay only for what you burn. Time-block unlimited — heavy daily coding or agent work in predictable hours; fixed cost, both K2 generations plus two more frontier models under one fee.

All three routes serve the same open-weights models. The question isn’t “which Kimi is better” — it’s which cost shape matches how you work.

CheapestInference serves Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier Pool) and DeepSeek V4 Flash and MiMo v2.5 (Core Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. See the pools or get started.

GLM 5.2 coding plans in 2026: what you actually get

Jul 6, 2026

GLM 5.2 — Zhipu AI’s (Z.ai) frontier coding and reasoning model — has become one of the most searched-for open-weights models for coding work. If you’re trying to run it as your daily coding model, you have three realistic routes, and they differ less in price than in cost shape: what happens to your bill and your workflow when usage spikes.

Route 1: the official Z.ai coding plan

Z.ai sells subscription tiers aimed at coding-tool usage of GLM. You get first-party access and tight integration with their own tooling. The trade-off is that the plans are quota-based: each tier grants an amount of usage that resets on a schedule, and hitting the ceiling mid-task means waiting or upgrading. For usage details and current tiers, check Z.ai’s pricing page — quotas and tiers change often enough that any number printed here would go stale.

Good fit: you want first-party access and your usage fits comfortably inside a tier’s quota.

Route 2: per-token APIs

GLM 5.2 is available per-token from several inference providers and aggregators. No quotas, no tiers — you pay for exactly what you use, which is ideal for light or unpredictable usage.

The catch is the same one that applies to every agent workload: coding agents re-send their whole context on every tool call, so token volume scales with iterations. Per-token GLM is cheap per request and open-ended per month — the bill is a dependent variable of how hard your agent worked.

Good fit: a few million tokens a month, spiky schedules, or evaluation before committing to anything.

Route 3: unlimited time blocks

The third shape is the one we sell, so discount accordingly — but the mechanics are simple to verify. You reserve one or more daily 8-hour time blocks and get unlimited GLM 5.2 usage during them: no token caps, no quota resets, a fixed monthly number decided at subscription time. Capacity is shaped by per-key concurrency rather than token budgets, so a runaway agent loop changes nothing on the invoice.

Two properties matter for coding specifically:

It works as a drop-in coding plan. The API is Anthropic- and OpenAI-compatible, so GLM 5.2 runs inside Claude Code, Cline, Roo Code, or any tool you already use — model id glm-5.2.
The subscription isn’t GLM-only. A Frontier Pool block covers Kimi K2.7, Kimi K2.6, and MiniMax M3 (1M context) too, switchable per request. If GLM is your main model but not your only one, that’s four coding plans for the price of one.

Current block pricing is on the pools page.

Good fit: GLM is your daily-driver coding model, your hours are roughly predictable, and you want the bill to be a constant.

When to use what

Official Z.ai plan — first-party access, quota fits your volume, you use their tooling. Per-token — light, spiky, or exploratory usage; pay only for what you burn. Time-block unlimited — heavy daily coding or agent work in predictable hours; fixed cost, no quota anxiety, multiple frontier models under one fee.

All three serve the same open-weights model. The question isn’t “which GLM is better” — it’s which cost shape matches how you work.

CheapestInference serves GLM 5.2, Kimi K2.7, Kimi K2.6, and MiniMax M3 (Frontier Pool, from $44.20/mo billed annually) and DeepSeek V4 Flash and MiMo v2.5 (Core Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. See the pools or get started.

Unlimited DeepSeek: what a flat monthly subscription changes

Jul 6, 2026

DeepSeek has a well-earned reputation as the budget option among frontier-quality models. Per-token rates for DeepSeek V4 Flash run around $0.14 per million input tokens and $0.28 per million output — an order of magnitude below closed-source flagships.

So why would anyone pay a flat monthly fee for it?

Because per-token pricing has a property that doesn’t care how low the rate is: cost scales with tokens, and agent tokens scale with iterations, not value. Cheap per token is not the same as cheap per month.

The math nobody runs until the invoice arrives

A coding agent re-sends its growing context on every tool call. A typical task burns 300–500K tokens; an active developer runs dozens of tasks a day. Being conservative:

	Tokens/day	Tokens/month	Per-token cost (V4 Flash rates)
Light use	2M	60M	~$11/mo
Daily driver	15M	450M	~$80/mo
Heavy agent loops	50M	1.5B	~$270/mo

The rate is tiny. The bill is not — and it’s unpredictable, because next month’s iteration count is unknowable in advance.

A time-block subscription inverts this: you reserve a daily 8-hour window and usage inside it is unlimited. The number on your invoice is decided when you subscribe, not by how many times your agent loops. DeepSeek V4 Flash is served in the Core Pool — current pricing is on the pools page.

At “daily driver” volume, the flat block is cheaper than even DeepSeek’s per-token rates — and the gap only widens from there.

What you get with the subscription

DeepSeek V4 Flash with a 1M-token context window — whole codebases, long documents, extended agent runs in a single request.
No token caps during your blocks. The plan is unlimited in tokens; capacity is shaped by per-key concurrency instead, so one busy key never affects another.
MiMo v2.5 included. A Core Pool subscription covers every model in the pool — Xiaomi’s MiMo v2.5 shares the same 1M-context class.
Drop-in API. OpenAI-compatible (/v1/chat/completions) and Anthropic-compatible (/anthropic/v1/messages) — point your SDK, Cline, or Claude Code at it with model id deepseek-v4-flash.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.cheapestinference.com/v1",
    api_key="sk-...",  # subscriber key
)
r = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Review this repo for race conditions: ..."}],
)

When per-token DeepSeek is still the right call

Honesty clause: if your usage is light or spiky — a few million tokens a month, unpredictable hours — per-token is cheaper and you should use it. The flat block wins when usage is heavy and concentrated in predictable hours: agent development, batch processing, a working day of assisted coding. That’s the break-even logic in one sentence; the full break-even analysis is here.

CheapestInference serves DeepSeek V4 Flash and MiMo v2.5 (Core Pool, from $5.94/mo billed annually) and Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. See the pools or get started.

Your AI bill should scale with users, not usage

Jul 5, 2026

If you’re building a product with AI features, you’re probably doing two things at once: charging your users a flat monthly price, and paying your inference provider by the token.

That’s a structural mismatch. Your revenue scales with the number of users. Your AI bill scales with what those users do. Those are different curves, and the gap between them is your margin.

This post makes one argument: for a product with users, your inference cost should be a function of headcount, not behavior — because that’s the only model where you can offer an unlimited experience and know your worst-case bill in advance.

Two ways to buy inference

Metered (per-token): you pay for every token in and out. Your cost is a function of user behavior — decided by your users, known only after the fact, and unbounded.

Capacity (per-seat): you pay a flat price for a reserved slot that serves one request at a time with no token caps. Your cost is a function of how much capacity you provision — decided by you, known before the month starts, and bounded.

Everything in this post follows from that one difference: who controls the variable your bill depends on.

	Metered (per-token)	Capacity (per-seat)
Bill is a function of	User behavior	Capacity you provision
Who controls it	Your users	You
Known	After the fact	Before the month starts
Worst case	Unbounded	The subscription price
Heavy user	Costs you more	Costs you the same

The fat-tail problem

Per-user token consumption is not a bell curve. It’s fat-tailed: most users send a few short conversations, and a small minority — power users, users who wire your product into a workflow, users running agents — consume one or two orders of magnitude more than the median.

When your COGS are metered, you price your product for the median and bleed on the tail. That leaves you three options, all bad:

Cap usage. “You’ve used your 50 messages this month.” Your most engaged users hit the wall first — you punish exactly the people who love the product.
Pass the meter through. Credit systems, token balances, per-message pricing. Users ration a feature they’re paying for, and usage anxiety kills adoption.
Eat it. Accept that some fraction of your users are unprofitable and hope the average holds. Your margin is now a bet on user behavior.

Per-seat capacity dissolves the trilemma instead of picking a corner: the heavy user and the light user cost you exactly the same, so you don’t need to cap, meter, or gamble.

The math

With metered pricing, your monthly cost is a sum over things you don’t control:

COGS = Σ (tokens per user × price per token)     ← one term per user, unbounded

With per-seat capacity, it’s a product of things you do control:

COGS = seats × price per seat                     ← known before the month starts

And here’s the part that makes the second equation better than it first looks: seats scale with peak concurrency, not with user count. A thousand users don’t make a thousand simultaneous requests — they make a handful at peak, because usage spreads across the day. You provision for the busiest moment, the same way you provision web servers.

Two consequences:

Your bill is a step function of how many users you serve simultaneously — which grows much more slowly than signups.
Your cost per user falls as you grow, because more users share the same peak capacity. Metered pricing has no equivalent: cost per user stays flat at best, and rises if engagement improves.

Under metered pricing, engagement is a cost. Under per-seat capacity, engagement is free. You’ve aligned your COGS with your business for the first time: more users → more revenue → step up capacity when queues grow. Nothing in that loop depends on how hard each user hits the API.

What bounded COGS buys your product

You can offer unlimited AI to your own users. No credit meters, no message counters, no “upgrade to continue.” This is the single biggest UX difference between AI features people use constantly and AI features people ration. You can only make that promise downstream if someone made it to you upstream.

Pricing becomes arithmetic. Gross margin per user = your price − (seat cost ÷ users per seat). Every input is known in advance. Compare that to forecasting a fat-tailed usage distribution and multiplying by a per-token rate.

A runaway user is a queueing problem, not a financial incident. On metered infrastructure, a user who wires your product into a retry loop shows up on your invoice. On seats, the worst they can do is saturate one slot and wait in line — they cannot add a cent to your bill.

You stop building cost-control infrastructure. Spend alerts, per-user budget tracking, anomaly detection on your own invoice — that’s engineering effort that exists only because your provider’s pricing made user behavior your financial problem.

What the seat model asks of you

Honesty about the trade: capacity pricing is not magic, it’s a different discipline.

One request at a time per key. A seat serves requests serially. Your backend keeps a pool of keys and dispatches to the least busy one — the same pattern as a database connection pool, and about as much code.
You scale in steps, not on a smooth curve. When p95 queue time creeps up, you add a seat. That’s the whole capacity-planning playbook.
Reserved time windows. Seats here are daily 8-hour blocks — reserve the block that matches your traffic hours, or all three for 24/7 coverage.
Fair use applies. Unlimited means no token counting during your reserved hours; it doesn’t mean reselling raw capacity.

If you’ve ever sized a server fleet, none of this is new. The point is precisely that it turns inference into infrastructure you provision instead of a utility that meters you.

When the meter is still right

Per-token pricing is the better buy when usage is genuinely sporadic — a weekly batch job, an internal tool ten people touch once a day. A seat that idles is money spent on capacity you didn’t use. Metered pricing is also right when you need a specific proprietary model, or thousand-way burst parallelism for a few minutes a day.

The crossover is steady, user-driven traffic: the moment real users generate load every day — and especially the moment agents multiply that load by 10–50× — the meter’s “pay only for what you use” becomes “pay for whatever your users decide,” and the flat seat wins.

Running it in practice

Size for peak concurrency. Count simultaneous in-flight AI requests at your busiest hour. That’s your starting seat count — not your user count.
Pool the keys. One API key per seat, least-busy dispatch in your backend. Keys are independent, so one saturated seat never affects the others.
Watch queue time, not spend. Your only scaling signal is latency. When it degrades at peak, add a seat; the bill changes by exactly one known number.
Match blocks to traffic. A product with a single dominant timezone can cover its whole day with one block per seat and pay a fraction of 24/7 coverage.

The API is OpenAI-compatible, so the switch is a base URL and a key.

We serve six open-weight models across two flat-rate pools — Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 in the Frontier pool (from $44.20/mo), DeepSeek V4 Flash and MiMo v2.5 in the Core pool (from $5.94/mo) — with unlimited time-block subscriptions: no token caps during your reserved hours, one key per seat. Your users’ usage never becomes your problem. Get started or see plans.

OpenRouter alternatives in 2026: unified LLM APIs compared

Apr 15, 2026

OpenRouter solved a real problem: one API key, hundreds of models, no separate accounts per provider. You point your code at openrouter.ai/api/v1 and pick any model from any provider.

But OpenRouter isn’t the only unified API anymore. And depending on your workload, it might not be the cheapest or fastest option. Here’s how the alternatives compare.

What OpenRouter does well

Credit where it’s due:

Model coverage: 200+ models from dozens of providers. If a model exists, OpenRouter probably has it.
Automatic routing: openrouter/auto picks a model for you based on your prompt. Useful for prototyping.
Fallback: If one provider is down, OpenRouter routes to another. You don’t handle failover yourself.
Single billing: One account, one API key, one invoice. No managing 8 provider accounts.

For developers who want access to everything and don’t want to manage multiple integrations, OpenRouter is a good default.

Where OpenRouter gets expensive

OpenRouter adds a margin on top of each provider’s per-token price. This is how they make money — they’re a reseller. The markup varies by model but is typically 5–20% above the direct provider price.

For low-volume usage, the convenience premium is negligible. For high-volume or agent workloads, it compounds:

Model	Direct price (input)	OpenRouter price	Markup
Claude Sonnet 4.6	$3.00/M	$3.00/M	0%
DeepSeek V3.2	$0.27/M	$0.30/M	+11%
Llama 3.1 70B	$0.13/M	$0.16/M	+23%
Qwen 3.5 397B	$0.40/M	$0.48/M	+20%

The markup is smallest on premium models (where the provider’s price already includes healthy margin) and largest on cheap open-source models (where OpenRouter’s fixed costs are a bigger percentage).

For an agent consuming 10M tokens/day on DeepSeek V3.2, the markup adds $9/month. Not a lot. But on a team of 10 with multiple agents each, it adds up — and the per-token model itself is the real problem for agent workloads.

The alternatives

Together AI

Best for: Fastest open-source model inference.

Together runs their own GPU clusters optimized for open-source models. No reselling — they serve the models directly. This means lower latency and often lower prices than OpenRouter for the same model.

100+ models
Own infrastructure (not reselling)
Competitive pricing on open-source models
Dedicated endpoints for production workloads
Per-token pricing only

Together doesn’t carry proprietary models (no Claude, no GPT). If you need Anthropic or OpenAI alongside open-source, you need a second integration.

Fireworks

Best for: Low-latency inference with custom model support.

Fireworks focuses on speed. Their custom serving infrastructure delivers lower latency than most providers, especially for open-source models. They also support fine-tuned model deployment.

50+ models
Very low latency
Fine-tuned model hosting
Serverless and dedicated options
Per-token pricing only

Like Together, Fireworks doesn’t carry proprietary models natively.

Groq

Best for: Absolute lowest latency.

Groq’s custom LPU hardware delivers the fastest inference in the market for supported models. If your use case is latency-sensitive (real-time chat, voice agents), Groq is hard to beat.

15+ models (smaller catalog)
Sub-second TTFT on most models
Free tier available
Per-token pricing

Limited model selection. No Claude, no GPT. But what they have is fast.

CheapestInference

Best for: Agent workloads and cost certainty.

Full disclosure — this is us. Here’s what we do differently:

Time-block subscriptions: Subscribe to a model pool and reserve one or more daily 8-hour blocks (Asia-Pacific, Europe, or Americas — all three for full 24/7 coverage). The Frontier pool ($52–$61/mo per block, from $44.20/mo billed annually) carries Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3. The Core pool ($6.99/mo per block, from $5.94/mo annually) carries DeepSeek V4 Flash and MiMo v2.5. No per-token billing.
Unlimited during your hours: During your reserved block, usage of every model in your pool is unlimited with no budget cap — fair use is one request at a time per key. Pay by card (Stripe) or USDC on Base.
A focused lineup: six curated open-weight models through one OpenAI- and Anthropic-compatible endpoint.
x402 pay-per-request: No account needed — agents pay with USDC on Base L2 per request.

The trade-off: a small, curated model catalog instead of OpenRouter’s breadth, no proprietary models, and no automatic routing between providers.

Side-by-side comparison

	OpenRouter	Together	Fireworks	Groq	CheapestInf.
Models	200+	100+	50+	15+	6 (curated)
Proprietary models	Yes	No	No	No	No
Pricing model	Per-token	Per-token	Per-token	Per-token	Time-block flat-rate
Unlimited in reserved hours	No	No	No	No	Yes
Auto routing	Yes	No	No	No	No
API format	OpenAI	OpenAI	OpenAI	OpenAI	OpenAI

Every provider on this list is OpenAI-compatible. Switching between them is a base_url change.

Cost comparison for real workloads

Light usage (chatbot, ~3M tokens/month)

OpenRouter

$4.20/mo

Together AI

$3.60/mo

CheapestInference

from $5.94/mo (Core)

At very low volume, per-token is still slightly cheaper — but the Core pool ($6.99/mo month-to-month, unlimited DeepSeek V4 Flash and MiMo v2.5 during your block) closes the gap to a couple of dollars, and it stays flat no matter how much the chatbot grows.

Heavy usage (agents, ~300M tokens/month)

OpenRouter

$420/mo

Together AI

$360/mo

CheapestInference

from $44.20/mo

At agent-scale volume, a time-block subscription is dramatically cheaper. The gap grows with usage because per-token scales linearly and a reserved block is unlimited — it doesn’t scale at all.

When to use what

Stay on OpenRouter if: You need access to 200+ models, use auto-routing, and your monthly spend is under $50. The convenience premium is worth it at this scale.

Switch to Together/Fireworks if: You only use open-source models, care about latency, and want to avoid the reseller markup. Together and Fireworks serve models directly.

Switch to CheapestInference if: You run agents during predictable hours, want cost certainty, and the curated open-weight lineup covers your needs — Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 in the Frontier pool, or DeepSeek V4 Flash and MiMo v2.5 in the budget Core pool. Unlimited inference during a reserved time block beats per-token billing once your usage in those hours is heavy.

Use Groq if: Latency is your primary constraint and your model is in their catalog.

All five are OpenAI-compatible. Try each one with a base_url swap and see which fits.

CheapestInference serves a curated open-weight lineup across two pools — Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier); DeepSeek V4 Flash and MiMo v2.5 (Core) — through one OpenAI- and Anthropic-compatible API. Unlimited time-block subscriptions from $5.94/mo (Core) or $44.20/mo (Frontier), billed annually. See the pools or get started.

Self-hosted vs. API inference: the real cost comparison

Apr 15, 2026

“Why pay for an API when I can run the model myself?”

It’s a reasonable question. Open-source models are free. GPUs are available on every cloud. vLLM and Ollama make serving straightforward. The math should be simple: GPU cost per hour × hours = total cost. Done.

Except it’s not. The GPU is the minority of the cost. Here’s the full picture.

The visible costs

GPU hardware

Running DeepSeek V3.2 (671B MoE, ~130B active parameters) requires at least 4× A100 80GB or 2× H100 80GB in FP8. Qwen 3.5 397B has similar requirements.

Setup	Hourly	Monthly (24/7)	Monthly (8h/day)
4× A100 80GB (cloud)	$12.80	$9,216	$2,816
2× H100 80GB (cloud)	$8.40	$6,048	$1,848
1× A100 80GB (Llama 70B)	$3.20	$2,304	$704
1× L40S (Llama 8B)	$1.10	$792	$242

These are cloud GPU rental prices (AWS, GCP, Lambda Labs — varies by provider and availability). If you buy hardware, the upfront cost is $15K–$40K per GPU, amortized over 3–4 years, plus electricity, cooling, and data center costs.

Smaller models are cheaper — but limited

Running Llama 3.1 8B on a single L40S costs $242/month (8h/day). That’s competitive with API pricing. But 8B models can’t handle complex coding, multi-step reasoning, or nuanced analysis — the tasks where AI provides the most value.

The models worth self-hosting (70B+, MoE) require multi-GPU setups where the economics change dramatically.

The invisible costs

GPU rental is just the beginning.

1. Operations and maintenance

Someone has to:

Set up vLLM/TGI with optimal batch sizes, quantization, and memory allocation
Monitor GPU utilization and restart crashed processes
Update model weights when new versions release
Handle OOM errors, NCCL failures, and driver issues
Manage the serving infrastructure (load balancer, health checks, auto-scaling)

If this is a full-time DevOps engineer at $150K/year, that’s $12,500/month in labor. If it’s 20% of a senior engineer’s time, it’s $2,500/month. Either way, it’s more than the GPU.

2. Idle capacity

GPUs cost money whether they’re inferring or not. If your usage pattern is 8 hours of heavy use (work hours) and 16 hours of near-zero traffic, you’re paying for 24 hours and using 8.

Cloud spot instances help but introduce availability risk. Auto-scaling GPU clusters is possible but complex — model loading takes minutes, not seconds.

API pricing is purely usage-based. Zero requests = zero cost.

3. Multi-model overhead

Self-hosting one model is manageable. Self-hosting five models for different tasks — a coding model, a reasoning model, a fast classification model, an embedding model, and a vision model — requires either:

5 separate GPU instances (expensive)
Shared GPU with model swapping (slow — loading a 70B model takes 2–5 minutes)
A serving framework that handles multi-model routing (complex)

An API gives you access to many models through the same endpoint. No model loading, no GPU allocation, no routing logic.

4. Opportunity cost

Every hour your team spends on inference infrastructure is an hour not spent on your actual product. For startups, this is the most expensive cost of all — it doesn’t show up on any invoice.

Total cost of ownership

For a team of 5 developers running AI-assisted coding with a mix of DeepSeek V3.2 and smaller models:

Cost	Self-hosted	API (per-token)	API (time-block sub)
Compute/inference	$2,800	$265	$250
Ops/maintenance	$2,500	$0	$0
Idle waste (~60%)	$1,680	$0	$0
Total monthly	$6,980	$265	$250

Self-hosting costs 26x more for the same workload. The GPU is only 40% of the self-hosted cost — ops and idle waste are the majority.

When self-hosting makes sense

Self-hosting wins in specific scenarios:

Data sovereignty: If your data cannot leave your network — regulated industries, government, healthcare with strict compliance — self-hosting is the only option. No API provider can guarantee the data isolation you need.

Extreme scale: If you’re processing millions of requests per day and your GPUs are consistently at 80%+ utilization, the per-token math eventually favors owned hardware. This threshold is higher than most teams expect — typically $20K+/month in API spend before self-hosting breaks even.

Custom models: If you’ve fine-tuned a model and need to serve it, self-hosting or a dedicated inference provider (Fireworks, Together) is required. Most unified APIs don’t serve custom model weights.

Latency control: If you need guaranteed sub-100ms TTFT and your data center is co-located with your GPUs, self-hosting eliminates network hops.

For everyone else — startups, small teams, companies with variable usage patterns — the API is cheaper, faster to set up, and easier to maintain.

The migration path

Most teams don’t need to choose one forever. A practical approach:

Start with an API: Get your product working, validate demand, understand your usage patterns.
Optimize model selection: Use cheaper models for simple tasks, frontier models for hard tasks. Full guide: Multi-model architecture.
Evaluate self-hosting when: Your monthly API spend exceeds $10K, your GPU utilization would be >70%, and you have DevOps capacity to maintain it.
Hybrid: Self-host your high-volume models, use an API for long-tail models and overflow capacity.

The worst outcome is spending 3 months setting up GPU infrastructure before you’ve validated that anyone wants your product.

CheapestInference serves six open-weight models across two pools — Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier); DeepSeek V4 Flash and MiMo v2.5 (Core) — through a single API. No GPUs to manage, no idle costs, no ops burden. Reserve a daily 8-hour time block for unlimited usage from $5.94/mo (Core) or $44.20/mo (Frontier), billed annually — reserve all three blocks for full 24/7. Get started or see the pools.

The real cost of running AI agents in production

Apr 15, 2026

Chatbots are cheap. Agents are not.

A chatbot sends a user message, gets a response, displays it. Maybe 2,000 tokens per exchange. An agent reads files, calls tools, retries on errors, re-sends the entire conversation every step, and does this 20–60 times per task. Same API, completely different economics.

If you’re budgeting for AI agents the same way you budget for a chatbot, you’re underestimating by 10–50x.

Token consumption: chatbot vs. agent

We measured token consumption across three workload types, each running for one hour:

Coding agent (OpenClaw)

~2.1M tokens

Research agent (CrewAI)

~1.2M tokens

RAG chatbot

~200K tokens

Simple chatbot

~40K tokens

The coding agent consumed 52x more tokens than a simple chatbot in the same time period. And this is normal — the agent was doing useful work the entire time.

Why agents cost so much

Three architectural properties of agents make them expensive:

1. Context accumulation

Every agent step appends tool outputs to the conversation. The LLM re-processes the entire conversation on each step. If the agent reads a 3,000-token file at step 5, that file gets re-sent at steps 6, 7, 8… all the way to the end.

For a 40-step task, one file read costs: 3,000 tokens × 35 remaining steps = 105,000 tokens in re-transmission.

This is why agent token consumption grows quadratically, not linearly.

2. System prompt overhead

Agent frameworks use large system prompts — OpenClaw’s is ~9,600 tokens, CrewAI’s varies by agent configuration. This prompt is sent with every request. Over 40 steps, the system prompt alone costs 384,000 tokens.

3. Error retry loops

When a tool call fails, the agent retries. Each retry sends the full context plus the error message. Three retries on a 30K-token context wastes 90K tokens with no productive output.

Without a retry cap, this can run indefinitely — always bound agents with a retry cap and a maximum iteration count.

Monthly cost by model and framework

Assuming one developer running 15 agent tasks per day, 22 working days per month, ~500K tokens per task (80% input / 20% output, at each vendor’s list price — live prices here):

Model	Cost/task	Daily (×15)	Monthly
Claude Fable 5	$9.00	$135.00	$2,970
GPT-5.5	$5.00	$75.00	$1,650
Claude Opus 4.8	$4.50	$67.50	$1,485
GLM 5.2 (open)	$1.00	$15.00	$330
DeepSeek V4 Flash (open)	$0.08	$1.26	$28
CheapestInference (full day)	—	—	from $44.20/mo flat

A team of 5 developers each running 15 tasks/day on Claude Fable 5 spends $14,850/month. The same team on flat-rate via CheapestInference pays a fixed monthly subscription per seat (from $44.20/mo for a reserved daily time block) — no matter how many tokens those agents burn. That’s an order-of-magnitude reduction.

Four strategies to cut agent inference costs

1. Switch to open-source models

Open-weight models like Kimi K2.6 and MiniMax M3 now sit at parity with Gemini 3.1 Pro on SWE-bench Verified, and GLM 5.2 outscores GPT-5.5 on SWE-bench Pro — at a half to a sixth of the per-token price. Full data: the Which-LLM guide and the State of Open Weights report.

2. Route by task complexity

Not every agent step needs a frontier model. File reads, simple classifications, and formatting don’t need 685B parameters. Use a small model for easy steps and a large model for hard ones. Full guide: Building a multi-model architecture.

3. Give each agent its own key

Give each agent its own API key so one runaway agent can’t starve the others. On a time-block subscription each key gets unlimited usage during its reserved hours, so you isolate workloads without juggling per-token allocations.

4. Use flat-rate pricing

Per-token pricing penalizes the exact patterns agents use: large contexts, many steps, retries. Flat-rate pricing makes all of that free. During your reserved time blocks your agent can use the full context window and retry freely without increasing the bill — reserve all three blocks for 24/7 coverage.

The math that matters

Here’s the equation most teams miss:

Agent cost = tokens_per_step × steps × cost_per_token

Most optimization focuses on cost_per_token — switching to a cheaper model. But tokens_per_step grows with context (quadratic), and steps is unpredictable. Optimizing only one variable leaves the other two working against you.

Flat-rate pricing eliminates all three variables from your bill. The cost is the subscription. Period.

We serve six open-weight models across two flat-rate pools — Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 in the Frontier pool (from $44.20/mo), DeepSeek V4 Flash and MiMo v2.5 in the Core pool (from $5.94/mo) — with unlimited time-block subscriptions: no token counting, no budget caps during your reserved hours. Reserve 1–3 daily 8-hour blocks and your agent’s token consumption never becomes your problem. Get started or see plans.

OpenClaw is free. Running it is not.

Mar 24, 2026

OpenClaw has 247,000 GitHub stars. It’s free, open-source, and runs locally. You install it, point it at an LLM, and it writes code, browses the web, queries databases, and executes files on your behalf.

The agent is free. The inference is not.

Every time OpenClaw calls a model, it re-sends the entire conversation history — every tool output, every file it read, every intermediate result. By iteration 20 of a typical task, the input context is 30,000+ tokens. By iteration 40, it’s past 100,000. And it sends this every single request.

This is not a bug. It’s how agents work. And it’s why running OpenClaw on pay-per-token APIs costs $300–600/month for active users — sometimes more.

Where the tokens go

We broke down token consumption for a typical OpenClaw coding task: “add authentication to an Express API.” The agent completed it in 38 tool calls.

Context accumulation

~280K tokens

System prompt (×38)

~156K tokens

Tool outputs (files, etc.)

~70K tokens

Agent output

~19K tokens

Total: ~525,000 tokens for a single task. The agent’s actual output — the code it wrote — was 19K tokens. The other 96% is overhead.

On Claude Opus at $15/M input + $75/M output, that single task costs $9.18. Run five tasks a day and you’re at $1,377/month.

On DeepSeek V3.2 via a pay-per-token provider at $0.27/M input + $1.10/M output, the same task costs $0.16. Better — but 20 tasks a day is still $96/month, and that’s one agent.

The three cost traps

Here’s the OpenClaw-specific version:

1. Context grows quadratically

OpenClaw reads files into context. If it reads a 2,000-token file at step 5, that file gets re-sent at steps 6, 7, 8… all the way to 38. That single file read costs 2,000 × 33 remaining steps = 66,000 tokens in re-transmission alone.

Users report session contexts at 56–58% of the 400K context window during normal use. This isn’t a failure mode — it’s the architecture working as designed.

2. System prompt is a fixed tax

OpenClaw’s system prompt is ~9,600 tokens. It gets sent with every request. Over 38 tool calls, that’s 365K tokens just in system prompts. You pay this whether the agent does useful work or not.

3. Wrong model for the job

OpenClaw defaults to a single model for everything. But not every tool call needs the same intelligence:

Reading a file and deciding what to edit? Llama 3.1 8B handles this at 200 tokens/sec.
Writing complex authentication logic? A frontier open-weight model like Kimi K2.7 is the right call.
Formatting a config file? Any 8B model is overkill but still cheaper than Opus.

We wrote a full guide on this pattern: Building a multi-model architecture. Routing agent requests to the right model can cut costs by 60–80% without reducing output quality.

The math on flat-rate vs. pay-per-token

Here’s the comparison for an OpenClaw user running ~20 tasks/day:

Provider	Cost/task	20 tasks/day	Monthly
Claude Opus (direct)	$9.18	$183.60	$5,508
GPT-5.4 (direct)	$4.73	$94.60	$2,838
DeepSeek V3.2 (per-token)	$0.16	$3.20	$96
CheapestInference (flat-rate)	—	—	from $5.94/mo (Core) · $44.20/mo (Frontier)

Flat-rate means you don’t care about context accumulation. The 280K tokens of context overhead that makes pay-per-token expensive? Irrelevant. The system prompt tax? Doesn’t matter. Your agent can call models 24/7 and the bill is the same.

If you’re running OpenClaw, here’s the setup we see working best:

1. Use open-weight models. Frontier open-weight models like Kimi K2.7 and GLM 5.2 score within a few points of proprietary models on coding benchmarks (the data). The gap doesn’t justify a 50x cost difference.

2. Route by complexity. Don’t send file reads and simple decisions to the same model as complex code generation. A router model costs fractions of a cent per classification. Full guide: Multi-model architecture.

3. Reserve the hours you work. On CheapestInference you subscribe to a pool and reserve one or more daily 8-hour time blocks (Asia-Pacific, Europe, Americas — pick 1–3, all three is full 24/7). The Frontier pool (from $44.20/mo billed annually) carries Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3; the Core pool (from $5.94/mo) carries DeepSeek V4 Flash and MiMo v2.5 — both 1M-context models that handle everyday OpenClaw tasks for the price of a coffee. During your reserved hours inference is unlimited with no budget cap. One API key per agent, one request at a time per key. Outside your window, requests return 429 until your block opens again.

4. Handle rate limits automatically. Time blocks mean your agent will hit 429s outside your reserved window — that’s expected. But OpenClaw kills the conversation when it gets a 429. The agent stops, and if you close the dashboard, that conversation is gone.

We built an OpenClaw plugin that fixes this: openclaw-ratelimit-retry. It hooks into agent_end, detects retriable 429s, parks the session on disk, and waits for the budget window to reset. Then it sends chat.send to the original session — resuming the conversation with its full transcript, as if you had typed a message.

openclaw plugins install @cheapestinference/openclaw-ratelimit-retry

plugins:
  ratelimit-retry:
    budgetWindowHours: 8    # matches your CheapestInference 8-hour time block
    maxRetryAttempts: 3     # give up after 3 consecutive 429s
    checkIntervalMinutes: 5 # check every 5 min for ready retries

The plugin is zero-dependency, persists across server restarts, deduplicates by session, and handles edge cases like sub-agents, queue overflow, and corrupted state files. If the retry itself hits a 429, it re-queues automatically. No tokens wasted on re-sending from scratch — the agent picks up exactly where it left off.

This turns budget caps from “your agent crashes” into “your agent naps and wakes up.” Set it up once and forget about it.

5. Consider unlimited time blocks. If your agent runs more than a few tasks per day, per-token pricing works against you. Every token of context overhead is money. With an unlimited time-block subscription, context overhead is free during your reserved hours — re-send the full window, let the agent work without a budget cap.

The irony

OpenClaw is free because the code runs on your machine. But the valuable part — the intelligence — runs on someone else’s GPUs. The agent framework is the cheap part. Inference is the expensive part.

Open-source models on flat-rate infrastructure flip this equation. The models are free. The inference is flat. The only variable cost left is your time.

Point your OpenClaw base_url at https://api.cheapestinference.com/v1 and find out what unconstrained agents actually cost: nothing more than you already budgeted.

pricing

Two rules, and that’s it

Allowances stay separate

It works across pools

One credential per subscription

Creating one

Route 1: the official Qwen Coding Plan

Route 2: per-token APIs

Route 3: unlimited time blocks on comparable open-weights models

The three routes at a glance

When to use what

Route 1: the official Kimi coding plan

Route 2: per-token APIs

Route 3: unlimited time blocks

When to use what

Route 1: the official Z.ai coding plan

Route 2: per-token APIs

Route 3: unlimited time blocks

When to use what

The math nobody runs until the invoice arrives

What you get with the subscription

When per-token DeepSeek is still the right call

Two ways to buy inference

The fat-tail problem

The math

What bounded COGS buys your product

What the seat model asks of you

When the meter is still right

Running it in practice

What OpenRouter does well

Where OpenRouter gets expensive

The alternatives

Together AI

Fireworks

Groq

CheapestInference

Side-by-side comparison

Cost comparison for real workloads

Light usage (chatbot, ~3M tokens/month)

Heavy usage (agents, ~300M tokens/month)

When to use what

The visible costs

GPU hardware

Smaller models are cheaper — but limited

The invisible costs

1. Operations and maintenance

2. Idle capacity

3. Multi-model overhead

4. Opportunity cost

Total cost of ownership

When self-hosting makes sense

The migration path

Token consumption: chatbot vs. agent

Why agents cost so much

1. Context accumulation

2. System prompt overhead

3. Error retry loops

Monthly cost by model and framework

Four strategies to cut agent inference costs

1. Switch to open-source models

2. Route by task complexity

3. Give each agent its own key

4. Use flat-rate pricing

The math that matters

Where the tokens go

The three cost traps

1. Context grows quadratically

2. System prompt is a fixed tax

3. Wrong model for the job

The math on flat-rate vs. pay-per-token

What we’d actually recommend

The irony