Model comparisons · 2026-09-25

Ember-1 context, cache, and usage cost

Long context is not unlimited permission to put everything in one call. System instructions, history, tool results, new input, and generated output share the budget. Ember-1 has a 1,048,576-token catalog context; because no separate output ceiling is published, plan against remaining context. Cache occurs automatically; do not assume sending `prompt_cache_key` creates it.

Purpose of this guide

Design the first experiment

Plan the long-context budget around the document. System instructions, history, tool results, new input, and output share the 1,048,576-token window, so remove irrelevant material and reserve room for completion.

Treat cache as a usage observation rather than a promised discount. Keep repeated prefixes stable, but do not assume `prompt_cache_key` creates a cache entry. Record cache read, uncached input, and output separately.

Application boundary

Raw rates are $3/M uncached input, $0.30/M cache read, and $15/M output. One example with 100,000 uncached input and 20,000 output is about $0.60 and contains no cache read.

Basic Ember-1 call through LLMTR

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $LLMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"fireworks/ember-1","messages":[{"role":"user","content":"Write a concise technical summary."}],"max_tokens":800}'

API limits to verify

Raw rates are $3/M uncached input, $0.30/M cache read, and $15/M output. A hypothetical 100,000 uncached-input plus 20,000-output request is about $0.60; it has no cache read. Streaming usage arrives in the final frame and reasoning can stream in `delta.reasoning_content`.

Exact streaming usage arrives in the final frame; do not charge from partial text. Reasoning can stream in `delta.reasoning_content`. Base budget alerts on completed usage and per-request caps.

Use model ID `fireworks/ember-1` and request surface `/v1/chat/completions`.
This model runs on third-party infrastructure; assess provider data policy for sensitive data.
Validate model output on the server before an application action.

Release decision and evidence

Run `moonshot/kimi-k3` as an alternative in every evaluation. LLMTR plans to retire the `fireworks/ember-1` identifier on 6 October 2026 at 00:00 Europe/Istanbul; this is not an absolute closure announced by Fireworks. For Ember-1 context, cache, and usage cost, record the test-set version, catalog capabilities, expected request shape, and unacceptable result. When a new provider response appears, preserve the example and reproduce the behavior. Collect failures, empty responses, and unexpected outputs as well as successes. A change should be measured for both user outcome and operating cost. Record minimum metadata such as request ID, model ID, latency, usage figures, and error class, without retaining prompt or response content by default. Decide in advance who may change thresholds and when rollback begins. Review results on a regular schedule rather than trusting one launch day. When the provider description changes, reread the source page and compare the catalog claim with a real request. This discipline does not hide preview uncertainty, but turns it into a product decision that can be reversed.

Compare sending a whole long document with retrieval, selection, and synthesis steps. Mark why each chosen passage relates to the question and carry its source location with the answer. This reduces context and lets a user see what supported the result.

Keep the same system instruction and long prefix when comparing cache behavior. Dates, request IDs, or random user text at the beginning can reduce reuse. A cache hit is still not guaranteed; decide from actual usage rows.

Split pre-release estimates into normal requests, long documents, heavy tool results, and retries. Calculate input, cache read, and output separately in every scenario. For the most expensive case, define a meaningful user limit or queue behavior.

Streaming can show text early, but it does not mean the job completed. After a connection breaks, check final usage and action state. Do not produce a definitive charge or success message before the usage record arrives.

At the end of the Ember-1 context, cache, and usage cost work, keep three concrete pieces of evidence: a summary of accepted and rejected examples, usage and latency measurements, and the reason for a rollback decision. This record avoids reopening the same debate at the next model update. The relevant product owner should read the results with the technical team, because a change that looks correct can affect user flow, support load, or cost budget differently. Document the condition under which the new behavior applies in short user-facing language. That keeps the catalog claim, application validation, and real operating result traceable without conflating them.

Frequently asked questions

Does cache work on every call?

No. It may occur for repeated prefixes; inspect usage for your hit rate.

What does 100k input cost?

At the uncached raw rate about $0.30; output and cache read are separate.

Is streaming cost known early?

Exact usage arrives in the final frame.