Model comparisons · 2026-09-25
Ember-1 reasoning tokens, quality, and cost
Reasoning is on by default in Ember-1 and reasoning tokens are billed at the output rate. How reasoning is switched on and off, its effect on cost with a worked example, and the tasks where it can be switched off.
Short answer
Reasoning is on by default in Ember-1. Before writing its answer the model produces a reasoning trace, and the tokens of that trace are billed as output together with the visible answer, at $15 per million tokens. An answer of a few sentences can sit on top of a much longer reasoning trace. Shortening that trace is exactly what Ember-1 is for.
Reasoning can be switched on or off per request, but its level cannot be set. This row is available until 6 October 2026; on its successor, moonshot/kimi-k3, reasoning is also on by default and is switched on and off the same way.
Switching reasoning on and off
Reasoning is controlled in two ways: with the reasoning field in the request body, or with a suffix appended to the model identifier. The table shows the options and their results.
| Setting | How it is sent | Result |
|---|---|---|
| Default | No field is sent | Reasoning on |
| Switch off | reasoning: false or fireworks/ember-1:fast | No reasoning tokens are produced |
| Switch on | reasoning: true or fireworks/ember-1:think | Reasoning on |
| reasoning_effort level | Values such as low, medium, high | 400 error; the message points to the on/off option |
Effect on cost: an example
Consider a hypothetical request: a 2,000-token prompt and a 200-token visible answer. If, with reasoning on, the model also produces a 1,500-token reasoning trace, output is 1,700 tokens. The cost is $0.006 for input and $0.0255 for output, about $0.0315 in total. With reasoning off, output stays at 200 tokens and the total falls to about $0.009.
For 1,000 requests a day the difference is $31.50 against $9. These numbers are an example; real reasoning length varies with the task and the prompt and is read from completion_tokens in the response. Still, the calculation shows that reasoning can be the largest cost item on most requests.
Where reasoning makes a difference
In work such as tagging, classification, information extraction and format conversion, the answer is usually right there in the text; similar quality can often be reached with reasoning off. In multi-step planning, code repair, calculation and decisions with interdependent conditions, reasoning can change quality markedly.
Which task falls into which group becomes visible by running the same task set in both modes: with quality scores and completion_tokens side by side, it is clear where reasoning pays for itself. Because the setting is per request, one application can use reasoning on some tasks and not on others.
In practice this is done with a small routing layer that picks the model identifier by task type: classification and extraction requests go to fireworks/ember-1:fast, planning and code requests go to fireworks/ember-1 without a suffix. Because the suffix is part of the model identifier, the split can live in configuration without touching the request body, and on the day of the move only the model name in front of the suffix changes.
Reasoning and waiting time
The reasoning trace is produced before the visible answer. In a stream, delta.reasoning_content chunks arrive first, and the visible answer starts only when reasoning ends. An interface that shows only the content field looks empty during that time; for the user, the length of the reasoning trace is the wait until the first word.
So the cost of reasoning shows not only on the bill but also in waiting time. Ember-1's shorter trace shortens that wait, and switching reasoning off almost removes it. With reasoning on, a status indicator showing that the model is working keeps an empty screen from being taken for a failure.
Reading reasoning content
In a stream, reasoning arrives in the delta.reasoning_content field, separate from the visible answer; usage information is present only in the final frame. The example below collects the two streams separately and reads completion_tokens at the end.
Reasoning content is the model's intermediate text, not a justification given to the user. Because it can repeat information from the prompt, whether it is written to logs is judged with the same care as the prompt itself.
Reading reasoning and answer separately in a stream
import os
from openai import OpenAI
client = OpenAI(base_url=os.environ["LLMTR_BASE_URL"] + "/v1", api_key=os.environ["LLMTR_API_KEY"])
stream = client.chat.completions.create(
model="fireworks/ember-1", # for no reasoning: "fireworks/ember-1:fast"
messages=[{"role": "user", "content": task}],
stream=True,
extra_body={"reasoning": True}, # already on by default; False switches it off
)
reasoning, answer, usage = [], [], None
for chunk in stream:
if chunk.usage:
usage = chunk.usage # arrives only in the final frame
if not chunk.choices:
continue
delta = chunk.choices[0].delta
if getattr(delta, "reasoning_content", None):
reasoning.append(delta.reasoning_content)
if delta.content:
answer.append(delta.content)
# completion_tokens includes reasoning tokens and is billed at the output rate.
print(usage.completion_tokens, len("".join(answer)))When moving to Kimi K3
moonshot/kimi-k3, which takes over after 6 October 2026, has the same price and switches reasoning on and off the same way; the cost calculation in this article applies there too. What changes is the length of the reasoning trace: because Ember-1 was trained to shorten it, Kimi K3 can be expected to produce more output tokens on the same tasks. Running the same task set on both models before the move shows how large that difference is in your own work.
Frequently asked questions
Is a request cheaper with reasoning off?
The output side gets cheaper, because no reasoning tokens are produced. Input cost does not change. Whether a task needs reasoning is shown by a quality comparison.
Which reasoning_effort level should I choose?
reasoning_effort levels are not supported on Ember-1 and return 400 when sent. Reasoning is only switched on or off: with the reasoning field or with the :think and :fast suffixes.
Are 40 percent fewer tokens guaranteed?
No. That is Fireworks' own evaluation. You can see the difference on your tasks by sending the same prompts to Ember-1 and moonshot/kimi-k3 and comparing completion_tokens.
Where do reasoning tokens appear in usage?
They are inside completion_tokens and are billed at the output rate. In a stream the reasoning text arrives in delta.reasoning_content and the usage information in the final frame.
Should I show reasoning content to users?
In most applications it is not needed. Reasoning content is the model's intermediate text, not a verified justification, and it can repeat information from the prompt. An indicator showing that the model is working is usually enough.