Kimi K2.7 Code vs GLM-5.2: Cheaper Per Agent Run? (2026)

TL;DR. Per token, Kimi K2.7 Code (moonshotai/kimi-k2.7-code) is cheaper than GLM-5.2 (z-ai/glm-5.2) on every axis: $0.95 vs $1.40 input, $4.00 vs $4.40 output, $0.19 vs $0.26 cache read on ofox.ai. But “cheaper per token” and “cheaper per agent run” are not the same number. On a typical run (50K input, 20K output, no cache) Kimi costs $0.1275 vs GLM’s $0.1580, so 19.3% cheaper. That margin shrinks as cache hit climbs, and it depends on how many tokens each model actually burns to finish the task. Both are open-weight and both are one string swap apart on ofox.ai.

The sticker price says Kimi wins. The invoice is more complicated, because run cost is price times tokens consumed, and the second half of that product is workload-specific. This post gives the verified prices, a worked per-run example, and the honest boundary: where I can compute the answer, and where you have to measure it on your own traffic.

TL;DR: Which One Should You Pick?

The honest verdict: for coding agent runs that fit in 256K of context, route the cost-sensitive default to moonshotai/kimi-k2.7-code. Keep z-ai/glm-5.2 for jobs that genuinely need the 1M window in a single call. The per-token gap favors Kimi everywhere; the per-run gap favors Kimi at most realistic mixes but narrows with cache, so the split above is where the money actually moves.

Quick Specs Comparison

Prices are ofox.ai gateway rates, USD per million tokens, read off the model catalog on July 16, 2026. Specs are from the Hugging Face model cards.

Two things to pull off this sheet before the math. Kimi is cheaper on all three billed axes, so any workload will pay less per token on Kimi. And the context windows are not close. GLM-5.2’s 1M is roughly 4x Kimi’s 256K, and that single spec is the main reason the per-run answer is not just “Kimi, always.” A prompt that overflows 256K has to be chunked and re-sent on Kimi, and repeated input tokens are exactly where Kimi’s discount lives, so a big enough single-context job can claw the gap back toward GLM.

On ofox only the text-only Code variant of Kimi is served, so this is a code-and-text comparison, not a multimodal one. If your agent needs to attach screenshots or diagrams, neither of these two is the model for that leg of the pipeline.

Per-Token vs Per-Run: The Distinction That Trips People Up

The mistake is reading a price table as a run comparison. Run cost is:

run_cost = (input_tokens × input_price)
         + (cached_input_tokens × cache_price)
         + (output_tokens × output_price)

The prices are fixed and verified. The token counts are not fixed. They depend on your prompt size, how much of the input hits cache, and how many output tokens the model emits to finish the job. Kimi wins the price half of every term. The token half is where a “cheaper” model can still lose a specific run, if it burns more tokens getting there.

Here is the per-axis picture, which is the ceiling on how much Kimi can win:

Notice the imbalance. Kimi’s biggest edge is on input (32% cheaper) and cache (27% cheaper). On output it is only 9% cheaper. So the shape of a run decides how much of that edge you actually collect. Input-heavy runs collect the big discount. Output-heavy runs collect the small one. And caching, counterintuitively, works against Kimi’s relative advantage, because a cached input token costs $0.19 instead of $0.95, which shrinks the very line item where Kimi was 32% ahead.

Worked Example: A Typical Agent Run

Take one concrete agent run and compute both invoices. The shape below is a reasonable single-task coding run: read a chunk of context, reason, emit a patch.

The run I hold fixed for both models:

• 50,000 input tokens (a few files of context plus instructions)
• 20,000 output tokens (reasoning plus the emitted diff)
• Cache handled separately below, starting with no cache

I have no first-party benchmark of how many tokens each model consumes to finish an identical task, so I hold the token counts equal across both models and vary only the price. That isolates the price effect cleanly. It also means these numbers answer “if both models emit the same tokens, who is cheaper,” not “who finishes the task in fewer tokens.” The second question needs measurement, and I flag it explicitly at the end.

At $0.03 a run the absolute number looks trivial. It stops looking trivial at volume. A single coding agent hammering 1,000 runs a day at this shape:

