Model comparisons · 2026-09-25

Ember-1 reasoning tokens, quality, and cost

A short visible answer does not mean a low bill because reasoning tokens can contribute to output cost. Reasoning is enabled by default in Ember-1, so measure quality and cost in one experiment. The goal is not disabling reasoning everywhere: simple labeling may work without it while code repair or multi-step planning can show a quality difference.

Purpose of this guide

Design the first experiment

Compare reasoning-on and reasoning-off runs with the same task set. Separate classification, code repair, and multi-step planning, and include reasoning tokens in output cost even when the visible answer is short.

Measure more than correctness: missing rationale, persuasive errors, overly long solutions, and tail latency all matter. Use blind scoring and inspect task-level differences rather than letting one average decide the release.

Application boundary

Try `reasoning: false` or `:fast`, but do not present effort labels as a guaranteed cost dial. The reliable experiment compares the enabled and disabled paths on representative work.

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

Reasoning tokens are billed as output. Disable them with `reasoning: false` or the `:fast` suffix. Do not recommend `low`, `medium`, `high`, and `max` as an ordered cost dial; reliable support is the on/off decision.

Separate input, cache read, and output in accounting. A prompt can improve quality while increasing output, so evaluate cost per successful task and roll back a prompt or model route when the budget threshold is crossed.

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 reasoning tokens, quality, and 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.

Set a quality goal and maximum acceptable cost for each job. A support draft may only need correct routing, while a code review fails on an incorrect security suggestion. This makes clear why one reasoning setting cannot produce the same result in every product.

Keep visible completion tokens and reasoning usage in separate report columns. One version can write shorter text while using more reasoning tokens. Looking only at answer length hides the relationship between user experience, price, and latency.

Do not change the prompt and model setting together. First run enabled and disabled reasoning with the same prompt, then change context or instructions. You can then explain which decision caused the quality difference.

For an unexpected cost increase, inspect the usage record: long input, growing output, cache-hit rate, or retries may be responsible. Per-task caps are more useful than one broad limit because they avoid cutting valuable expensive requests.

At the end of the Ember-1 reasoning tokens, quality, and 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

Is disabled reasoning cheaper?

The related output cost can fall, but total cost also depends on input and visible completion tokens.

Which effort level should I select?

Compare default and disabled modes on your tasks.

Are 40 percent savings guaranteed?

No. It is Fireworks' own evaluation; measure your workload.