Saltar al contenido principal

Ember-1: Kimi K3's Answers for 40% Fewer Tokens (Sep 2026)

Intermedio

On September 23, 2026 Fireworks published Ember-1: not a new architecture, not a new pre-train — Kimi K3 with its reasoning habit re-trained. Same 2.8-trillion-parameter body, same 1M context, same price per token. It just stops thinking so much. Fireworks reports 35–50% fewer reasoning tokens with no loss of accuracy, and on two of five published benchmarks Ember-1 outscores K3 running at its maximum effort setting while costing less.

Four days later it was the top AI story on Hacker News. The interesting part is not the model — it is the claim underneath it: the cheapest way to run a reasoning model is no longer to tell it to think less. This page takes that claim apart, shows you the arithmetic the launch table implies but never prints, and gives you a way to test it on your own traffic in an afternoon.

What you'll learn
  • Separate the two things that make an agent expensive: price per token, and number of tokens — Ember-1 changes only the second
  • Read the launch table honestly, including the benchmark where effort buys literally nothing and the one where every model scores under 22%
  • Derive the cost per task the blog does not print (and discover a single benchmark run costs $5–$535)
  • Understand why a 71% cut in reasoning tokens produced only a 39% cut in total tokens — and what that ratio tells you about your own bill
  • Measure reasoning-token share on your workload with one field most SDK wrappers throw away
  • Know the fine print before you migrate: research-preview status, no released weights, a lost input modality, and the revenue-tiered Kimi K3 licence underneath it all

The one-paragraph version​

Kimi K3, like every reasoning model, spends most of its generated tokens on internal reasoning — Fireworks puts it at sometimes more than 90%. In a multi-turn agent that reasoning is replayed into every later call, so context grows roughly quadratically with turn count and early thinking gets re-billed for the rest of the run. Fireworks' customers asked for K3's coding quality at lower cost; turning reasoning_effort down gave up too much quality, so Fireworks trained the behaviour instead — over 50 training runs and 200+ evaluations — teaching the model to keep the self-reflection that recovers from mistakes and drop the rest. The result is served as accounts/fireworks/models/ember-1 at exactly K3's rates: $3 / M uncached input, $0.30 / M cached input, $15 / M output.

Three things the headline hides​

1. Nothing got cheaper. The model just buys less.​

This is the part that reframes how you should think about model cost. Ember-1's rate card is identical to Kimi K3's, on Fireworks and on OpenRouter alike ($3 input / $15 output per million, 1,048,576-token context on both). There is no discount. Every dollar saved comes from tokens that are never generated in the first place — and, in an agent loop, from those same tokens never being replayed as input on the next nineteen turns.

That has a practical consequence: $/token is the wrong number on your dashboard. Two models at the same list price can differ 2× on the same task, and the model with the higher list price is regularly the cheaper one per finished task. AILmanac's What AI costs across providers makes the same point from the pricing side; Ember-1 is the cleanest natural experiment for it yet, because the price variable is pinned and only the token count moves.

2. Turning effort down is not the same thing, and the table proves it​

K3 exposes reasoning_effort at low, high and max. Fireworks ran all three as separate arms, which is what makes their table more useful than most launch tables:

BenchmarkNK3 lowK3 highK3 maxEmber-1Ember-1 vs K3 max
Terminal Bench 2.18976.4%77.6%80.9%82.0%−51.9% / −23.1 USD
SWE-bench Verified50080.4%86.0%93.2%92.2%−15.5% / −68.1 USD
SWE-Interact756.7%13.3%21.3%20.0%−32.5% / −60.8 USD
DeepSWE 1.111355.8%62.8%66.4%75.2%−23.7% / −126.9 USD
τ-2 Bench Airline5064%64%64%66%−5.9% / −0.3 USD

Read down the K3 columns before you read the Ember column. On SWE-bench Verified, dropping from max to low costs you 12.8 points — that is the "give up too much quality" Fireworks is talking about, and it is why an effort dial alone could not solve their customers' problem. Ember-1 lands above K3 high on every row and above K3 max on two of five, at a lower cost than max on all five. Against K3 low it is strictly better on both axes.

Two rows deserve separate attention:

  • τ-2 Bench Airline: 64% / 64% / 64%. Three effort levels, one score. On this benchmark every extra thinking token K3 generates is pure waste — you pay max prices for low results. If your production workload looks like τ²-bench (a scripted customer-service policy, short turns, tool calls against a fixed API), the effort dial is a cost setting with no quality meaning, and you should have measured that rather than defaulted to it. The general habit — sweep effort on your eval before trusting a default — is in Effort tuning and Reasoning models compared.
  • SWE-Interact: nobody breaks 22%. The same models that resolve 92–93% of SWE-bench Verified resolve one task in five when the benchmark requires interacting with a user mid-task. SWE-bench Verified is close to saturated and tells you almost nothing about a frontier model any more; the interactive variant is where the actual capability gap lives. Keep both in mind whenever a launch post leads with a 90-something SWE-bench number. This is the capability–reliability gap showing up as two columns in one table.