Nine hundred dollars a month, on one workload shape, from a one-string routing change. That is the case for defaulting cost-sensitive traffic to Kimi.

Cache Impact: The Margin Shrinks as Cache Climbs

Code-review agents and multi-turn sessions re-send the same repo context on every call, so a large fraction of input hits cache. Both models bill cache reads below full input rate. Here is the same 50K-in / 20K-out run at rising cache hit rates.

Kimi stays cheaper at every point, but the margin drops from 19.3% to 13.6% as cache climbs. The reason is structural. Kimi’s largest discount is on full-price input (32% cheaper). Caching converts full-price input into cache-price input, where Kimi is only 27% cheaper, and it shrinks the whole input line item toward zero. What is left is mostly output, where Kimi’s edge is a thin 9%. So the more you cache, the more your run cost is dominated by output, and the less Kimi’s input advantage matters.

The practical read: if your workload is a high-cache code-review loop, both models are close, and the tiebreaker is more likely output quality or the 256K-vs-1M context ceiling than the per-run price. If your workload is low-cache, fresh-context generation, Kimi’s discount lands closer to its full 19%.

Mix Sensitivity: How the Ratio Moves With Input-to-Output Shape

Cache is one lever. The other is the raw input-to-output ratio, independent of caching. Blend the per-token prices at three common workload shapes and the Kimi advantage moves in a predictable direction.

The trend is the mirror image of the cache trend. Input-heavy runs collect Kimi’s fat 32% input discount, so the advantage widens toward 20%. Output-heavy runs lean on the thin 9% output discount, so the advantage narrows toward 11%. Kimi is cheaper at every shape, but a summarization agent that reads a large file and emits a two-line answer saves more, proportionally, than a scaffolding agent that reads a short prompt and emits a large file.

Put the two levers together and the picture is: Kimi’s per-run edge is largest on input-heavy, low-cache runs, and smallest on output-heavy, high-cache runs. Neither combination flips the ranking. Both just move the size of the win between roughly 11% and 20%.

Scaling the Bill: What the Ratio Costs at Volume

The per-run difference is cents. The reason it is worth a routing decision is that agent fleets do not run one job. Here is the typical 50K-in / 20K-out run scaled across three volume tiers, no cache, so you can locate your own spend.

The 19.3% gap holds at every tier because it is a property of the run shape, not the volume. Only the absolute spend scales. At a thousand runs a day the savings pays for a monitoring tool. At a hundred thousand runs a day it pays for a small team. Where your fleet sits on that table is where the model choice stops being a rounding error.

The Token-Consumption Wildcard (What I Can’t Measure)

Everything above holds token counts equal between the two models. That is a deliberate simplification, and it is the load-bearing caveat of this whole comparison.

Run cost is price times tokens. I have verified the price. I have not measured the tokens, because there is no published first-party benchmark of how many input, thinking, and output tokens each of these two models consumes to complete an identical agent task. Anyone quoting you a “Kimi finishes in 15% fewer tokens” number without a reproducible harness is guessing.

Here is why it matters, as a break-even, not a benchmark:

On the 50K-input run, GLM-5.2 costs $0.1580 total. Kimi’s input for 50K is $0.0475, which leaves $0.1105 of budget before it ties GLM. At $4.00/M output, that budget buys about 27,600 output tokens. So Kimi can emit roughly 1.38x more output than GLM’s 20,000 and still cost the same or less.

Flip that around: if GLM-5.2 tends to finish a given task in meaningfully fewer output tokens than Kimi, its higher per-token price can be partly or fully offset on that task. The per-token winner is not automatically the per-run winner once you let the models emit different token counts. Kimi has ~38% of headroom on this run shape before the price advantage flips, which is a comfortable buffer, but it is a buffer, not infinity.

One more wrinkle sits inside the output number. Both models emit thinking tokens, and thinking tokens bill as output. Kimi K2.7 Code is a thinking model, and Moonshot has documented a reduction in thinking-token volume on this generation relative to the prior one, which is its own cost story covered in the token-cut analysis. For a cross-model comparison it means the “output tokens” line is not just the visible answer, it is answer plus reasoning, and the split differs by model and by task difficulty. A model that reasons more to reach the same answer pays more on output even at a lower output price. That is another reason the token-consumption half of the equation has to be measured, not assumed.

