Model comparisons · 2026-09-25
Ember-1 context, cache, and usage cost
Ember-1's 1,048,576-token context window, its automatic prompt cache and its three price items: uncached input, cache read and output. How the cache is triggered, how the cost of a request is calculated, and when usage arrives in a stream.
Short answer
Ember-1's context window is 1,048,576 tokens, with no separate output ceiling below it. Cost has three items: uncached input at $3 per million tokens, input read from cache at $0.30, and output at $15. Repeated prompt prefixes are cached automatically; no separate key needs to be sent for that.
This row is available until 6 October 2026. Its successor, moonshot/kimi-k3, has the same prices and the same context window, so the calculations below still apply after the move.
Price items
The prices in the catalog are the provider's prices; the platform margin is not added to model prices and applies only when topping up credit. Reasoning tokens fall under the output item.
| Item | Price | What it covers |
|---|---|---|
| Uncached input | $3.00 | The part of the prompt not read from cache |
| Cache read | $0.30 | A prefix identical to an earlier request |
| Output | $15.00 | The visible answer and reasoning tokens |
How the cache comes into play
The cache works for the part of the prompt that is identical, from the start, to an earlier request. That makes ordering matter: parts that do not change, such as the system instruction, a long document and tool definitions, go first, and the question that changes with every request goes last. A timestamp or request number added at the start keeps everything after it from being read from cache.
The number of tokens read from cache appears in the usage field of the response as cached_tokens. The cache is not guaranteed on every request; when a long time passes between requests with the same prefix, or the prefix changes, full price is paid. The real rate is seen by watching that field.
The same principle applies to multi-turn conversations. Because the earlier messages are sent unchanged from the start on every new turn, the conversation history can largely be read from cache and full price is mostly paid only for the latest turn. Trimming or summarising the history changes the prefix; the first request after that benefits less from the cache.
An example calculation
Consider a 100,000-token prompt: 90,000 tokens are identical to an earlier request and read from cache, 10,000 tokens are new. The model produces 2,000 tokens of output. The table compares this request with and without cache; the numbers are an example.
In the cached request the two largest items are the new input and the output. With reasoning on, reasoning tokens are added to the output, so even in long-document work the output item can make up a large share of the total. If 50 questions a day are asked about the same document, the difference the cache makes in this example is about $12 a day.
| Item | With cache | Without cache |
|---|---|---|
| Cache read | 90,000 tokens: $0.027 | None |
| Uncached input | 10,000 tokens: $0.030 | 100,000 tokens: $0.300 |
| Output | 2,000 tokens: $0.030 | 2,000 tokens: $0.030 |
| Total | $0.087 | $0.330 |
Calculating cost from the response
In a stream, usage information arrives only in the final frame, just before the [DONE] marker; that frame is present whether or not stream_options is sent. So the exact cost of a request is known when the answer completes. The example below builds the prompt in a cache-friendly order and calculates the cost from the usage in the final frame.
A cache-friendly prompt layout and cost from usage
PRICE_PER_M = {"input": 3.00, "cache_read": 0.30, "output": 15.00}
def cost_usd(usage: dict) -> float:
cached = (usage.get("prompt_tokens_details") or {}).get("cached_tokens") or 0
fresh = usage["prompt_tokens"] - cached
return (fresh * PRICE_PER_M["input"] + cached * PRICE_PER_M["cache_read"]
+ usage["completion_tokens"] * PRICE_PER_M["output"]) / 1_000_000
# Fixed parts first, the changing question last: the prefix stays the same across requests.
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": LONG_DOCUMENT},
{"role": "user", "content": question},
]
stream = client.chat.completions.create(model="fireworks/ember-1", messages=messages, stream=True)
usage = None
for chunk in stream:
if chunk.usage:
usage = chunk.usage.model_dump() # arrives only in the final frame
# ... answer chunks are handled here
print(round(cost_usd(usage), 6))Watching the cache rate
Whether the cache is actually working is seen by looking at the ratio of cached_tokens to prompt_tokens on each request. In a flow that asks questions about the same document this ratio should be high; if it is low, the prefix is changing from request to request. The most common causes are a date and time added at the start of the prompt, user-specific information written into the system instruction, and tool definitions changing order.
Tracking daily cost split into the three items shows which one is growing. Growth in uncached input points to a change in the prefix; growth in output points to longer answers or reasoning traces.
Using the long context
A one-million-token window does not mean everything belongs in one request. The system instruction, conversation history, tool results, new input and the output to be generated share the same window. When many questions are asked about one long document, keeping the document in the fixed prefix and adding the questions at the end lowers both cost and waiting time thanks to the cache.
Because there is no separate output ceiling, max_tokens can be set up to the rest of the window; but output is the most expensive item. A limit at the length the task needs keeps an unexpectedly long answer from inflating the cost.
Frequently asked questions
Do I need to send prompt_cache_key for caching?
No. On Ember-1 repeated prefixes are cached automatically. The number of tokens read from cache appears in the usage field as cached_tokens.
Does Ember-1 have an output ceiling?
There is no separate output ceiling below the context window. Prompt and output together cannot exceed 1,048,576 tokens; max_tokens is limited to what the task needs.
When is the cost known in a stream?
Usage information arrives in the final frame, before the [DONE] marker. The exact cost is calculated when the answer completes.
Does cost change after moving to Kimi K3?
Prices and context are the same. What can change is the token count: a longer reasoning trace from moonshot/kimi-k3 on the same task can raise the output item.
Are cached tokens billed twice?
No. cached_tokens is part of prompt_tokens. The part read from cache is billed at $0.30 and the rest at $3; the same token is never counted in both items.