Ember-1 Trims Kimi K3's Reasoning by 40% — and the Fine Print Is the Story

The number that will get quoted is 40%. Fireworks Research published Ember-1 on 23 September 2026, describing it as a specialized derivative of Moonshot AI's Kimi K3 that holds K3's accuracy while spending roughly 40% fewer tokens to get there. That is a real and unusually specific claim, and it arrives with three things attached: a full benchmark sheet with token-reduction columns, two customer A/B tests from production coding traffic, and a release status that is not general availability. Ember-1 is out as a research preview, on the vendor's own serverless platform, with a two-week access window and a permanence decision that depends on demand. Understanding which part of this is a shipped product and which part is a well-argued research result is the whole exercise.

There is also a name collision worth clearing before anything else. A separate open research project called Ember (v0.1.5, from Slow Lit Labs) spent 2026 publishing long-horizon-coherence evaluations, and it is not related to this model in any way. Anything you read about Ember failing to beat Qwen3-8B under matched inference settings is about that project. Ember-1, the subject here, is a Kimi K3 derivative from Fireworks Research.

What Ember-1 actually is

Ember-1 is not a new architecture and not a new base model. It is Kimi K3, retrained to reason more concisely. Fireworks Research ran more than 50 training experiments and over 200 evaluations on its own serverless training stack, across mathematics, coding, instruction following, conversation, search, tool use and software engineering, with the explicit goal of removing reasoning that does not change the answer. The lab says reasoning length could be cut by 35–50% without accuracy loss across seven benchmarks and two customer production traffic sets. Every one of those figures is vendor-reported and has not been independently reproduced; no third party has published a run of Ember-1 as of writing.

The framing matters because the obvious alternative already existed. Kimi K3 ships with reasoning-effort settings, and the cheap way to spend fewer tokens is to turn effort down. Fireworks Research says it tried that and the low setting gave up too much quality — which is a familiar result to anyone who has tuned effort levels on a reasoning model. Ember-1's claim is that the effort dial is coarse and retraining is fine.

Why reasoning tokens are worth this much effort

A reasoning model's bill is not dominated by its answer. Fireworks Research notes that K3 can spend more than 90% of its generated tokens on internal reasoning before it writes anything a user sees. On a single request that is merely expensive. In a multi-turn agent loop it compounds, because each turn replays the prior conversation, so the reasoning traces from earlier turns get re-read and re-billed on every subsequent call. Fireworks Research describes context growing roughly quadratically with turn count. That is the actual target of this release, and it is why the headline metric is roughly 40% fewer tokens rather than a quality jump.

The mechanism also explains the risk. Compression that removes wasted deliberation is free; compression that removes a step the model needed is not. The widely-reported failure mode of over-aggressive reasoning reduction is a model that skips an intermediate check and jumps to a conclusion, which in an agent shows up much later as a wrong tool call rather than a wrong sentence. Fireworks Research's repeated emphasis on equivalent quality reads as an answer to that concern, and the A/B numbers are the closest thing to evidence for it — with the usual caveat that the test sets, the pass criteria and the sample sizes were all chosen by the party making the claim.

The benchmark sheet, with its provenance attached

These are Fireworks Research's figures, unreproduced. The right-hand column is the part worth reading closely: it pairs each score with how many tokens and dollars it took relative to K3 Max.

• Terminal Bench 2.1 (n=89) — Ember-1 82.0% vs K3 Max 80.9%, K3 High 77.6%, K3 Low 76.4%; 51.9% fewer tokens, $23.10 less per task.

• SWE-bench Verified (n=500) — Ember-1 92.2% vs K3 Max 93.2%; 15.5% fewer tokens, $68.10 less per task.

• SWE-Interact (n=75) — Ember-1 20.0% vs K3 Max 21.3%, K3 High 13.3%, K3 Low 6.7%; 32.5% fewer tokens.

• DeepSWE 1.1 (n=113) — Ember-1 75.2% vs K3 Max 66.4%; 23.7% fewer tokens, $126.90 less per task.

• τ-2 Bench Airline (n=50) — Ember-1 66% vs K3 Max 64%, K3 High and Low both 64%; 5.9% fewer tokens, $0.30 less per task.

