Who Picks the Model, and What If It Fails?

Insulin has no per-conversation model picker. The platform selects the model for you, and when a provider fails or hits a limit mid-turn, the turn retries on the next available one and tells you it did. That is a reliability choice, and it is worth understanding before you evaluate it as a missing dropdown.

---

Nearly every AI product you have evaluated this year put a model selector in the top-left corner. It has become such a fixture that its absence reads as an omission — a roadmap item, or a product that has not caught up.

It is worth pausing on that assumption, because the dropdown solves a problem most business users do not have and creates one they do. This post covers what Insulin actually does, what happens when a model fails mid-turn, what you keep control of, and the honest trade you are making.

There is no per-conversation model picker

Insulin selects the model for each turn rather than exposing a chooser. The documentation is direct about it: “Insulin selects the model for you.”

The one place model settings are exposed is the built-in assistant, where the pencil button in the conversation header opens them. For everything else, the selection is the platform’s job.

The case for a dropdown is real but narrow: a practitioner who knows the models well, is doing a task with a known model-specific strength, and is willing to re-pick every conversation. The case against it is broader. A dropdown asks every user to hold a mental model of a fast-moving vendor landscape, and its default answer — whatever was selected last time — is wrong more often than a fresh decision would be. Worse, it puts the burden at the exact moment the user is least interested in it: when they have a question and want an answer.

What happens when a model fails

This is the part the dropdown cannot do at all.

When a model fails mid-turn, the turn retries on the next available provider. The failover is automatic, and it is not silent — the thread carries an explanatory note, in the shape of “first-model hit its usage limit — continued with second-model.”

Two things follow from that, and both matter more than model choice does.

Provider outages stop being your outage. A rate limit, a regional degradation, or a provider incident becomes a retry rather than a failed turn and a support ticket. If you have run any AI workload at volume you have met this: the work does not fail because the model was wrong, it fails because a provider returned a 429 at the wrong moment.

You are told, rather than quietly served a different answer. A failover you cannot see is the genuinely bad version of this design, because it makes a result irreproducible for reasons that are invisible. Surfacing the switch in the thread is what keeps the behaviour auditable — you can look at a turn and see which provider actually answered it.

What you still control

Automatic selection is not the same as no control, and the distinction matters when you are writing a policy.

The model class a piece of work is allowed to use is an agent-level decision, not a per-message one — which is the level it belongs at, because the risk lives in the workflow rather than in the conversation. That is the subject of choosing models by workflow risk, and it is where a governance conversation should actually happen. Above every agent sits one organization-wide decision — which AI providers may serve the organization at all — covered in the AI model allowlist.

The commercial arrangement is separate again: whether the models are Insulin’s or your own provider account is a procurement decision, covered in BYOK versus managed models. Neither of those is the dropdown, and neither is affected by its absence.

The honest trade

Be clear-eyed about what you give up, because a post that pretends there is no cost is not useful to someone running an evaluation.

You lose per-conversation model pinning. If your workflow genuinely depends on one specific model answering one specific way — a reproducibility requirement, a benchmark, a regulated process that names a model — automatic selection is a real constraint and you should raise it directly rather than discovering it later.

You gain a system that survives its dependencies. Every model provider has bad days. A platform that treats them as interchangeable at the point of failure keeps working through those days; a dropdown just shows you which one broke.

For most business work — drafting, extracting, summarising, routing — the second is worth more than the first. For a small set of workflows it is not, and the right time to find out is during evaluation, not after rollout.

Frequently asked questions

Can I choose which model Insulin uses for a conversation? There is no per-conversation model picker. The documentation states that Insulin selects the model for you. The built-in assistant exposes model settings through the pencil button in the conversation header.

What happens if a model fails partway through? The turn retries on the next available provider automatically, and the thread shows a note explaining the switch, such as one model hitting its usage limit and the turn continuing with another.

Does failover happen silently? No. The switch is surfaced in the conversation as an explanatory note, so you can see which provider actually answered a given turn rather than having to infer it.

Where does model governance happen, then? At the agent level rather than the message level. Which class of model a workflow may use is a policy decision about the workflow’s risk, not something each user re-decides per conversation.

Is this a problem if I need reproducible model behaviour? It can be. If a workflow requires one named model to answer a specific way, automatic selection is a genuine constraint and worth raising during evaluation rather than after rollout.

Takeaways

• The absence of a dropdown is a design decision, not a gap. Insulin selects the model per turn; the documentation says so plainly.
• Failover is the feature the dropdown cannot provide. A failed provider becomes a retry on the next one instead of a failed turn.
• It is visible. The thread carries a note naming the switch, which is what keeps a result explainable after the fact.
• Governance lives at the agent level, where the risk actually is — not in a per-message chooser.
• Name the exception early. If you need one specific model pinned for reproducibility, raise it during evaluation.

Reliability is mostly what you do on the bad days. See agents for where model policy is actually set, or book a demo to see a failover in a real thread.