Fireworks AI Rate Limits 2026: Developer, Enterprise, On-Demand Deployments

Fireworks sits in the **open-model serverless** market alongside Groq and Together AI, but its design point is different from both. Groq optimizes for raw token-per-second speed on a narrow model menu (LPU hardware, single-digit ms TTFT, no on-demand option). Together optimizes for breadth (300+ models, several inference modes, dedicated instances). **Fireworks optimizes for the production gradient**: start cheap on serverless, graduate to on-demand H100/H200/B200 instances when your traffic outgrows shared infra — same API, same SDK, same model weights, just a routing config change.

That gradient is why Fireworks publishes its serverless models at **200-1,000+ tokens/second** for typical 70B-class models (Llama 3.3, Qwen 2.5, DeepSeek V3) — fast enough for most production workloads, but the variance is real because you're sharing the GPU pool with everyone else on that model. When you need predictable latency, you switch to on-demand. The Fireworks docs put it plainly in the on-demand deployments guide: on-demand provides 'Lower latency, higher throughput, and predictable performance unaffected by other users.'

**The single most important number to internalize**: on-demand deployments have *no hard rate limits — only limited by your deployment's capacity*. The 6,000 RPM account ceiling and per-model serverless defaults do not apply. The only ceiling is how many tokens-per-second your H100 (or H200, or B200) can physically generate. For high-volume teams, this changes the cost model entirely — you stop paying per-token and start paying per-GPU-hour × utilization.

Fireworks does not use the exact label 'Developer tier' on its docs page — the labels are **Tier 1 → Tier 4 → Unlimited**, and 'Developer' is the colloquial shorthand for everything below the sales-gated Business and Enterprise tiers. The mechanics, sourced directly from docs.fireworks.ai/guides/quotas_usage/rate-limits on 2026-06-20:

**No payment method**: **10 RPM** account-wide. This is the new-account default. You can call any serverless model, but at 10 requests per minute the throughput is for evaluation only — not production. **Tier 1** (valid payment method added): **$50 monthly spend cap**. **Tier 2** ($50 spent or pre-added in credits): **$500 monthly cap**. **Tier 3** ($500): **$5,000 monthly cap**. **Tier 4** ($5,000): **$50,000 monthly cap**. **Unlimited tier**: contact sales.

Per-model RPS and TPM **scale with your tier** — Tier 4 has materially higher per-model TPM than Tier 1 — but the exact numbers are not published per-tier on the docs page; live values appear on your account's quota dashboard at fireworks.ai/account/quotas. The widely cited default for new serverless accounts is **600 RPM per model** (≈10 RPS); the account-wide ceiling across all models stays fixed at **6,000 RPM** regardless of tier.

The Tier 4 → Unlimited jump is the one that requires a sales conversation. The other promotions are automatic on credit consumption — there is no waiting period the way OpenAI's Tier 5 has a 30-day clock. Spend $5,000 across a single day on Tier 3 and you wake up on Tier 4. The tier ladder is purely spend-gated, not time-gated.

The 'Business tier' in Fireworks' public language is the negotiated step above Tier 4 — higher per-model TPM ceilings, lifted 6,000 RPM account cap, and a named relationship with the Fireworks team. You upgrade by contacting sales directly from the console. The upgrade is reviewed manually; expected turnaround is hours to a couple of business days depending on the size of the ask.

Enterprise tier is the top of the ladder. Per Fireworks' enterprise FAQ: *'there are no quotas for Enterprise Tier.'* Enterprise customers get unlimited request capacity, dedicated infrastructure allocation, priority processing in the queue, customizable scaling policies, and enhanced support. SLA terms are negotiated per contract — Fireworks does not publish a standard enterprise SLA in the docs.

**When to actually upgrade**: if your serverless bill is consistently above $5,000/month AND your traffic pattern is steady (not bursty), you have probably crossed the inflection where **on-demand deployments are cheaper than the next tier on serverless** — even before you factor in rate-limit headroom. The per-GPU-hour math is in the next section. The Business tier upgrade only makes sense when you genuinely want to stay on serverless (because your traffic is bursty, multi-model, or experimental) and you've outgrown the 6,000 RPM account cap.

Enterprise is the path when you need named SRE support, custom SLA, security/compliance review (SOC 2 Type II, HIPAA on request), regional data-residency commitments, or you're deploying custom fine-tunes against a contracted GPU pool. Threshold: typically $20k+/month committed.

On-demand deployments are the Fireworks feature that makes the platform genuinely different from Groq and Together. You provision a dedicated GPU instance (H100, H200, B200, or B300) and the model runs only for you. **No rate limit other than the GPU's physical throughput.** Billing flips from per-token to per-GPU-hour.

**Current on-demand pricing**, sourced from fireworks.ai/pricing on 2026-06-20: **H100 / H200: $7.00/hour**. **B200: $10.00/hour**. **B300: $12.00/hour**. A100 is also available on-demand. Provisioning takes seconds to minutes via the `firectl deployment create` CLI; the deployment runs until you tear it down (or pauses automatically based on your autoscaling config).

