Fireworks released Ember-1 on September 23, 2026 with a claim I could not check against my own invoices: Kimi K3 quality at 40% fewer tokens, and in one A/B test a 71.3% cut in reasoning tokens specifically. I pay for Claude, Claude Code and Cursor every month, and until I went looking for this piece I had never once opened the field that tells me how much of my output spend was the model thinking rather than answering. That is the honest starting position here. Reasoning tokens bill at full output rates, they grow with task difficulty rather than answer length, and if you have never opened that field either, both of us have been buying them blind.
In this article
- Why agentic tools spend money where you cannot see it
- How reasoning tokens are billed at full output rates
- Why Fireworks priced Ember-1 exactly like the model it replaces
- What the benchmark table says about the cost of efficiency
- How to count your reasoning tokens before you try to cut them
- Why the budget dial got replaced by an effort setting
- Seven reasoning token checks I now run every month
- FAQ
Agentic Tools Spend Your Money Where You Cannot See It
The spend problem in a one-person AI stack is not the chat window, it is the agent loop. When I ask Claude a question in a browser tab, I see the answer and I have a rough sense of what I bought. When Claude Code runs eleven tool calls to rename a folder of client files, the visible output is four lines of confirmation and the invisible output is everything the model worked through to get there. Those are not the same purchase, and only one of them shows up on screen.
This matters more now than it did a year ago because the tools I use most are the agentic ones. Claude Code runs daily. Cursor handles CSV cleanup and rename jobs. Google Antigravity has been sitting beside Claude Code in my testing since May. Every one of those is a multi-step loop where the model reasons between actions, and every step of reasoning is billable text I will never read.
The shape of the problem is simple enough to state in one sentence. Reasoning tokens scale with task difficulty rather than with answer length, so the runs that feel cheapest — short output, quick confirmation — can be the ones that cost the most. A four-line summary sitting on top of a long chain of internal deliberation looks, on the bill, exactly like a long essay.
None of this is hidden in a dishonest way. Both Anthropic and OpenAI document it plainly. It is hidden in the ordinary way that a utility meter is hidden: technically visible, practically ignored, and only ever consulted after something goes wrong.
Reasoning Tokens Are Billed at Full Output Rates
Nobody gives you a discount for thinking. OpenAI’s reasoning guide states it without hedging: “While reasoning tokens are not visible via the API, they still occupy space in the model’s context window and are billed as output tokens.” Anthropic’s extended thinking documentation says the same thing from the other direction, describing a usage.output_tokens_details.thinking_tokens field that “reports how many of the billed output tokens were internal reasoning.”
Read those two sentences together and the economics get clear fast. Reasoning tokens are not a separate meter with a separate rate. They are output tokens that you cannot inspect, cannot cache in the way you cache a system prompt, and cannot shorten by asking for a shorter answer. On any frontier model, output is the expensive side of the ledger, which means reasoning tokens are charged at the highest rate the provider offers.
The second fact is that they consume context as well as budget. OpenAI recommends “reserving at least 25,000 tokens for reasoning and outputs when you start experimenting with these models,” which is a polite way of saying that a task can fail not because the model was wrong but because it thought itself out of room. Anthropic’s rule is structurally identical: the thinking budget counts toward max_tokens for the turn, with a floor of 1,024 tokens, so the budget has to leave space for the actual answer.
So reasoning tokens are expensive twice. They cost money at output rates, and they cost headroom in a context window you were already rationing. That double charge is the reason a model that reaches the same answer with fewer of them buys you more than a simple percentage suggests.
Fireworks Priced Ember-1 Exactly Like the Model It Replaces
Efficiency claims almost always get paid for somewhere, and this one does not. Fireworks built Ember-1 on Kimi K3 and claims it “delivers Kimi K3’s quality with 40% fewer tokens,” which is the sort of line that usually collapses the moment you open the price list. The premium tier, the higher per-token rate, the minimum commit — the efficiency gets billed back to you one way or another.
That is not what happened. On Fireworks’ own serverless pricing, Ember-1 lists at $3.00 input, $0.30 cached input and $15.00 output per million tokens. The Kimi K3 page on the same platform lists the identical three numbers. Same rate card, same roughly one-million-token context window, fewer tokens consumed to finish the job.
When the per-token price is held constant, a reduction in reasoning tokens passes through to the invoice almost one to one. That is a rarer thing than it sounds. Most of the price movement I have tracked this year came from vendors cutting rates — I wrote about what Anthropic’s lower Opus pricing actually changed for a daily user — and rate cuts are wonderful but they are also somebody else’s decision. Token efficiency is a different lever: it reduces what you consume rather than what you are charged for consuming.
I should be precise about my standing here. I have not run Ember-1 or Kimi K3 in client work; when Moonshot published K3’s open weights in July I covered it from the sidelines and that is still where I am. What I can evaluate is the structure of the claim, and the structure is unusually clean: identical published pricing, a documented reduction in reasoning tokens, and a research preview you can test without a commitment.
The Benchmark Table Shows Efficiency Is Not Free
The published numbers do not describe a free lunch, and Fireworks does not pretend otherwise. Across the benchmarks in the Ember-1 announcement, the pattern is a narrow trade rather than a clean win:
- Terminal Bench 2.1: Ember-1 at 82.0% against Kimi K3 Max at 80.9%
- DeepSWE 1.1: Ember-1 at 75.2% against 66.4%
- τ-2 Bench Airline: 66% against 64%
- SWE-bench Verified: Ember-1 at 92.2% against 93.2%
- SWE-Interact: 20.0% against 21.3%
Three up, two down. Fireworks describes the overall reduction as “35–50% without sacrificing accuracy” across seven benchmarks and two customers, and reports one A/B test at 39% total token reduction with a 71.3% drop in reasoning tokens. That last pair of numbers is the interesting one, because the gap between 39% and 71.3% tells you where the savings came from. The answer stayed roughly the same length. The deliberation behind it got cut by two-thirds.
That is the trade a solo operator has to price honestly. A model that thinks less will sometimes think too little, and the two benchmarks where Ember-1 lands lower are both software engineering tasks where the extra deliberation presumably earned its keep. Whether a one-point drop on SWE-bench Verified matters to you depends entirely on whether your failure mode is expensive.
The question is not whether fewer reasoning tokens cost you accuracy. It is whether the accuracy you lose is worth less than the tokens you keep.
For most of what I hand to an agent — renaming files, reshaping a CSV, drafting a script I will read before running — the answer is obviously yes. For anything touching a client deliverable, I would rather overpay in reasoning tokens than debug a confident mistake.
Count Your Reasoning Tokens Before You Try to Cut Them
Nobody should be optimising a number they have never measured, which is the part I got wrong for most of this year. Both major providers expose the breakdown, and both do it in a field that sits one level deeper than the usage number most dashboards show.
On Anthropic, the field is usage.output_tokens_details.thinking_tokens, and the documentation notes that when you stream a response the breakdown “appears only on the final message_delta event” — which is exactly why it is easy to miss in a streaming client. On OpenAI, the equivalent is usage.output_tokens_details.reasoning_tokens. Same shape, same place in the response object, same total absence from the summary line you actually look at.
Reading those fields for a week changes what you think your stack costs. The headline usage number tells you output tokens; it does not tell you what fraction of them you would have paid for even if the model had answered instantly. That fraction is the only honest basis for deciding whether reasoning tokens are a problem in your particular workflow, and on my own request mix the answer may well be no.
This is also the point where the answer stops being a model choice and becomes a routing decision. I run a short list of checks before wiring any agent API into client work, and token accounting now sits near the top of it. If 70% of your output spend is deliberation on tasks that never needed it, the fix is not a cheaper provider. The fix is sending the easy work somewhere that does not think about it for thirty seconds first.
The Budget Dial Got Replaced by an Effort Setting
The control surface changed underneath this problem, and if you last tuned it a year ago your mental model is out of date. Anthropic’s manual approach was a fixed thinking budget — thinking: {type: "enabled", budget_tokens: N} — where the model thinks on every request against a number you pick. The docs are now explicit that this is deprecated on the 4.6 generation and rejected outright on Claude 4.7 and later, “such as Claude Opus 5.5, Claude Sonnet 5, and Claude Fable 5.1,” which return a 400 error.
What replaced it is adaptive thinking with an effort control: thinking: {type: "adaptive"} plus output_config: {effort: ...}. The behavioural difference matters more than the syntax. With a fixed budget, the model spends reasoning tokens on every request whether or not the request deserved them. With adaptive thinking, Anthropic’s documentation says the model “decides whether and how much to think on each request, and at lower effort settings it may skip thinking entirely on easy inputs.”
That is a structurally better default for the way a solo stack actually works, because my request mix is lumpy. Most of what I send is trivial. A few things a week are genuinely hard. A fixed budget taxes the trivial requests to fund the hard ones; an effort setting lets the easy ones through cheaply. It is the same insight Fireworks baked into a model, arriving from the opposite direction — one through training, one through a runtime parameter.
One practical warning sits in the same docs, and it is the kind of thing that quietly doubles a bill. Changing the thinking configuration invalidates prompt caching, because the budget value is rendered into the prompt. Anthropic shows the effect directly: a third request with a changed budget re-creates a 1,370-token cache instead of reading it. If you are going to tune reasoning tokens, pick a setting and hold it for the life of a cached conversation rather than nudging it between calls.
Seven Reasoning Token Checks I Now Run Every Month
None of this needs a new subscription, and that is deliberate — the whole point of a token efficiency story is that it should reduce spend rather than add a line to it. These are the seven checks I have folded into my own monthly review:
- Read the thinking breakdown, not the total.
thinking_tokenson Anthropic,reasoning_tokenson OpenAI. If you have never looked, look once before forming an opinion. - Separate the lumpy requests from the routine ones. Reasoning tokens are worth paying for on a handful of hard tasks a week and wasteful on everything else.
- Migrate off fixed thinking budgets. On Claude 4.7 and later they return a 400 error anyway; adaptive thinking with an effort setting is the supported path.
- Hold the thinking configuration stable inside a cached conversation, because changing it invalidates the cache and the cache is usually worth more than the tuning.
- Reserve context deliberately. OpenAI’s floor of 25,000 tokens for reasoning and output is a reasonable starting reservation, and Anthropic’s budget has to sit under
max_tokenswith room for the answer. - Price efficiency claims against the rate card. Ember-1 is interesting because the rate did not move; an efficiency claim attached to a higher per-token price is a different product.
- Keep one expensive path open. For client deliverables I want the model that deliberates, and the cost of a confident error is not measured in tokens.
The sixth check is the one I would keep if I could only keep one, because it is the one that catches marketing. Fewer tokens at a higher rate is not a saving, and the only way to know which you are being offered is to open both pricing pages and compare the three numbers. It took me under a minute to do that for Ember-1 and Kimi K3, and it is the reason this piece exists at all.
For me, the useful outcome of reading all this was not a switch. I am still on Claude and Claude Code daily, still running Cursor for the jobs it is better at, and I have not moved a single client workflow to Fireworks. What changed is that I now know which fraction of my output spend is deliberation, which is a number I should have been watching since the first agentic tool landed in my stack. Reasoning tokens are not a scandal and they are not a scam — they are just the part of the invoice nobody printed on the front page.
Sources
- Fireworks AI — Introducing Ember-1
- Fireworks AI — Ember-1 model and serverless pricing
- Fireworks AI — Kimi K3 model and serverless pricing
- Anthropic — Extended thinking
- OpenAI — Reasoning
FAQ
Are reasoning tokens charged at a different rate than normal output?
No. OpenAI’s documentation states that reasoning tokens “are billed as output tokens,” and Anthropic describes thinking tokens as a subset of the billed output tokens reported in usage.output_tokens_details.thinking_tokens. There is no separate or discounted meter on either platform.
Can I see what the model actually reasoned about?
No. OpenAI says reasoning items “remain opaque, and the API does not return their reasoning text.” Anthropic returns summarised thinking blocks rather than raw traces. You can measure the volume of reasoning tokens precisely, but you cannot audit their content the way you audit an answer.
Does Ember-1 cost the same per token as Kimi K3 on Fireworks?
Yes. Fireworks lists both at $3.00 input, $0.30 cached input and $15.00 output per million tokens on serverless. Because the rate card is identical, the claimed 40% reduction in tokens passes through to the bill rather than being offset by a premium.
Should I still be setting a fixed thinking budget on Claude?
No. Anthropic’s docs mark budget_tokens deprecated on the 4.6 models and say Claude 4.7 and later reject it with a 400 error. The supported replacement is adaptive thinking with an effort setting, which lets the model skip deliberation on easy inputs entirely.
Is cutting reasoning tokens always the right optimisation?
It depends on what a mistake costs you. Ember-1 scores higher than Kimi K3 Max on Terminal Bench 2.1 and DeepSWE 1.1 but lower on SWE-bench Verified and SWE-Interact, so less deliberation does trade against accuracy on some tasks. For routine automation the trade is clearly worth it; for client-facing work I would rather overpay.
AI-assisted research and drafting. Reviewed and published by ToolMint.