3. The "−51.9% / −23.1 USD" column tells you what a benchmark run costs​

Fireworks never labels the two figures in that last column. Read as relative cost reduction and absolute dollars saved over the whole run, they are internally consistent — and dividing one by the other recovers a number nobody publishes: what it costs to run these benchmarks once.

The arithmetic below is ours, not Fireworks' — it is inference from their two published figures, so treat it as an order of magnitude, not a quote:

BenchmarkNImplied K3-max run costImplied cost per task
Terminal Bench 2.189~$44~$0.50
SWE-bench Verified500~$439~$0.88
SWE-Interact75~$187~$2.49
DeepSWE 1.1113~$535~$4.74
τ-2 Bench Airline50~$5~$0.10

A single DeepSWE 1.1 sweep on K3 at max effort runs to roughly half a thousand dollars — for 113 tasks. That is the real reason "just run your own evals on every model" is advice people nod at and do not follow, and it is worth knowing before you promise a stakeholder a five-model bake-off. It is also the number that makes a 24% saving matter: repeated nightly, that one benchmark is a $46,000-a-year line item.

Why 71% off reasoning was only 39% off the bill​

Fireworks' internal validation reports 71.3% fewer reasoning tokens and 39% fewer total tokens on the same traffic. The gap between those two numbers is the most useful thing in the announcement, and it generalises to any efficiency claim you are ever pitched.

Reasoning tokens are a share of generated tokens. The rest of your bill is made of things an efficiency post-train cannot touch:

  • System prompt and tool definitions, re-sent every turn (often the largest single block in an agent).
  • Tool results — file contents, search results, HTTP responses — which arrive from the outside world at their own size.
  • The final answer, which you actually wanted.
  • Prior turns, replayed as input.

So the ceiling on any "fewer thinking tokens" saving is your reasoning-token share, not the vendor's. An agent whose turns are 80% tool output will see a fraction of the advertised win; a chat workload with a short prompt and long deliberation will see most of it. Before you migrate anything, measure the share — the next section shows how. Why agents burn tokens covers the other three lines in that list.

Watch out
  • A vendor's token-reduction percentage is measured on the vendor's traffic mix. Your saving is bounded by your own reasoning-token share — measure it before you estimate anything.

Measure it on your own traffic in an afternoon​

Fireworks returns the model's thinking in a reasoning_content field (the content that would otherwise sit inside think tags) rather than in content. Many OpenAI-compatible wrappers drop unknown fields, which is how teams end up unable to answer "what share of our output is thinking?" — and, worse, how they silently break multi-turn quality.

Guided walkthrough1 of 5
  1. Log the length of reasoning_content next to the length of content for every assistant message, for a day of real traffic. The ratio is your reasoning-token share and the ceiling on any efficiency saving anyone can sell you.

One call against Ember-1 on the OpenAI-compatible endpoint

curl https://api.fireworks.ai/inference/v1/chat/completions \
-H "Authorization: Bearer $FIREWORKS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "model": "accounts/fireworks/models/ember-1",
  "max_tokens": 8192,
  "messages": [
    {"role": "system", "content": "You are a senior engineer. Reply with a unified diff and one paragraph of rationale."},
    {"role": "user", "content": "The test suite in ./tests fails on macOS only. Log and module attached: ..."}
  ]
}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content // "" | length),
  usage: .usage
}'

The A/B you actually want: same task, three arms, one table

# Arm 1 — the incumbent at full effort
MODEL="accounts/fireworks/models/kimi-k3" EFFORT="max"  ./run-evals.sh > k3-max.jsonl

# Arm 2 — the cheap way people try first
MODEL="accounts/fireworks/models/kimi-k3" EFFORT="low"  ./run-evals.sh > k3-low.jsonl

# Arm 3 — the efficiency post-train (no effort setting to choose)
MODEL="accounts/fireworks/models/ember-1"               ./run-evals.sh > ember.jsonl

# Then the only comparison that matters:
#   dollars spent / tasks that passed the gate
jq -s 'group_by(.arm)[] | {arm: .[0].arm,
      passed: (map(select(.passed)) | length),
      usd: (map(.usd) | add),
      cost_per_pass: ((map(.usd) | add) / (map(select(.passed)) | length))}' *.jsonl

The fine print before you migrate​

It is a Research Preview. Fireworks ships new research models with two weeks of serverless access and makes them permanent "based on community demand". Do not put an unbudgeted migration behind that. Build the A/B, keep K3 as the fallback path, and re-check availability before you cut over — this is exactly the case server-side fallbacks and model routing patterns exist for.