**The break-even math** for Llama 3.3 70B Instruct: serverless billing on Fireworks for a 70B-class model lands around **$0.90 per 1M tokens** blended (the price for >16B-param text models per the public pricing page). One H100 sustaining ~1,500 tokens/sec output on a quantized 70B can produce roughly **5.4M tokens/hour** at full utilization. At $7/hour for the H100, that's an effective **$1.30 per 1M tokens** — *more expensive* than serverless if you can use only half the GPU. But run that H100 at 80%+ utilization (steady high-volume production) and you're at ~$1.60/M effective, *or* at lower throughput targets (300 tok/s sustained) it's the only way to get the latency profile.

**Where on-demand wins decisively**: (1) sustained high-volume workloads where you can hold the GPU near 70%+ utilization, (2) workloads that need predictable latency (no shared-pool variance), (3) workloads that need rate-limit headroom beyond 6,000 RPM, (4) fine-tunes and custom models not on the serverless menu. **Where serverless wins**: bursty traffic, multi-model menus, low/medium volume (under ~$2k/month spend), eval and dev workloads, anything you can't hold above 30% GPU utilization.

Deployment placement (`--region`) is fixed at creation time — you cannot move an on-demand deployment between regions in place. Plan region selection up front for data-residency or latency reasons. Multi-region failover requires two deployments.

Fireworks' specialized function-calling model is **FireFunction V2** — a tuned variant designed for structured-output and tool-calling workloads, with quality competitive with GPT-4-class function-calling at a fraction of the cost. It runs on serverless with the same 600 RPM default ceiling as other 70B-class models, plus an additional consideration: **function-calling responses are typically token-heavy on the output side** (the full structured JSON tool call), so your effective TPM utilization climbs faster than with chat completions.

There is **no separate per-call function-budget** the way some providers ration tool-use turns — Fireworks treats a function-call response as a normal completion for rate-limit accounting. But the output-token weight matters: a 5-tool-call orchestration that emits 600 output tokens per turn × 100 RPM = 60,000 TPM out, which crosses serverless tier thresholds faster than a chat workload at the same RPM.

For high-volume function-calling at scale, the on-demand path is especially attractive because FireFunction V2 is a 70B model that fits comfortably on a single H100. One H100 dedicated to FireFunction V2 gives you predictable structured-output latency, no rate limit, and clean billing — particularly important for agent loops where a single user task may fire 10-20 sequential function calls and you can't afford one of them to get throttled mid-loop.

