Models and your own key

Two settings decide what an agent costs and how well it works: which model runs it, and whose key pays for the call. They look alike and they behave nothing alike, so they live in different places and follow different rules.

Two choices per workflow

The workflow screen has a Model section with two pairs.

Running it covers the workflow when it executes, whether that run is agentic or codified. A workflow version is one or the other, never both, so one pair is enough.

Building it with the assistant covers the interview, where the workflow gets described, drafted and codified.

Each pair has a model and a thinking level. Both start at Platform default. That is a real choice and not a blank: it keeps following whatever the platform is set to, and picking it again is how you clear an override.

Changing either pair on a live workflow applies from its next run. Nothing gets re-codified and no new version is minted, because the model is runtime configuration and not part of what the workflow does.

What a run records

Each run stamps the model and thinking level it actually used, along with who paid and what it consumed. A resume rebuilds from that stamp, never from what the workflow says now, so a run that waited three days on an approval finishes as the same agent that started it. It also means a run that behaved oddly last Tuesday can be explained instead of guessed at.

Why the model list is short

Every model that can run a workflow has to support computer use, because runs drive a real browser. A model without it does not fail at the picker, it fails on the run's first screenshot, which is a far worse place to find out. So the list you are offered is the list that qualifies.

The assistant that builds a workflow is not held to that rule. It authors and talks, and it reaches a browser only through your own login session, so its picker offers more.

One thinking level is refused everywhere: minimal. Web search is part of every agent's baseline and OpenAI will not accept the two together, so a workflow configured that way would fail on its first model call.

Bringing your own OpenAI key

Settings has an OpenAI key section. Save a key there and everything of yours runs on it: your workflow runs, the agent watching them, and the assistant you build with. Leave it empty and all of it runs on all-agents billing.

The key belongs to your account, not to one workflow, and it is deliberately not part of the interview. The key pays for the interview itself, so it has to be settable before any workflow exists.

Two things happen when you save it:

• The key is proven before it is stored. A key that does not work says so on that screen, rather than three hours later in a failed run.
• What it can reach is recorded. The check notes which models the key actually reaches, and the workflow model picker narrows to that set. A key proven against fewer models offers you fewer, which is the point.

Tracing follows the same key. A run paid for by your key exports its trace to your own OpenAI organisation.

Removing the key puts everything back on all-agents billing straight away.

When your key stops working

One key covers everything, so a broken one stops a lot at once. Three different behaviours, each picked for who is looking at a screen at the time:

• You are told once, on the change from working to broken, not once per queued run. The message names no workflow, because a broken key stops all of them and naming one would send you to fix the wrong thing.
• Scheduled and event-driven work waits. Nothing is thrown away. The items stay queued and drain on the next tick once the key works again. The Check again button on the key screen is what releases them.
• A manual run fails immediately, with a readable reason. Somebody is watching, and a run that silently never starts is worse than a clear failure.

Only a key that stopped paying trips this. A rate limit or a provider error is the provider having a moment, and neither counts as broken.