Microsoft Foundry Fireworks models retirement: what 1 July 2027 means

Summary. From at least 5 August to 12 October 2026, Microsoft's Foundry retirement schedule listed 13 Fireworks-hosted models as generally available with a retirement date of 1 July 2027. By 5 November that table had gone, although the page still shows its 23 September update date. It now carries only a warning that pay-per-token Fireworks models get 15 days' notice and a link to the Fireworks model catalogue. The catalogue shows the pay-per-token offering for five of the 13 already retired between 1 June and 7 August 2026, six more offered only on provisioned throughput (PTU), and two, FW-MiniMax-M2.5 and FW-Qwen3-14B, not listed at all. Eleven remain deployable on PTU, which carries 12 months' notice and no published dates. Treat 1 July 2027 as a date Microsoft has removed, not a guarantee. Your options are newer Fireworks models such as FW-DeepSeek-V4.1-Flash, FW-GLM-5.3 and FW-Kimi-K3, PTU on your current model, Azure-sold models such as DeepSeek-V4-Pro (retiring 20 February 2028), or your own weights on Fireworks PTU. Fireworks Data Zone deployments exist only in the US, and the service is excluded from the EU Data Boundary.

About this article. This is for platform and AI engineering teams running FW- models on Microsoft Foundry. On 7 November 2026 we checked every model name, date, PTU parameter and price against Microsoft Learn (live and archived copies of the retirement schedule, plus the Fireworks catalogue, enablement, import, privacy and lifecycle pages), the Azure Retail Prices API, Fireworks AI's documentation and AWS's Bedrock pages, without querying a live subscription. Microsoft revises these pages often, so re-check before you act. This is not legal or procurement advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What changed between March and November 2026

The 1 July 2027 date was the second retirement date Microsoft published for these models. Archived copies of the schedule and Microsoft's launch post give this sequence.

Microsoft's public docs repository showed the same 13 rows in archived copies up to 1 October 2026, and returned a not-found error on 7 November.

The catalogue explains the divergence. Its pay-per-token dates apply only to pay-per-token deployments, a model can stay on PTU after its pay-per-token offering ends, and PTU customers get 12 months' notice before a PTU offering retires. It dates the end of pay-per-token for FW-Kimi-K2.5, FW-GPT-OSS-120B and FW-DeepSeek-V3.2 to 1 or 2 June 2026, while the schedule still showed them as previews running to 1 July 2026.

1 July 2027 is a year after that preview date, which fits the 12-month lifecycle Microsoft gives GA Fireworks models instead of its standard 18 months, but Microsoft has not explained the date or its removal. The same policy promises at least 60 days' notice for GA retirements and says dates can't be extended; the Fireworks pages set 15 days for pay-per-token, down from 30 in the launch post. Plan for 15. Our AI model retirement policies comparison sets this against AWS, Google, OpenAI and Anthropic.

The 13 models: status on 7 November 2026

PTU figures are minimum deployment, scale increment and input tokens per minute (TPM) per PTU, and every PTU row below supports both Global Provisioned and Data Zone Provisioned.

Eleven of the 13 remain deployable on PTU; none remains deployable pay-per-token. If you built on FW-Kimi-K2.5 or FW-GLM-5.1 pay-per-token in early 2026, that path closed months before the date many teams wrote in their calendars.

Newer per-token models turn over just as fast. FW-Kimi-K2.6, FW-Kimi-K2.7-Code and FW-Inkling lost pay-per-token on 25 September 2026, and FW-GLM-5.2, FW-DeepSeek-V4-Pro and FW-DeepSeek-V4-Flash-0731 on 8 October. FW-GLM-5.2-Fast still shows as GA with a 29 October 2026 retirement date that has passed, so treat that row as stale.

Deployment types: why one model has two retirement dates

Fireworks on Foundry sells the same model through two offerings, each with its own notice, quota and Region rules.

Two points trip teams up. First, Microsoft's general policy auto-upgrades Global Standard and Data Zone Standard deployments to a named replacement at retirement, and never auto-upgrades Provisioned deployments. The Fireworks catalogue does not say that rule covers FW- deployments, and four of the five retired models among the 13 had no replacement named, so build your own cutover. Second, Fireworks adaptive limits can sit below your quota and grow with usage, so a cold cutover can hit HTTP 429 errors even with quota approved. Ramp traffic and retry with exponential backoff.

Replacement options on Foundry