The only honest way to close this gap is to run both models on your real tasks and read resp.usage off each response. The A/B loop below prints exactly that.

Decision Flow: Which Model for Which Run

flowchart TD
    A[New agent run] --> B{Input over 256K tokens?}
    B -->|Yes| C[GLM-5.2: needs the 1M window]
    B -->|No| D{Measured token gap favors GLM?}
    D -->|Yes| E[GLM-5.2: fewer output tokens offset price]
    D -->|No, or unmeasured| F{Vision or multimodal needed?}
    F -->|Yes| G[Route to a vision model, not these two]
    F -->|No| H[Kimi K2.7 Code: cheaper per run under 256K]

The flow encodes the whole argument: context ceiling first, measured token behavior second, modality third, and Kimi as the cost default for everything that falls through. The one branch most teams skip is the middle one, because they never run the A/B and never learn whether GLM finishes their tasks in fewer tokens. Skipping it usually favors Kimi anyway, given the ~38% output headroom, but it is worth an hour to confirm.

When to Pick Kimi K2.7 Code

Three cases where Kimi is the clear per-run pick:

1. Runs that fit inside 256K context. Most single-task coding runs are well under 256K. Inside that window Kimi is cheaper on every token, so it is cheaper per run at every mix, most decisively on input-heavy jobs where the 32% input discount lands in full.
2. Output-heavy generation with fresh context. Scaffolding, test generation, codemod application. Low cache reuse means the full input discount applies, and even the thin 9% output edge compounds across thousands of runs.
3. Cost-defaulted agent fleets. If you route a high volume of routine agent runs and escalate only the hard cases elsewhere, Kimi as the default line item is $915/month cheaper per 1,000-run-per-day workload on the shape modeled above.

The Modified MIT license adds a fourth, softer reason. If Moonshot changes hosted pricing later, the weights give you a self-host fallback on the same model. That option has value even if you never exercise it, because it caps your exposure to a future price move. The same logic applies to GLM-5.2 under plain MIT, so open-weight availability is not a tiebreaker between these two, but it is a real difference against any closed API you might otherwise default to.

When to Pick GLM-5.2

Two cases where the pricier-per-token model can be the better per-run choice:

1. Whole-repo prompts above 256K. GLM-5.2’s 1M context is roughly 4x Kimi’s. A prompt that overflows 256K must be chunked and re-submitted on Kimi, and each chunk re-sends overlapping input. Repeated input tokens are billed again, which is exactly where Kimi’s discount was, so a large enough single-context job can neutralize or reverse the per-token gap. If your job genuinely needs 1M in one call, GLM does it natively and Kimi cannot.
2. You have measured a token-consumption gap. If your own A/B shows GLM finishing your specific tasks in enough fewer output tokens to overcome its 4.4-vs-4.0 output price, believe your data over this table. The break-even is ~1.38x output headroom on the run shape above; workloads that beat it favor GLM.

Both cases share a theme: they are the situations where the token half of the cost equation overrides the price half. The 1M context case is a hard override, since a job that does not fit in 256K simply cannot run on Kimi in one call, and chunking multiplies the input tokens you pay for. The measured-gap case is a soft override that only exists if you have real data. Absent that data, the price half wins, and the price half points at Kimi. That is the asymmetry worth remembering: to justify GLM on cost you need a specific reason, whereas Kimi is the cost default that needs no justification beyond the rate card.

When Neither Is the Right Call

If your agent needs vision (screenshots, diagrams, PDF pages), the text-only Kimi Code variant on ofox cannot do it, and GLM-5.2’s cost edge is irrelevant to a job it also is not built to lead on. Route the multimodal leg to a vision model and keep these two for the text-and-code work. For the broader routing pattern across the ofox catalog, including where a Claude model earns the escalation, see the GLM-5.2 vs GPT-5.5 cost breakdown, which works through the same per-token-versus-per-bill logic at higher price points.

