First, a disambiguation for the search engines: this is about MiMo, Xiaomi’s open-weights large language model — not MIMO antenna technology. If you came here for multipath radio, wrong blog.
MiMo v2.5 is the model Xiaomi’s LLM lab ships as its fast, efficient workhorse: small enough to be quick and cheap to run, with a ~1M-token context window that puts it in a class usually reserved for much more expensive models. It’s open weights, and — unlike most of the open-weights catalog — very few providers serve it over an API at all.
MiMo v2.5 is not a frontier reasoning model, and pretending otherwise helps nobody. Where it earns its keep:
Long-context work on a budget. Feed it an entire codebase, a contract stack, or weeks of chat logs in one request. Most tasks over long inputs are retrieval-and-synthesis, not deep reasoning — exactly the regime where a fast model with 1M context beats a smarter model with 128K.
High-volume agent plumbing. Sub-agents, summarizers, extractors, classifiers — the loops that run hundreds of times a day and quietly dominate token bills.
Drafting and iteration speed. It’s fast. For inner-loop coding assistance, latency often matters more than the last few points of benchmark quality.
For frontier-tier reasoning, use a frontier-tier model — that’s what the Frontier Pool is for. MiMo’s job is to make the other 80% of your token volume cost almost nothing.
MiMo v2.5 is served in the Core Pool alongside DeepSeek V4 Flash, on unlimited time-block subscriptions — flat monthly fee, no per-token billing. One curl:
"messages": [{"role": "user", "content": "Summarize the attached spec..."}]
}'
It speaks both the OpenAI and Anthropic API shapes, so it also works as a model in Claude Code, Cline, or any OpenAI-compatible client — set model id mimo-v2.5. Full details on the MiMo v2.5 model page.
Because the interesting frontier in 2026 isn’t only “smartest model” — it’s capability per dollar at volume. A subscription covers every model in its pool, so the practical pattern is: route the hard 20% to a frontier model, and everything else to a model like MiMo where unlimited usage costs a flat few dollars a month. Your effective blended cost drops without touching quality where quality matters.
CheapestInference serves DeepSeek V4 Flash and MiMo v2.5 (Core Pool, from $12.74/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.
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.
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.
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.
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.
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.
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.
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.
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 $48.45/mo), DeepSeek V4 Flash and MiMo v2.5 in the Core pool (from $12.74/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.
It’s 11pm. Claude Code is 40 minutes into a refactor, tests are half-green, and then the terminal prints:
5-hour limit reached ∙ resets 3am
The agent stops. The session sits there. If you go to bed, nothing happens at 3am — the limit resets, but nobody is around to type “continue”. You lose the hours between the reset and whenever you come back.
We got tired of this, so we built claude-auto-retry: a small open-source tool that watches your Claude Code session, parses the reset time out of the limit message, waits for it, and resumes the session automatically. You run claude exactly like before. That’s the whole pitch.
Claude subscriptions meter usage in rolling windows. Heavy Claude Code use — long agent runs, big contexts, lots of tool calls — burns through a window fast, and when it’s gone you get a variant of:
5-hour limit reached ∙ resets 3pm
You've hit your limit · resets 3pm
Claude usage limit reached. Resets at 2pm
The limit itself is fine — it’s how a fixed-price subscription stays fixed-price. The annoying part is what happens after: Claude Code doesn’t queue your work and resume at the reset. It just stops, mid-task, holding all the context of whatever it was doing. Resuming costs one word — “continue” — but only if a human is there to type it.
For interactive use that’s a coffee break. For the way people increasingly use Claude Code — overnight runs, long autonomous tasks, claude -p in scripts — it’s a silent halt that wastes every hour between the reset and your return.
A cron job that types “continue” at a fixed time. Blind. The reset time moves with your usage, so you either fire too early (message goes nowhere, session still limited) or too late (hours lost anyway). And if Claude exited, you’re injecting keystrokes into a bare shell.
Wrapper scripts around the CLI. Most break something: interactive mode, claude -p piping, or they lose the session when your terminal disconnects.
The failure modes all reduce to the same two hard parts: knowing when the limit actually resets, and injecting “continue” safely into a live session — including after you’ve closed your laptop.
The tool leans on tmux for session persistence, but hides it completely:
Transparent wrapping. The installer adds a shell function so claude transparently runs inside a tmux session. If you’re already in tmux, it uses your pane. You won’t notice the difference — interactive use, flags, and claude -p "prompt" | jq all work as before.
Background monitoring. A separate process polls the pane every 5 seconds looking for the known limit-message patterns (customizable if Anthropic changes the wording).
Real reset-time parsing. When a limit hits, it parses the actual reset time from the message — timezone-aware and DST-safe — computes the wait, and sleeps until reset plus a small safety margin. No guessed schedules.
Safe injection. Before sending “continue”, it verifies Claude is still the foreground process in the pane. If Claude exited, nothing gets typed into your shell.
Survives disconnects. Because the session lives in tmux, you can close the terminal, drop SSH, or shut the laptop lid. The monitor keeps waiting server-side; reattach whenever and the run has continued without you.
Separately from usage limits, it also catches transient API errors (429, 5xx, 529 overloaded) and retries those with exponential backoff — a different failure with a different fix, handled by the same monitor.
It’s pure Node.js with zero npm dependencies, MIT-licensed, and logs everything it does to ~/.claude-auto-retry/logs/.
The installer adds the shell function to ~/.bashrc or ~/.zshrc and installs tmux if it’s missing (apt, dnf, brew, pacman, apk). Then use Claude Code exactly as always:
Terminal window
claude
When a limit hits, you’ll see the monitor take over. Check on it with:
Terminal window
claude-auto-retrystatus# what it's waiting for, and until when
claude-auto-retrylogs# what it has done
Retry counts, the wait margin, and custom detection patterns live in ~/.claude-auto-retry.json if you want to tune them. Needs Node.js ≥ 18; tested on Ubuntu, CentOS, macOS, Arch, and Alpine.
We first shared the tool on r/ClaudeAI — the discussion there is a decent picture of how many people hit this exact wall.
claude-auto-retry makes limits painless when the work can wait a few hours. Some workloads can’t — always-on agents, batch jobs, anything that has to keep moving at 4am.
Claude Code speaks the Anthropic Messages API, which means it can point at any compatible endpoint — including ours. CheapestInference serves open-weight models across two pools (Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 in the Frontier pool; DeepSeek V4 Flash and MiMo v2.5 in the budget Core pool) through an Anthropic-compatible endpoint, with a different limits model: you reserve daily 8-hour time blocks, and during your reserved hours inference is unlimited — there is no usage-limit message to parse, because there is no rolling cap to hit.
The two approaches compose. Plenty of people keep their Claude subscription for interactive work and run the long unattended stuff — the runs that would otherwise die at 11pm — on an open-weight model during a reserved block. Open-weight coding models are closer to frontier than most people assume; here’s the current evidence.
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.
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.
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.
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’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.
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 ($57–$61/mo per block, from $48.45/mo billed annually) carries Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3. The Core pool ($14.99/mo per block, from $12.74/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.
At very low volume, per-token is still slightly cheaper — but the Core pool ($14.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.
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.
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 $12.74/mo (Core) or $48.45/mo (Frontier), billed annually. See the pools or get started.
“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.
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.
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.
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.
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.
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.
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.
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.
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 $12.74/mo (Core) or $48.45/mo (Frontier), billed annually — reserve all three blocks for full 24/7. Get started or see the pools.
