What Happens When Cloudflare Retires a Workers AI Model, and How Flarepipe: Chat Handles It
Cloudflare’s Workers AI catalog is not a fixed list. New models arrive, older ones are marked deprecated with a notice period, and eventually they are removed. For a chatbot that is good news in the long run and a hazard in the short run: the day a model identifier stops resolving, a bot that was built around it starts failing, and unless something is watching, nobody finds out until a visitor does.
This matters more for a plugin than for a hosted service. A SaaS chatbot swaps its model in one deploy. Flarepipe: Chat runs inside each site owner’s own Cloudflare account, with no connection back to us, so there is no central switch to flip and no way for us to hot-fix thousands of installs at once. The design has to assume retirements will happen and make them survivable from the site owner’s side.
Three models, three settings
The plugin uses three Workers AI models, and all three are settings rather than values baked into the code. Under Flarepipe Chat > Settings you will find them as free-text fields that accept any Workers AI model identifier, so you are never waiting on a plugin release to use a model that exists today.
| Role | Default |
|---|---|
| Answering | @cf/meta/llama-4-scout-17b-16e-instruct |
| Fallback | @cf/meta/llama-3.3-70b-instruct-fp8-fast |
| Embedding | @cf/google/embeddinggemma-300m |
The answering model writes the replies. The fallback is tried when the answering model fails. The embedding model turns text into vectors, both when your content is indexed and when a visitor’s question is matched against it. The embedding model is the one where a retirement needs more than a settings change, covered below.
What happens at the moment of failure
The Worker tries the answering model first. If the call errors, which is what a removed model does, it logs the error and tries the fallback before giving up. With the defaults, a visitor asking a question on the day Llama 4 Scout is retired gets an answer from Llama 3.3 70B instead and never knows anything happened. That buys time without fixing anything, and it does not help if the retirement takes both models, or if it is the embedding model that went.
So the second half of the design is detection. Once a day, a scheduled check exercises the Worker and its bindings, including a probe that runs the embedding model, so an embedding retirement surfaces in the health check rather than in front of a visitor. When something fails, the plugin raises a WordPress admin notice with the detail and a link to the settings screen, and the Run diagnostics button on that screen gives you the same report on demand. The models page describes both mechanisms.
A chatbot that stopped working without anyone noticing is worse than one that never launched, and the daily check is there so that somebody notices.
What to do when the notice appears
For a retired answering or fallback model, it is a five-minute job:
- Read the admin notice, or press Run diagnostics in Flarepipe Chat > Settings, to confirm which model failed.
- Check Cloudflare’s Workers AI model catalog for a current replacement. The deprecation notice usually names one.
- Put its identifier in the answering model field (or the fallback field) and save. Saving redeploys the Worker with the new configuration; there is nothing else to restart.
- Ask the bot a question on the front end, or run diagnostics again, to confirm it is answering.
Your index is untouched by any of this. Changing the model that writes answers has no effect on the vectors that find them.
When it is the embedding model
This is the case that needs care. The embedding model and the Vectorize index are welded together: the index was created with 768 dimensions to match the default model, and every stored vector was produced by that model. If you switch to a different embedding model and do nothing else, new questions are embedded one way and compared against content embedded another way. Nothing errors. Retrieval returns the wrong passages and nobody gets a warning.
So an embedding change always ends with Rebuild index, on the settings screen. It deletes the index, recreates it at the size the new model needs, and re-indexes everything through the usual background batches. It asks you to confirm, because it is destructive, and on a large site it takes a while. Until it finishes, the bot has less to work with than usual. Do it at a quiet hour, and do it the day the deprecation notice lands rather than the day the model disappears.
Choosing a replacement
When you are picking a new answering model, the behavior that matters most for a support bot is whether it follows the instruction to decline when the retrieved content does not answer the question. Fluency matters less, because a confident invention is worse than an “I do not know” with a link to a human. Larger models are generally better at that. They also spend your Workers AI allocation faster, so if volume is your constraint the limits page explains which lever to pull.
Whatever you choose, test it the way the demo page suggests: ask something the site covers, ask something it does not, and ask it to ignore its instructions.
Why the plugin does not just switch for you
It would be easy to have the plugin phone home for a list of current models and swap them automatically. We chose not to, for the same reason the plugin has no telemetry endpoint at all: a chatbot that answers your customers from your content, on your account, should not have a remote control held by someone else. The security page is specific about this. Nothing in the plugin contacts Flarepipe or Six Foot 3, which means the model choice is yours, and the notice, the fallback and the diagnostics exist so that the choice is never urgent.
If a retirement does catch you out, the troubleshooting guide has the short version of this post, and the support page reaches us.