# Fireworks Rune Decision API: Input-Only Pricing and Request Limits

Fireworks adds Rune 26B-A4B to Serverless for typed decisions. Check input-only pricing, supported APIs, question limits and the text-only restriction.

By Paras Madan | 2026-10-28


Fireworks has added Rune 26B-A4B to Serverless, giving developers a hosted way to classify text and score options without generating a written answer. The October 27 announcement brings input-only billing and a decisions API that can answer many questions about the same document in one request.

That makes it relevant to applications that need a routing decision, a document label or a score. A support system, for example, might need to identify the request type and urgency before choosing which workflow should handle the ticket.

## What the Fireworks release adds

The [Fireworks changelog](https://docs.fireworks.ai/updates/changelog) identifies Rune as a System One decision model. Send a document and typed questions, and the service returns probabilities rather than a generated explanation. The hosted endpoint accepts text only and does not support reasoning.

This is an availability update for an existing model. The [Fireworks model listing](https://app.fireworks.ai/models/fireworks/rune) has an October 20 creation date, while the changelog announces Serverless availability on October 27. It lists the model identifier as `accounts/fireworks/models/rune` and marks training and image input unsupported.

Developers comparing providers should preserve that distinction. A model family can support capabilities that a particular hosted deployment does not expose.

## Pricing starts at $0.042 per million input tokens

The [official Serverless price table](https://docs.fireworks.ai/serverless/pricing) lists $0.042 per million uncached input tokens and $0.0084 per million cached input tokens. Output is $0 because the service generates no output tokens. Rune runs on US capacity without an additional US-capacity premium; the table does not list a Priority rate.

At those published rates, 100 million entirely uncached input tokens would cost $4.20. That is arithmetic from the price table, not a measured application cost. Actual consumption depends on the text and questions sent, caching and the number of requests.

The useful comparison is the total cost of an accepted decision. A cheap classifier that sends too many cases to the wrong team can create more work downstream than it saves at the API layer.

## Use the decisions endpoint, not chat completions

Fireworks' [System One API reference](https://docs.fireworks.ai/api-reference/post-systemone) supports `/inference/v1/systemone` and the OpenAI-compatible `/inference/v1/decisions` shape. Chat completions and completions requests to this model return an error. The model page's generic chat example should not be used for this integration.

A request can contain up to 256 questions. Multiple-choice questions allow up to 208 options; ordinal scores take two to ten levels. The API documentation lists a 256K-token context limit, 16K tokens of question text, a 4 MiB state and an 8 MiB request body. Requests time out after five minutes.

Questions share one read of the state. The state can be cached across requests, while the questions are not. Grouping related questions is therefore worth testing before designing an application around separate calls for every label.

## Validate the probability before automating the action

Fireworks describes the returned probabilities as calibrated. Check that against the application's own examples before using a confidence threshold to automate a workflow. A probability returned by the API is an estimate, not a guarantee that a particular decision is correct.

For a ticket router, keep a reviewed sample of clear cases and ambiguous ones. Compare the predicted probabilities with actual outcomes, then choose when to route automatically and when to request review. Keep the decision separate from any irreversible action.

Rune's attraction is a small, explicit API result at a low published token price. Its usefulness depends on whether those decisions remain dependable on the documents your application actually receives.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain AI APIs through clear pricing, integration examples and limitations that developers can use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).