Fireworks AI Will Remove Seven Serverless Model Routes on September 25

Action deadline: Fireworks AI says seven older model routes will stop working on its serverless endpoints after September 25, 2026. Dedicated deployments are not affected.

The September 12 Fireworks AI changelog names the affected models and recommended replacements. The short notice makes this an operations story, not just a model-catalog update: teams need to identify the exact endpoint type, test output compatibility and deploy new model identifiers before traffic reaches a dead route.

The migration matrix

First determine whether the deadline applies to you

The change applies to serverless endpoints, including Fast and US-only serverless variants where those exist. Fireworks explicitly says dedicated deployments are unaffected. A model name in a configuration file is not enough to decide impact; inventory the serving product and route used in production.

• Search application settings, environment-specific configuration and fallback lists.
• Inspect traffic dashboards for calls to the seven model identifiers.
• Separate serverless endpoints from dedicated deployments.
• Find scheduled jobs and rarely used disaster-recovery paths, not only the main API client.

A replacement name does not guarantee behavioral compatibility

Fireworks says DeepSeek V4.1 Flash outperforms DeepSeek V4 Pro (0813) on official benchmarks and carries the same vision capability as the experimental vision route. That is a provider claim about benchmark and feature coverage. It does not prove that an application’s prompts, tool calls, refusal patterns, token use or latency distribution will remain unchanged.

For DeepSeek users, our DeepSeek V4.1 Flash guide tracks the newer model’s identity, cache pricing and agent benchmark claims. The separate DeepSeek V4 Pro 0813 price analysis explains why a workload built around a Pro route needs its own cost and quality comparison.

The two-choice Kimi migration needs a decision rule

Kimi K2.6 and Kimi K2.7 Code each have two recommended destinations: GLM 5.3 or Kimi K3. Teams should not select by model recency alone. Use a small, versioned evaluation set that reflects the actual workload, then score correctness, structured-output validity, p95 latency, token consumption and human correction time.

A provider migration recommendation is the start of a compatibility test, not the end of one.

A safe migration runbook for the next twelve days

1. Freeze a representative set of inputs and expected outputs today.
2. Run the old and recommended routes side by side with identical parameters.
3. Review tool-call JSON, multimodal payloads, safety behavior and long-context cases.
4. Deploy the replacement behind a percentage-based or tenant-based switch.
5. Keep an explicit rollback path that does not point to another retiring route.
6. Remove the old identifier before September 25, then test every scheduled and fallback path.

What to monitor after the cutover

Track HTTP errors, invalid structured outputs, tool-call retries, first-token latency, full-response latency, tokens per successful task and human escalation. A migration can look healthy at the transport layer while quietly increasing correction work. Keep old and new metrics separated by model identifier so the cutover is visible.

Bottom line

The September 25 cutoff is narrow but real: serverless users of seven named models must move, while dedicated deployments stay in place. The operational risk is not difficult model selection by itself. It is the forgotten fallback, scheduled task or multimodal payload that nobody exercises until the old route disappears.

Primary source

• Fireworks AI changelog: September 12, 2026 serverless deprecation notice

Checked September 13, 2026. Deadline, scope, replacements and benchmark statements are attributed to Fireworks AI. MustHave.ai has not independently benchmarked the recommended models.