Try Both via ofox: A/B in One Loop

Both moonshotai/kimi-k2.7-code and z-ai/glm-5.2 are live on https://api.ofox.ai/v1 under the OpenAI-compatible protocol. The model swap is a single string. This is the harness that actually answers the token-consumption question the tables above can’t.

Python: A/B both models and read token usage

from openai import OpenAI
import os, time

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.environ["OFOX_API_KEY"])

prompt = "Refactor this module for async I/O and add early returns on empty input: ..."

for model in ["moonshotai/kimi-k2.7-code", "z-ai/glm-5.2"]:
    t0 = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    dt = time.time() - t0
    u = resp.usage
    print(f"{model}: {dt:.1f}s  in={u.prompt_tokens} out={u.completion_tokens}")

The prompt_tokens and completion_tokens fields are the missing half of the cost equation. Multiply them by the verified prices and you get the real per-run cost on your task, not the equal-token approximation from the tables above. Run it across 20 to 30 representative cases from your actual workload before you commit a routing default.

Node: same shape

import OpenAI from "openai";

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

const prompt = "Refactor this module for async I/O and add early returns on empty input: ...";

for (const model of ["moonshotai/kimi-k2.7-code", "z-ai/glm-5.2"]) {
  const t0 = Date.now();
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  const u = resp.usage;
  console.log(`${model}: ${(Date.now() - t0) / 1000}s in=${u.prompt_tokens} out=${u.completion_tokens}`);
}

Production routing: single-line model swap

Once you have your own token numbers, the production routing is one function. Default the cost-sensitive traffic to Kimi, send the over-256K jobs to GLM:

def pick_model(input_tokens: int) -> str:
    if input_tokens > 256_000:
        return "z-ai/glm-5.2"        # needs the 1M window
    return "moonshotai/kimi-k2.7-code"  # cheaper per run under 256K

resp = client.chat.completions.create(
    model=pick_model(estimated_input_tokens),
    messages=messages,
)

Same key, same endpoint, same billing line. The model column on your ofox invoice tells you what each request cost, so you can validate the split against real spend after a week. For related Kimi cost work, see whether a 30% thinking-token cut actually lowers your K2.7 bill and the free and zero-cost Kimi K2.7 Code paths.

FAQ

Is Kimi K2.7 Code cheaper than GLM-5.2 per token? Yes, on every axis. Kimi is 32% cheaper on input ($0.95 vs $1.40/M), 9% cheaper on output ($4.00 vs $4.40/M), and 27% cheaper on cache reads ($0.19 vs $0.26/M).

Does that make it cheaper per agent run? At most realistic workload shapes, yes, but the margin varies. A 50K-in / 20K-out run is 19.3% cheaper on Kimi with no cache, 13.6% cheaper at 80% cache hit. The savings shrink as cache climbs because Kimi’s biggest discount is on full-price input.

Could GLM-5.2 ever be cheaper per run? Yes, two ways. If a job overflows Kimi’s 256K context and has to be chunked, repeated input tokens can erase the discount. And if GLM finishes your specific task in enough fewer output tokens, its higher output price can be offset. Measure token consumption on your own tasks to know.

What is the context window difference? Kimi K2.7 Code is 262,144 tokens (256K). GLM-5.2 is 1,048,576 tokens (1M), roughly 4x larger. That gap is the main reason the per-run answer is not “Kimi, always.”

Are both open-weight? Yes. Kimi K2.7 Code ships under a Modified MIT license, GLM-5.2 under MIT. Self-hosting is a fallback against future hosted price changes, though it adds GPU and operations cost.

References

• ofox.ai model catalog: moonshotai/kimi-k2.7-code
• ofox.ai model catalog: z-ai/glm-5.2
• Kimi K2.7 Code model card (Hugging Face)
• GLM-5.2 model card (Hugging Face)
• GLM-5.2 vs GPT-5.5 cost breakdown
• GLM-5.2 access guide
• Kimi K2.7 Code token-cut bill analysis
• Kimi K2.7 Code free and zero-cost paths