Option 1: newer Fireworks pay-per-token models

The catalogue lists seven GA pay-per-token models with no retirement date.

This is the easiest move and the riskiest to keep: the same 15-day notice applies, several FW- models retired within months of launch, and Microsoft positions Fireworks as early access to open models, often before Azure sells them. Use it for experiments and burst traffic, with a second model tested behind a gateway.

Option 2: stay on the same model with PTU

If your evals are tuned to FW-Kimi-K2.5, FW-GLM-4.7 or FW-Qwen3.5-397B-A17B, PTU keeps the exact model with 12 months' notice. The trade-off is commitment and size: FW-DeepSeek-V3.2 and FW-GLM-5 need at least 1,080 PTUs, while FW-GPT-OSS-120B starts at 50. Microsoft's lifecycle FAQ calls PTU capacity model-agnostic and movable between provisioned managed deployments; confirm that this holds for Fireworks before you size around it. Unless Service Health already shows a PTU retirement notice, the 12-month rule means one announced now could not take effect before November 2027.

Option 3: models sold directly by Azure

Several of the same families are sold by Azure itself.

DeepSeek GA models sit on the same 12-month partner lifecycle as Fireworks, but GA retirements get at least 60 days' notice, and previews at least 30 days with possible force-upgrades. This is still a migration: new deployment, new model string, fresh evals. Note the odd row: the named replacement for DeepSeek-V4-Flash is a preview that retires on 3 December 2026. For a GA target with a long runway, DeepSeek-V4-Pro and DeepSeek-V4-Flash run to February 2028.

Option 4: bring your own weights onto Fireworks PTU

Fireworks on Foundry can import custom weights and serve them on provisioned capacity. The enablement guide lists supported architectures as Kimi K2, K2.5 and K2.6, GLM 4.7 and 4.8, gpt-oss-120b, and four Qwen 3.5 sizes up to 397B; the import guide says weights must match a supported Fireworks base model and points to the PTU table for the current list. That covers most of the retiring list. Import runs through the Azure Developer CLI models extension (azd ai models create), a project can run only one active deployment of the same imported model at a time, and LoRA adapters are in preview. You control the weights; Fireworks controls which architectures it supports.

Option 5: leave Foundry

Going direct to Fireworks AI means a separate account; Microsoft's FAQ says deployments do not carry over from Fireworks AI to Foundry, so plan to rebuild either way. Amazon Bedrock lists Kimi K2.5, DeepSeek V3.2, gpt-oss-120b, MiniMax M2.5 and GLM 5.3, but retires Kimi K2 Thinking, GLM 4.7, DeepSeek-V3.1 and MiniMax M2 on 30 March 2027; see our Bedrock open-weight retirement guide.

Decision table

Worked example: PTU sizing and list price when you change model

PTU count is the cost driver. The Azure Retail Prices API lists one Fireworks PTU meter for all FW- models: $1.00 per PTU-hour for Global Provisioned and $1.10 for Data Zone Provisioned in US Regions. Assume a steady 500,000 input tokens per minute. Required PTUs equal input TPM divided by input TPM per PTU, rounded up to the model's minimum and then to its scale increment, using the catalogue figures. Prices are Global unless the row says Data Zone.

Over a 730-hour month, moving from FW-Kimi-K2.5 to FW-Kimi-K3 cuts 1,800 PTUs to 508, about 72% fewer, and list cost from $1,314,000 (1,800 × $1.00 × 730) to $370,840 (508 × $1.00 × 730). FW-DeepSeek-V3.2 to FW-DeepSeek-V4.1-Flash drops 1,080 PTUs to 46, or $788,400 to $33,580 a month. These are list rates before any agreement discount; ask whether Foundry PTU reservations cover Fireworks. Input TPM per PTU ignores output-heavy workloads, and Microsoft says to benchmark with representative traffic before final sizing.

Data residency, compliance and India notes

Fireworks-specific limits. Fireworks on Foundry is excluded from EU Data Boundary commitments, has not achieved FedRAMP, is not applicable for PCI DSS and is not available in Azure Government, and Microsoft does not evaluate the safety or Responsible AI characteristics of these models. Customer data leaves Microsoft facilities because inference runs on Fireworks GPUs, with Fireworks acting as a Microsoft subprocessor under the Product Terms and Data Protection Addendum. Data at rest stays in the Region you deploy in, model providers get no customer data, and the service lacks SOC 1 Type 2 and HITRUST coverage.

