Pinning the seed does not make your feature deterministic

A backend engineer at a logistics startup told me his AI feature had been “locked down.” Temperature zero, a fixed seed, the same prompt template every call. For a while the outputs really did come back identical, and the team built tests that asserted on the exact text. Then one morning half those tests went red. Nobody had touched the code. The provider had rolled a new model version, and the frozen output was no longer frozen.

Determinism you rent is determinism you can lose

Setting temperature to zero makes sampling greedy. Fixing a seed pins the randomness. On your own hardware, with your own weights, that can get you close to reproducible. Through a hosted API, it does not, because the parts that decide the tokens are not yours to hold still.

The provider changes the model. They change the serving stack, the hardware, the way batches get assembled. Any of those can shift which token wins at a given step, and greedy decoding will happily follow the new winner. Floating-point math on a GPU is not guaranteed to give bit-identical results across different execution paths, so even the same weights can drift. The engineer had built his confidence on a guarantee the provider never actually offered.

That is the trap. The outputs were stable long enough to convince the team they were permanent. Tests passed for weeks, which felt like proof. It was a coincidence with a long lease, and the lease ended without notice.

Build for behavior that survives the tokens changing

The fix is to stop asserting on the exact string and start asserting on what the string has to do. If the output is JSON, check that it parses and has the right fields. If it is a classification, check that it lands in the allowed set. If it is a summary, check length bounds and that required facts are present. Those hold when the wording shifts. An exact-match test does not.

This changes what a “passing” feature means. Instead of “the model returned this precise text,” you get “the model returned something that satisfies the contract.” A model bump can move every word and your tests stay green, because they were never about the words.

Here is what that discipline looks like in practice.

Assert on structure and content, not exact text. Validate format, required fields, and value ranges, so a reworded answer that still means the right thing passes.
Pin the model version explicitly. Call a specific version rather than a floating alias, so an upgrade is a decision you make, not a surprise you discover.
Re-run your evals when the version changes. Treat a provider update like a dependency bump: run the suite against the new version before it reaches users.
Keep a golden set of real inputs. Hold a batch of representative cases and measure the pass rate on every model change, so drift shows up as a number, not a support ticket.
Do not gate correctness on reproducibility. Design the feature to be right across a range of outputs, so it does not need the tokens to be identical to work.

The point is to make a model change boring. When your tests check behavior, a new version either still satisfies the contract or it does not, and you find out on your terms.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look for exactly this assumption early, because it hides well. A team will say the feature is reproducible and mean it, not realizing the reproducibility is on loan from a provider who can end it any morning. We pin versions, move the tests onto behavior, and set up the eval run that catches drift before a user does. It is far cheaper to find a rented guarantee in week one than to find it when the outputs move in production.

Temperature zero freezes the randomness you own. It cannot freeze the model somebody else is hosting for you.