The weights are not released, and that is legal. The most-upvoted confusion in the Hacker News thread was some version of "they trained on open weights and are not releasing theirs — can they do that?" They can. The Kimi K3 licence grants the right to "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software; to run, deploy, fine-tune, or otherwise modify the Software and create derivative works from it" — with no copyleft obligation to publish what you build. What it does attach are two revenue-tiered conditions, and they are worth knowing whether or not you care about Ember-1:

  • Model-as-a-Service above $20M. If you (and affiliates) run a MaaS business — giving third parties access to model inference or fine-tuning, e.g. via API, with meaningful control over inputs, parameters or training data — whose combined revenue exceeds $20 million over any consecutive 12 months, you must enter a separate agreement with Moonshot AI before commercial use of the Software or its derivative works.
  • Attribution above 100M MAU or $20M/month. A product or service built on it that passes 100 million monthly active users or $20 million in monthly revenue must display "Kimi K3" prominently in its user interface.

Internal use that does not expose the model or its capabilities to third parties is exempt from the MaaS clause. The practical reading: an open-weight licence can be MIT-shaped at the top and still gate the two situations a serious business ends up in. Read the licence before the benchmarks — the same advice applies to every "open" frontier release on DeepSeek, Qwen and the open-weight wave.

Check your input modalities. OpenRouter lists Kimi K3 as text+image+video and Ember-1 as text+image. Fireworks' own model page advertises image input for Ember-1 and says nothing about video. If any part of your pipeline sends video frames to K3, verify that path explicitly before switching — a modality that silently disappears is a much worse failure than a quality dip, because it usually surfaces as a malformed request in production rather than a lower score in an eval.

Check your sampling parameters too. OpenRouter's parameter list for Ember-1 omits seed and min_p, both of which it lists for K3. If your eval harness pins a seed for reproducibility, confirm the behaviour on the endpoint you will actually call rather than assuming the parent model's surface carried over. Porting prompts across models has the broader checklist.

Reading the Specialized Intelligence Index​

Ember-1's other headline — "sets a new Pareto frontier on Bedside Bench across open and closed models including GPT-5.6 Sol, GPT-6 Astra and Claude Opus 5" — comes from the Specialized Intelligence Index, which Fireworks launched on September 22, 2026, one day before Ember-1. Same company runs the index and ships the model. That is not automatically disqualifying, but it changes how you read it.

What the SII does better than the usual leaderboard:

  • Benchmarks come from practitioners, not academia — Doximity's BedsideBench (500 physician-validated clinical cases) for healthcare, Harvey's legal agent benchmarks for law, Sierra's τ-Banking and τ-Voice and Decagon's DuetBench for support, Rogo for finance, Novee's PWNBench and depthfirst's dfbench for security, and a software cluster including Datacurve's DeepSWE and Proximal's FrontierSWE V2.
  • It reports cost per task and wall-clock duration next to score, from provider rate cards — the axes this whole page argues for.
  • It labels every result by who can reproduce it: anyone, Fireworks-with-partner, or partner-only. That single label is the most useful piece of leaderboard metadata published this year; treat a partner-only row as a vendor claim with a nicer table around it.
  • It refuses a composite score. No rollup across domains, no single "intelligence" number — which is the right call, and rare.

What to hold in mind anyway: the benchmark suite, the arms chosen, the effort settings, and the model that wins are all selected by the same party. Compare its rows against an index run by someone with no model to sell before you quote them in a design doc. The general discipline is in The verification bottleneck.

So should you switch?​

  • Agentic coding on K3 at max effort, at volume: run the A/B this week. This is the exact workload Ember-1 was trained on, the reported savings are 15–52% of cost, and DeepSWE 1.1 suggests you may gain accuracy rather than trade it.
  • Already running K3 at low or high because max was too expensive: strong candidate. Ember-1 beats K3 high on all five published rows and dominates low outright.
  • Workloads shaped like τ²-bench (short turns, scripted policy, heavy tool output): expect modest savings — the effort dial was already doing nothing for you, and your reasoning-token share is small.
  • Anything needing video input, a pinned seed, or a guaranteed 12-month endpoint: stay on K3 for now and re-evaluate when the preview converts.
  • Not on Kimi K3 at all: the transferable lesson is the measurement, not the model. Find your reasoning-token share, sweep the effort dial on your own eval, and start reporting cost per completed task instead of $/M tokens. Every provider's version of this question is the same question.

Check yourself

0/6
  1. Ember-1 costs exactly the same per token as Kimi K3 ($3 in / $15 out per million). Where does the reported 35–50% saving come from?
  2. On τ-2 Bench Airline, Kimi K3 scores 64% at low, high AND max effort. What does that tell you?
  3. Fireworks reports 71.3% fewer reasoning tokens but only 39% fewer total tokens on the same traffic. Why the gap?
  4. Every model in the launch table scores 80–93% on SWE-bench Verified but 6.7–21.3% on SWE-Interact. What is the right conclusion?
  5. Fireworks built Ember-1 on Kimi K3's open weights and did not release Ember-1's weights. Under the Kimi K3 licence, is that allowed?
  6. Your team runs an agent whose turns are dominated by large tool outputs (file contents, search results). How much of the advertised 40% saving should you budget for?
Pulsa Intro o Espacio para girar la tarjeta. Usa las flechas izquierda y derecha para moverte entre las tarjetas.Término mostrado.
1 / 9

Next​

Sources & further reading​