# Kimi API Pricing in 2026 and Cost per 1,000 Tasks

By Femi Adegoke · 2026-10-21 · Source: https://www.activepieces.com/blog/kimi-api-pricing-in-2026-and-cost-per-1-000-tasks

---
<aside class="tldr"><p class="tldr-label">Summary</p><p>Kimi K3 costs $15 per 1M output tokens, which translates to $4.50 per 1,000 tasks with 300 output tokens each.</p><ul><li>A 300-token step costs $4.50 per 1,000 runs on K3, nearly four times K2.6's cost.</li><li>A translation task bills 10,816 reasoning tokens, more than eight times the 1,291 output.</li><li>Cached input costs $0.30 per 1M tokens, K3's uncached input costs $3.00 per 1M.</li></ul></aside>

[Kimi](https://www.kimi.ai/help/kimi-api/api-pricing)'s API is pay-as-you-go, billed per million tokens, and the current flagship, K3, costs $15 per 1M output tokens according to [BenchLM](https://benchlm.ai/moonshot/api-pricing).

Output's the meter that grows fastest, even in a workflow chained together with a tool like [Activepieces](https://www.activepieces.com), so it's the price to check first.

Kimi API pricing is the pay-as-you-go rate schedule Moonshot AI charges for its Kimi models, set per million input and output tokens and adjusted by cache hits, reasoning output and rate-limit tier.

## Kimi API Pricing Today, Checked Against Moonshot's Page

### The one-table price list

The table lists the output price for each flagship release I could confirm.

viz type=distribution title="What each Kimi flagship release charges for output" unit="$ per 1M output tokens" source="BenchLM - https://benchlm.ai/moonshot/api-pricing" xaxis="Release" yaxis="$ per 1M output tokens"5.00 for K3."
K2: 2.5
K2.5: 3
K2.6: 4
K3: 15

| Model | Output ($ per 1M tokens) |
|---|---|
| K3 | 15 |
| K2.6 | 4 |
| K2.5 | 3 |
| K2 | 2.5 |

Context window and usage limits are not in these confirmed figures, and I won't guess them. Read those columns off Moonshot's own page before you budget, because cache hits and rate-limit tier change the real bill.

### How flagship output prices changed by release

K2 launched at $2.50 per 1M output tokens, K2.5 moved to $3, and K2.6 to $4, so each release added roughly a dollar. **K3 jumps to $15, nearly four times K2.6**, so cost becomes a major consideration in model selection.

![Four gently rising coin stacks next to one towering stack](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/5513dacb-b021-4089-b930-ea75f1b2816c/kimi-api-pricing-in-2026-and-cost-per-1-000-task-02038b01.webp)

Take a step that writes 300 output tokens, run 1,000 times. That's 0.3M tokens: $4.50 on K3, $1.20 on K2.6, $0.90 on K2.5.

Sending easy steps like classification to an older model, which an [Activepieces](https://www.activepieces.com) flow can do per step, cuts that line fivefold against K3. Unlimited flows on every plan, including free, mean the split adds no flow charge.

On most APIs, the reasoning a model writes before its answer counts as output, so a short reply can still cost far more than its visible length suggests.

The output prices above come from BenchLM's Moonshot pricing page, as of 21 October 2026. Treat them as a snapshot, since list prices change between releases.

## Worked Cost of 1,000 Automation Runs on Kimi

A run costs its input tokens times the input rate plus its output tokens times the output rate, and 1,000 runs cost exactly a thousand times that.

The steps below show how K3 and K2.6 get priced the same way, so any price change only swaps one input.

1. State tokens per run: input (the email or ticket plus your instructions) and output (the summary or label).
2. Multiply input tokens by the input rate per million tokens.
3. Multiply output tokens by the output rate per million tokens.
4. Add the two for the cost of one run.
5. Multiply by 1,000 for a batch.
6. Multiply that by 100 for 100,000 runs a month, so per-run optimizations accumulate into meaningful monthly impact.
7. Repeat for K3 and K2.6, then subtract.

### Assumptions: tokens per email and per ticket

The unit metered here is one run: one email summarised or one ticket classified. Emails and tickets differ mainly in output: a summary writes sentences, while a label writes a word or two.

![A completed flow run showing trigger and step execution with HTTP request details and success status](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/bf7801a3-7dea-4788-a83a-1d3dde0fbc59/what-actually-transfers-when-you-migrate-off-aut-3c5ad478.webp)

That means a summary costs mostly its output rate and a classification mostly its input rate.

Count your own tokens from a sample of real messages, because a long quoted thread inflates input far beyond the visible text.

When Kimi summarises an email, output tokens dominate, so the output rate decides the winner against the cheaper model. If K3 charges a higher output rate than K2.6, every extra sentence in the summary widens the gap.

Cap summary length in the prompt and you shrink the K3 bill faster than you'd by switching models.

When Kimi classifies a ticket, input dominates, since the answer's a single label. The gap between the models follows the input rates, and a stable instruction block that gets cached input pricing narrows it further.

![Huge stack of paper in, one tiny slip out](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/1075ef1d-6bb2-4f60-9e4e-acf83fc1a36d/kimi-api-pricing-in-2026-and-cost-per-1-000-task-d365a297.webp)

## Hidden Costs and Limits Teams Hit With Kimi

The headline rate hides one charge above all: **reasoning tokens billed as output**. Five more items sit behind it:

- Reasoning tokens, billed at the output rate: a 120-word paragraph billed 2,289 tokens
- Cache-hit versus cache-miss input pricing
- Tool-call fees
- A minimum top-up
- Rate-limit tiers that rise with cumulative spend

That's roughly fourteen times the 160 or so tokens the paragraph itself contains, so the visible text's a poor guide to the bill.

[TaskCents](https://taskcents.com/models/kimi-k3/) estimates Kimi K3 requests as input, reasoning and output tokens:
- A chat question runs 39, 854 and 512.
- An email reply runs 249, 2,946 and 587.
- A blog post runs 53, 5,705 and 2,023.
- A proofread page runs 716, 3,281 and 843.
- A translation runs 1,322, 10,816 and 1,291.

![Where the tokens go in a Kimi K3 request](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/0b2c9a2d-f37b-4393-938f-0d6e6c190030/kimi-api-pricing-in-2026-and-cost-per-1-000-task-c3c4f690.svg "Source: TaskCents")

In every task reasoning is the largest slice, so most of your output-rate spend buys thinking you never read.

**Cache hits cost less than misses**, but the discount only touches input. Input's the smallest slice in all five tasks above, so caching trims a small line while reasoning stays untouched.

<blockquote class="pull"><p>In every task reasoning is the largest slice, so most of your output-rate spend buys thinking you never read.</p></blockquote>

If you open a new account, you start at the lowest ceiling, because tiers unlock with cumulative spend. I couldn't confirm the thresholds, so load-test before a launch rather than assuming production throughput.

I couldn't confirm tool-call fees or the minimum top-up. Treat both as unknowns until the vendor states them. An unknown tool fee can multiply across every step of an agent run, and a minimum top-up's cash committed before your first task.

## Kimi Compared With the Closest Alternative Models

Kimi's cheaper on some price lines and not others, so the comparison belongs at the level of one task, priced across the same five lines for every vendor.

### Price table across five vendors

 It shows input, output, cached price, context window and the cost of 1,000 runs of one step.

Read the 1,000-run column first, because it folds the other four lines into the number you'll actually be billed.

*(table)*

Check every row against the vendor's own pricing page on the day you commit, since list prices move.

### Where Kimi wins on cost

When your steps resend the same long prefix, Kimi's advantage shows up. That prefix might be a fixed instruction block or a shared document, and the cached price then applies to most of the input.

If the step is input-heavy and the prefix repeats, compare cached columns rather than headline input prices.

A large context window also helps when the alternative is chunking one job into several calls, each carrying its own overhead.

### Where a cheaper model is good enough

Kimi's not the cheapest option on every line. For classification, extraction and routing, a Haiku-class or Flash-class model often finishes the step for less, and a step that emits short output gains little from a bigger model's strengths.

Send the easy steps to the cheaper row and keep Kimi for the steps where its cache hits or context actually reduce the bill.

## Ways to Lower a Kimi Bill Without Switching

Four changes cut a Kimi K3 bill without leaving it: **keep the prompt prefix stable**, trim input, cap output, and give easy steps to a cheaper row.

The examples below assume a step of 2,000 input tokens and 300 output tokens, so 1,000 runs bill 2M input and 0.3M output tokens.

### Cutting Kimi API Costs With Prompt Caching

Kimi K3 bills [0.3, 3 and 15 dollars per million tokens](https://benchlm.ai/moonshot/api-pricing) for cached input, input and output. A cached token costs a tenth of an uncached one.

If 1,500 of the 2,000 input tokens are a fixed instructions-and-examples prefix that hits the cache, 1,000 runs fall from $10.50 to $6.45, which means caching large static portions of your input is worthwhile.

Put anything that changes per run, such as the email body, after the fixed text.

On K3, output costs five times the input rate, so a cap on output length is the strongest dial. Halving the reply from 300 to 150 tokens saves $2.25 per 1,000 runs, thereby showing that response length directly affects your per-run costs.

Trimming input from 2,000 to 1,200 tokens, for instance by stripping quoted reply chains, saves $2.40 at the uncached rate, meaning input optimization is another cost lever alongside output reduction.

### Using Cheaper Kimi Models for Easy Steps

K2.7 Code bills [0.19, 0.95 and 4 dollars](https://benchlm.ai/moonshot/api-pricing), and Kimi K2.6 bills 0.16, 0.95 and 4. The same step on K2.6 costs $3.10 per 1,000 runs, so K3's about 3.4 times as expensive for a classification it may not do better.

The chart shows each lever applied to the $10.50 baseline, ending with easy steps moved to the cheaper model.

Rerun it with your real token counts before committing, because the ranking shifts if your outputs are short.

Then set a spend alert on the account so a prompt change that breaks the cache shows up as a bill spike within a day, not at month end.

## Routing Each Workflow Step to the Cheaper Model With Activepieces

Activepieces can send easy steps to a cheaper model and reserve Kimi for the hard ones, but it doesn't change Kimi's list price at all.

Its core is MIT-licensed and the free cloud plan includes 1,000 credits a month, so you can test the split at $0.

What Activepieces gives you is the switch: one place where each step's model is chosen, alongside 743 integrations for the apps each step reads from and writes to, so the per-task pricing this article argues for becomes a setting, not a rewrite.

![n8n AI Agent vs Activepieces AI Agent](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/e67a969e-f633-4a5b-a235-f6f88fac6280/deepseek-r1-vs-v3-for-business-ai-2026-guide-scr-191f01d5.webp)

A ten-step flow that separates a cheap classify step from a hard Kimi reasoning step doesn't multiply the workflow-side bill: flows are unlimited on every plan, credits meter AI usage, and per-project and per-person caps with usage visibility let a team limit model spend.

Zapier bills per task and Make bills per module, so on their pricing pages the same split costs more with every step you add, which charges you for the habit of breaking work into small, reliable integrations.

The only per-step cost left is Moonshot's per-million-token rate, which you pay on your own key through the generic HTTP step or an OpenAI-compatible step.

I haven't confirmed a dedicated Moonshot integration among the 743 integrations in the open source monorepo, so I'm not linking one. Treat the HTTP route as the one you can rely on.

### Branching by task difficulty

A Router step splits a flow into conditional branches plus an Otherwise path.

In the screenshot below, a Router at step 5 sends one branch to an invoice-payment agent at step 6 and another to a separate agent at step 7.

That shows the pattern to copy: a condition decides which task runs next, and each branch can carry its own model.

![Activepieces canvas with a Router at step 5 feeding invoice-payment and second agent branches at steps 6 and 7, plus an Otherwise path](activepieces-router.png)

For pricing, put classification, tagging and short summaries on a cheaper model in one branch. Send multi-step reasoning, where long reasoning output inflates the bill, to Kimi in another.

Make the Otherwise path the cheap one, so an unmatched input never lands on the expensive model by default.

### Logging tokens per run to track spend

Every model response reports its token usage. Add a step after each call that writes the input tokens, output tokens, model name and branch to a spreadsheet or database row.

Multiply by each model's rates and you have a cost per task, not a guess per model.

If input tokens per run jump after a prompt edit, you see it in the rows before the invoice arrives. That log catches the cache problem from the previous section.

## A Monday Plan for Pricing Your Kimi Usage

Those rows only help if they're filled from your own traffic, so start the week with real prompts, not the list price. The six steps run in this order because each one feeds the next:

1. Pull real prompts for each task from your logs.
2. Measure average input and output tokens per run, including reasoning.
3. Multiply by the rates in the pricing table.
4. Test the cheaper model on 50 samples.
5. Set a spend cap and an alert.
6. Schedule a monthly pricing re-check.

### Measure tokens on real tasks

Pull prompts as they actually ran, with the system text, retrieved context and tool output attached. Because a hand-written example's shorter than production, it understates your input cost. Average input and output separately, because the two are billed at different rates.

Count reasoning tokens as output: a step that "answers in one line" can still bill for pages of thinking. Multiply each average by its table rate and you have a cost per run, which is the unit you'll compare.

![Tiny speech bubble beneath an enormous thought cloud of pages](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/4297b492-34e8-4d86-a0f0-77bbf0f41c77/kimi-api-pricing-in-2026-and-cost-per-1-000-task-66e8d05e.webp)

### Test the cheaper model on a sample

Run 50 real samples of one easy task, such as classification or extraction, through the cheaper model and compare the answers with what Kimi returned. Fifty is small, but it's enough to expose a failure pattern before you route live traffic to it.

If the cheaper model passes, route that step to it and keep Kimi for the steps that failed. Repeat per task, not per model.

### Setting a Kimi Spend Cap and Monthly Check

Set a hard spend cap, then an alert set below it, so you get a warning while there's still budget to act. Then put a monthly re-check of the pricing page on the calendar.

When rates, cache terms or tier limits change, a stale estimate quietly turns every cost per run you just calculated into a wrong number.

## Frequently asked questions

**Is there a free tier for the Kimi API?**

Possibly, but whether you get one depends on your account and when you sign up, so confirm it on the vendor's pricing page. Treat any free allowance as a trial credit for testing prompts, not as a budget you can plan a production workload around.

### Is the Kimi API cheaper than the Kimi chat subscription for heavy use?

It depends on what each plan meters. The subscription charges per seat and caps your usage, while the API charges per token, so your bill moves with prompt length, cache hits and reasoning output.

Price one real task on the API, such as a full run of your workflow, and compare that against the subscription fee divided by the runs you expect.

### Does Kimi charge for cached requests?

Yes, but cached input tokens are billed at their own rate, separate from the standard input rate. That makes cache-hit price the first line to read on the pricing page.

If your workflow resends the same long instructions on every call, it pays the cached rate on most of its input; if it changes the prefix each time, it pays the full rate.

**Can I use the Kimi API with OpenAI-compatible tools?**

Generally yes. The API follows the OpenAI request format, so most tools need only a new base URL, key and model name.

Before you rely on it, test tool calling and any reasoning output on a small batch, because compatible doesn't mean every field behaves identically.

### How often does Kimi change its API prices?

There's no fixed schedule you can plan around, so treat every rate as provisional.

Record the date you last read the pricing page next to each cost estimate, and re-check the cache terms and rate-limit tier at the same time. A change to either one alters your cost per run even when the headline token price stays the same.

## Related reading

- [Zapier Pricing 2026: Plans, Tasks & True Cost at Scale](https://www.activepieces.com/blog/zapier-pricing-2026-plans-tasks-true-cost-at-scale)
- [How Much Does UiPath Pricing 2026 Cost?](https://www.activepieces.com/blog/how-much-does-uipath-pricing-2026-cost)
- [How Much Does DocuSign Pricing 2026 Cost?](https://www.activepieces.com/blog/how-much-does-docusign-pricing-2026-cost)

## References

- [BenchLM](https://benchlm.ai/moonshot/api-pricing)
- [TaskCents](https://taskcents.com/models/kimi-k3/)