India. Data Zone covers only the US, so an Indian team uses Global Standard or Global Provisioned, which may process inference data in any Azure Region. If your DPDP assessment or a sector regulator expects in-country processing, Fireworks on Foundry does not offer it today. The privacy FAQ says the service is currently available in the US, while the catalogue lists Global deployments in all global Azure Regions, so confirm support for an Indian Region with your account team. Re-run the assessment at migration time; our DPDP engineering playbook covers the controls.

EU and UK. With the EU Data Boundary excluded and no EU data zone, EU teams with residency obligations should look at Azure-sold models or another provider.

US. US teams get both Global and Data Zone options, but several replacements are single-type: FW-Kimi-K3 and FW-DeepSeek-V4.1-Flash PTU are Global only, while FW-MiniMax-M3 per-token is Data Zone only.

Migration steps

1. Inventory FW- deployments in every subscription. Catalogue models carry the FW- prefix; imported weights use the FireworksCustom model format.

            az cognitiveservices account deployment list \
  --name "<foundry-resource>" --resource-group "<resource-group>" \
  --query "[?starts_with(properties.model.name, 'FW-') || properties.model.format=='FireworksCustom'].{deployment:name, model:properties.model.name, sku:sku.name, capacity:sku.capacity}" \
  -o table
          

1. Classify each deployment. GlobalStandard or DataZoneStandard means 15-day exposure; GlobalProvisionedManaged or DataZoneProvisionedManaged means 12 months' notice.

1. Set alerts and a weekly check. Create an Azure Service Health alert filtered to Azure OpenAI Service, the name Microsoft uses for Foundry alerts, and compare the Fireworks catalogue with last week's copy. Fifteen days rules out a monthly review.

1. Pick two targets per workload and build a golden set of real prompts with expected outputs.

1. Evaluate side by side for accuracy, format, tool calls, latency and cost per task.

1. Secure capacity. For per-token, use Microsoft's Fireworks quota request form; for PTU, size with the arithmetic above and confirm quota before deploying.

1. Check API routes. Besides the Foundry Responses API, Fireworks models offer a passthrough route at /providers/fireworks/v1/responses where Fireworks, not Foundry, handles sessions. Test the route production uses.

1. Keep prompt caching working. Set x-session-affinity, user or prompt_cache_key consistently on the new deployment; prompt_cache_key wins when both it and user are set.

1. Cut over behind a stable alias. Point application config at a deployment name or gateway route so the next swap is a config change; see our AI gateway comparison.

1. Delete old deployments once traffic has moved and rollback is no longer needed.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our LLM migration and cost optimisation service audits FW- deployments, sizes PTU against per-token options and moves workloads to a tested replacement behind a gateway with rollback. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Model retirement schedule, archived 12 October 2026 — Microsoft Learn via Internet Archive

1. Model retirement schedule, archived 5 November 2026 — Microsoft Learn via Internet Archive

1. Model retirement schedule, Microsoft Foundry, updated 23 September 2026 — Microsoft Learn

1. Fireworks model catalog, deployment types, and regions in Microsoft Foundry, updated 14 October 2026 — Microsoft Learn

1. Import custom models with Fireworks, updated 29 October 2026 — Microsoft Learn

1. Fireworks models on Microsoft Foundry, updated 20 October 2026 — Microsoft Learn

1. Announcing Fireworks AI on Microsoft Foundry, 11 March 2026, archived 11 June 2026 — Microsoft Tech Community via Internet Archive

1. Model retirement schedule, archived 7 June 2026 — Microsoft Learn via Internet Archive

1. Model retirement schedule include file, azure-ai-docs repository, archived 1 October 2026 — Microsoft Docs on GitHub via Internet Archive

1. Foundry Models lifecycle and support policy, updated 24 July 2026 — Microsoft Learn

1. Serverless rate limits — Fireworks AI Docs

1. Models at a glance — Amazon Bedrock User Guide, AWS

1. Model lifecycle (Legacy) — Amazon Bedrock User Guide, AWS

1. Azure Retail Prices API, Azure Fireworks Models provisioned meters, read 7 November 2026 — Microsoft

1. Fireworks on Microsoft Foundry privacy and compliance FAQ, updated 28 September 2026 — Microsoft Learn

1. Understanding deployment types in Microsoft Foundry Models, updated 12 August 2026 — Microsoft Learn

1. Prompt caching — Fireworks AI Docs