Two things stand out. First, Ember-1 wins outright on Terminal Bench 2.1 and DeepSWE 1.1 while losing narrowly on SWE-bench Verified and SWE-Interact — a pattern consistent with a model that has not lost capability so much as changed which tasks it spends deliberation on. Second, the token savings are wildly uneven: 51.9% on Terminal Bench against 5.9% on τ-2 Airline. Whatever Ember-1 learned, it is not a uniform 40% haircut on thinking. The "about 40%" in the headline is an average across a spread that runs from roughly 6% to roughly 52%, and a team whose workload looks like τ-2 Airline should not expect to feel it.

The production A/B tests are the more persuasive evidence, precisely because they were not built to be benchmarks. In one customer's coding workload, Ember-1 scored 0.753 against K3's 0.751, took 21.4 steps against 23.8, and emitted 29.9K output tokens against 49.3K — a 71.3% reduction in reasoning tokens and 39% in total tokens, with roughly equivalent quality. A second customer saw about 35% fewer tokens per task at comparable quality, and Fireworks Research says it ran the switch on its own internal coding and coworking traffic first, with the reported outcome that nobody noticed. Treat all of it as vendor-reported, but treat it as the strongest form of vendor-reported: A/B preference and task-completion data are harder to game than a leaderboard.

There is one more evaluation, on Doximity's Bedside Bench — 500 physician-validated clinical cases across ten categories — where Fireworks Research claims Ember-1 set a new Pareto frontier on cost per task, comparing it against open and closed models including GPT-5.6 Sol, GPT-6 Astra and Claude Opus 5. That is a vendor claim about a Pareto position, which is a claim about a two-dimensional tradeoff rather than a single score, and it is only as good as the cost assumptions behind it. Those assumptions came from Kimi K3's public API rate card. Which brings us to the part of the story a reader can actually verify today.

The base model is the part you can already route

Ember-1's entire cost argument is measured against Kimi K3's published rates. Kimi K3 is live on OrcaRouter at $3.00 per million input tokens, $0.30 per million cached input tokens and $15.00 per million output tokens, with a 1,048,576-token context window. That is the same rate card the Fireworks Research comparison uses, and it is worth knowing that the savings in those token-reduction columns are calculated against numbers you can see for yourself rather than against a vendor's internal cost model.

Ember-1 itself is not on OrcaRouter. It is available only through the vendor's own serverless platform, as a research preview, and Fireworks Research has not published a price for it — so the dollar figures in the benchmark table are derived from K3 rates and token counts, not from an Ember-1 rate card that exists. If the arithmetic is what interests you, the honest sequencing is to price the workload at K3's route today, take the token-reduction percentages as the upper bound of what a switch might buy, and wait for a published rate before modelling the saving as money.

Where OrcaRouter does help here is with the hedge. A research preview with a two-week access window is exactly the kind of model you want to try without betting a production path on it, and the way to do that without a second contract is to put it behind the same endpoint as everything else you call. OrcaRouter serves 200+ models behind one API with automatic failover, so a preview model that turns out to be unavailable next month is a routing change rather than a migration. Nothing about Ember-1 requires that — but nothing about a two-week window argues against it either.

What to do with this release

If you already run Kimi K3 in an agent loop, Ember-1's numbers describe your bill. The multi-turn replay problem is real, it is the dominant cost in long agent runs, and a model that shortens its own traces without changing its answers is worth the evaluation time. The right test is not the benchmark table; it is your own traffic, run in shadow — send a share of real requests to both models, compare outputs, keep live results untouched for a week or two before changing anything. That is also the advice the release's own critical readership is giving, and it is sound.

If you run a low-deliberation workload, or one dominated by short single-turn calls, the savings largely evaporate and the τ-2 Airline row is your realistic expectation. And if you need a production-grade commitment — a price, a service level, a guarantee the endpoint exists in six months — Ember-1 does not offer one yet. It is a research preview whose permanence Fireworks Research explicitly ties to demand. The interesting question over the next month is whether the two-week window becomes a permanent serving option and whether a third party reproduces any of the numbers. Until one of those happens, this is a strong result to read and a poor one to build a budget on.

None of that should be read as diminishing the work. Removing reasoning without removing accuracy is a harder problem than adding it, and doing it on top of someone else's frontier model rather than training your own is the shape a lot of 2026 capability work has taken. Ember-1 is the first release in what Fireworks Research says will be an ongoing series, and the template — take a model that is already good, retrain one axis of its behaviour, sell the delta in tokens — is one worth watching regardless of how this particular preview lands.