Blog

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 per-token from Moonshot and the aggregators. 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:

Kimi K2.7 under one flat fee. A Frontier Pool block covers Kimi K2.7 (model id kimi-k2.7), alongside GLM 5.2 and MiniMax M3, switchable per request. (Kimi K2.6 was retired from the pool in July 2026 — K2.7 is its direct successor; if you need K2.6 specifically, Route 2 still covers it per-token.)
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 three 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, K2.7 plus two more frontier models under one fee.

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

CheapestInference serves Kimi K2.7, 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.

DeepSeek subscription: what unlimited flat-monthly access changes

Jul 6, 2026 - Last update: Aug 1, 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?

Update (Aug 2026): DeepSeek retrained V4 Flash — the 0731 build posts large agent-benchmark gains at the same price, which strengthens every number below. What changed in V4-Flash-0731 →

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: ..."}],
)

Common questions

Is there a DeepSeek subscription? Not from DeepSeek itself — their first-party API is pay-per-token (with peak/off-peak and cache discounts, but no flat plan). CheapestInference sells a flat-monthly DeepSeek subscription: unlimited DeepSeek V4 Flash (the 0731 build) during your reserved daily 8-hour blocks, plus MiMo v2.5 in the same Core Pool.

How much does a DeepSeek subscription cost? From $14.99/month per 8-hour daily block ($12.74/mo billed annually), up to full 24/7 coverage — live pricing on /pools. No token caps during your hours.

Does the subscription include the latest DeepSeek model? Yes — the pool serves the current V4 Flash build under the stable model id deepseek-v4-flash; when DeepSeek retrained it (V4-Flash-0731, July 2026), subscribers got the new build with no migration.

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 $12.74/mo billed annually) and Kimi K2.7, 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.

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 and MiniMax M3 (1M context) too, switchable per request. If GLM is your main model but not your only one, that’s three 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, and MiniMax M3 (Frontier Pool, from $48.45/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.

Xiaomi's MiMo v2.5: the 1M-context model almost nobody is serving

Jul 6, 2026

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.

What it’s actually good at

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.

The fastest way to try it

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:

curl https://api.cheapestinference.com/v1/chat/completions \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mimo-v2.5",
    "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.

Why serve it at all?

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.

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 five open-weight models across two flat-rate pools — Kimi K2.7, 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.