**Image models** on Fireworks include **FLUX.1 schnell** (Black Forest Labs' fast variant), **SDXL** (Stable Diffusion XL), and several community fine-tunes. These run on a **separate quota pool** from text models — calling FLUX.1 does not consume your Llama 3.3 RPM budget, and vice versa. The serverless image throughput target is on the order of 1-3 seconds per 1024×1024 image on FLUX.1 schnell. For high-volume image generation (catalog precompute, programmatic media), the on-demand path is typically cheaper above ~5,000 images/day because image models hold a single GPU well.

**Embedding models** also run on a separate quota. Pricing, sourced from fireworks.ai/pricing 2026-06-20: **embedding models up to 150M parameters → $0.008 / 1M input tokens**. **150M-350M params → $0.016 / 1M**. **Qwen3 8B → $0.10 / 1M**. **nomic-embed-text-v1.5** at 137M params falls in the cheapest bucket at $0.008/M — competitive with OpenAI's text-embedding-3-small. For large retrieval index precompute (10B+ tokens), nomic-embed-text on Fireworks serverless is one of the cheapest options on the open-model market.

Both image and embedding quotas scale with your spending tier the same way text-model quotas do. The 6,000 RPM account ceiling still applies, but in practice embeddings and images rarely hit it because each call is more compute-intensive than a chat completion.

**FireOptimizer** is Fireworks' label for the quantized and distilled variants of frontier open models that ship on the platform. The typical pattern: Fireworks takes a 70B model (Llama 3.3, Qwen 2.5, DeepSeek V3), produces **FP8** or **INT4** quantized versions, plus speculative-decoding-paired smaller drafter models, and serves both the full-precision and the optimized variants on serverless.

**The tradeoff**: optimized variants run 1.5-3× faster (200 tok/s baseline → 400-600 tok/s on quantized) at typically 5-15% quality regression on most benchmarks. For chat, summarization, and structured-output workloads the quality regression is usually invisible. For complex reasoning, math, and long-context tasks the regression matters and you stay on full precision.

**Cost impact**: optimized variants are priced at the same per-token rate as the full-precision model on Fireworks serverless — you get the speed boost free. The economics shift entirely on on-demand deployments, where a quantized 70B fits on a smaller GPU (or runs at higher tokens-per-second on the same GPU), which directly drops your per-GPU-hour effective cost-per-million-tokens. **For production at scale, the right answer is almost always: deploy the quantized variant on-demand, route quality-sensitive traffic to a smaller on-demand pool of the full-precision variant.**

Fireworks returns **two different rate-limit-adjacent error codes** and the correct retry strategy depends on which one you see. From the rate-limits docs: *'If you receive HTTP 429 on those endpoints, it typically means deployment saturation (GPUs busy) rather than hitting a TPM tier cap.'* This is the opposite of what most provider docs imply by 429.

**HTTP 429 on Fireworks serverless = deployment saturation** (the shared GPU pool is busy serving other users). Retry with exponential backoff and jitter — the issue usually clears within seconds as load rebalances. This is *not* a signal that you need to upgrade your tier; it's a transient capacity squeeze on the shared pool.

**HTTP 429 explicitly with a tier-cap message = you hit your TPM or RPM ceiling**. Now the fix is either upgrade your spending tier (add credits to promote), or switch the workload to on-demand. Read the error body — Fireworks distinguishes the two cases in the message.

**HTTP 503 = service unavailable**, typically the entire model endpoint is unreachable (deployment cold-start, brief platform issue). Retry with longer backoff (15s, 30s, 60s). If it persists more than a couple of minutes, check status.fireworks.ai before assuming it's your problem.

**Production retry pattern**: exponential backoff with jitter capped at 60s for 429, longer capped at 120s for 503. Token-bucket client-side throttle at 80% of your account RPM ceiling to avoid hitting tier caps in steady state. For latency-sensitive workloads, run a small on-demand deployment as overflow — serverless first, on-demand on 429 — and you get the best of both cost models.

All three platforms serve roughly the same model menu (Llama family, DeepSeek, Qwen, Mixtral, FLUX). The differences are in *how* they serve.

**Groq** wins on raw latency. Single-digit-ms TTFT, 800-2,000 tok/s on Llama family thanks to LPU hardware. **No on-demand option** — you're on shared serverless and that's it. Free tier and paid tier; rate limits are a hard ceiling per tier with no per-account negotiation below enterprise. Best for: latency-critical real-time UX (voice, sub-second agent loops), low-to-medium volume.

**Together AI** wins on breadth. **300+ models** including community fine-tunes, multiple inference modes (chat, batch, embeddings, vision), dedicated instances available, fine-tuning service. Rate-limit structure similar to Fireworks but the per-model menu is broader. Best for: experimentation, RAG with diverse model picks, teams that need a custom fine-tune deployed alongside frontier base models.

**Fireworks** wins on the **gradient from serverless to dedicated**. Same SDK, same model, same prompts work on both modes — the switch is a routing config change. On-demand pricing ($7/hr H100, $10/hr B200) is competitive with hyperscalers, and the 'no rate limit' on on-demand is the cleanest production guarantee on the market. Best for: teams that start on serverless and need a real path to scale without re-architecting, function-calling workloads (FireFunction V2 is unique), production agents.

**The real-world decision**: pick Groq for voice / sub-second loops; pick Together for breadth and fine-tunes; pick **Fireworks for anything you expect to scale into the >$5k/month bracket** because the on-demand escape hatch is what you'll need on day 90.

The tier ladder ($50 / $500 / $5,000 / $50,000 monthly caps, 10 RPM unpaid → 6,000 RPM paid account ceiling) is sourced from docs.fireworks.ai/guides/quotas_usage/rate-limits, fetched 2026-06-20. The on-demand pricing ($7/hr H100/H200, $10/hr B200, $12/hr B300) and embedding pricing ($0.008/M up to 150M params) come from fireworks.ai/pricing, same date.

The **600 RPM per-model serverless default** is the widely-cited Fireworks baseline, referenced consistently across community write-ups and Fireworks' own blog content. Per-model exact RPS/TPM values do not appear in the public rate-limits doc as static numbers — they scale with your account tier and are visible on your live account quota dashboard. We've shown them in the table as `~10 RPS (600 RPM default)` to be clear they are the default, not a contractual fixed ceiling.

The **Enterprise 'no quotas' language** is sourced directly from Fireworks' enterprise quota FAQ.

**Live-verify when you budget**: open fireworks.ai/account/quotas (logged in) and confirm your current per-model RPS, TPM, and account RPM ceiling. The dashboard reflects any sales-negotiated increases (Business / Enterprise) that wouldn't appear in the public docs.

**Live-verify pricing**: fireworks.ai/pricing and docs.fireworks.ai/serverless/pricing update independently of the rate-limit ladder. The MoE pricing tier (DeepSeek V3 is a 671B-param MoE, only ~37B active per token) is priced differently from dense models — check the live page when modeling per-token cost.

**Why this page exists**: ChatGPT and Perplexity searches for 'Fireworks rate limits' currently surface a mix of Fireworks' docs, community forum threads, and aggregator review sites. The numbers vary across those sources because Fireworks updated the tier ladder in late 2025 and several third-party pages still cite the old structure. This page is the canonical, dated, sourced reference. If you arrived here via an AI engine, that mechanism is working.