I want to know which model answered before I praise it or complain about it. That seems basic, but a name in the selector can hide an execution that took another route. If I cannot see the switch, a comparison between models proves less than it seems to.
On August 7, 2026, Anthropic announced new biology safeguards for Fable 5. According to the company, the change reduced biology-related fallbacks by about 85%. Requests it considers dual use, such as virology, toxicology and molecular design, still go to Opus 5. Everyday health questions, like lab results and symptoms, should fall back far less often. In an AI product for health, that boundary runs through ordinary conversations: one question can be answered by one model and the next by another. As a developer, I need to know which model produced each answer.
When I compared Sol and Codex in Cursor for one task, the names were already getting mixed up: the model on one side, the application and its features on the other. Invisible fallback makes that comparison harder.
A weak answer can come from the selected model or an alternative invoked along the way. It can also reflect a product restriction. If I record everything under the first name on the screen, my analysis starts with a mistake. Then a routing rule gets built on that impression, and the mistake gets a config file to call home.
The user is still right to complain about a bad experience, and knowing where the answer came from helps fix the complaint. I want to distinguish an unclear request from an access restriction or a model switch. Each diagnosis calls for a different change; telling people to rewrite their prompt out of habit wastes time.
The interface can show the switch beside the result and keep the details for when I need them. For a task with several calls, I need to reconstruct the sequence without hunting for identifiers scattered across another dashboard. Cost follows the same execution history: combining one model's prices with another model's answers ruins a comparison, however tidy the table looks.
My rule for this evaluation: record the selected model, the model that actually answered, and the restrictions in effect. If the tool doesn't give me that information, my conclusion applies to the whole product. I will not assign individual credit or blame to a model that may never have performed that part of the work.