Cloudflare moved its Workers AI model retirement date from November 15 to November 20, 2026. Starting November 20, Cloudflare says calls to the listed models will return HTTP 410 Gone with error code 5028. The notice does not specify an hour. If your app depends on one of those models, switch and verify its replacement before that date.
Primary notice: planned model deprecations
Start with an exact inventory
The most important step is to find every exact model ID in use. Do not rely on approximate names or memory. Search Workers bindings, REST calls, config files, environment overrides, queue consumers, batch jobs, scheduled tasks, and any fallback logic that may call Workers AI indirectly.
- Worker bindings that point to a model ID
- Direct API calls in application code or scripts
- Wrangler, environment, and deployment configuration
- Queue and batch job handlers
- Fallback or retry paths that switch models during errors
- Any copied examples in docs, runbooks, or notebooks
Use exact matching. For example, the retiring @cf/zai-org/glm-5.3-flash is not the same as the suggested @cf/zai-org/glm-5.3. A close name is not a safe replacement. Compare full model IDs, not just family names.
Choose replacements by modality and contract
Pick a replacement based on what the workload actually needs: text generation, vision, embeddings, or another modality. Then verify the candidate in the current catalog before deployment. The safest migration is one that preserves the input and output contract your app expects, not one that simply sounds similar.
For embeddings, matching vector dimensions does not make two models compatible. Test retrieval with a separate index built from the replacement model, and send queries through that same model. Check dimensions and retrieval quality before moving production traffic.
Also note that the notice says embeddinggemma-2 is available soon. Do not assume it is already generally available unless the catalog confirms it at the time you migrate.
A practical migration checklist
- Inventory exact model IDs in all code paths and config layers.
- Map each retiring ID to a verified catalog entry that fits the same task.
- Stage the new model with representative inputs from production.
- Check response shape, output quality, latency, and actual cost.
- For embeddings, validate dimensions and retrieval behavior before reindexing broadly.
- Roll out gradually and monitor errors, throughput, and user impact after switching.
Use representative inputs, not synthetic perfection cases. A model that looks fine on a tiny demo can still fail on edge cases, prompt formats, or long-context requests. Test the real request shapes your system sends in production.
Watch the live migration carefully. Compare success rates, latency, and cost on the new model. If an application depends on a specific output schema, confirm that the new model still returns data in the shape your parser expects.
Examples of what to check
- A chat worker using @cf/zai-org/glm-5.3-flash should be reviewed for a catalog-verified substitute before November 20.
- A code path using a text embedding model should be revalidated for vector size and retrieval quality before any index rebuild.
- A queue consumer or scheduled job should be checked for hidden fallback calls that may still reference a retiring model after the main app is updated.
What not to do
- Do not wait for the cutoff date to start testing.
- Do not assume a similar model name is an acceptable drop-in replacement.
- Do not mix old and new embedding vectors in one index without a compatibility plan.
- Do not expose credentials while searching configs or logs.
- Do not plan to roll back to a retiring model after the cutoff, since it is expected to fail with 410 Gone and code 5028.
A simple operating rule
The best migration strategy is straightforward: find every exact model ID, verify each replacement in the current catalog, test on real inputs, and finish before November 20, 2026. That keeps you ahead of the deprecation window and avoids a last-minute outage.
If you are auditing a live system, start with the direct notice and then compare your codebase against the current Workers AI catalog. The sooner you confirm exact IDs, the less likely you are to discover a hidden dependency on the cutoff date.
