AI models & SDK configs

Every agent runs on an AI runtime, and you decide which ones your workspace can use. Disco Parrot is not wired to a single vendor, so you are never betting that one lab stays ahead at everything: you connect one or more runtimes, on your own provider keys or on the spend bundled into your subscription with nothing to procure, turn on the specific models you trust, set the defaults, and the platform resolves the right runtime for each run. This page is the how-to for setting that up. For why multi-runtime routing matters, the resolution cascade in full, and how spend is metered, read the AI models concept.

The runtimes you can connect

A runtime is a provider and the way the platform talks to it. Four are supported, and each signs in its own way.

You configure each on the AI models page under Platform, one card per runtime. A runtime has to be enabled before anything in the workspace can run on it, and you can have more than one enabled at once so different work runs on different providers.

Bring your own keys, or let Disco Parrot run it

You can power a runtime two ways, and you can mix them.

• Bring your own keys. Connect a runtime with your own provider account, a Claude or Gemini API key, a Codex sign-in, a Copilot authorization, and the usage bills to that account. This is the path when you already have a provider relationship, or you want your own billing and your own rate limits.
• Let Disco Parrot run it. Turn on managed spend and there is no provider to configure and no key to hold: the platform supplies the runtime and the models, and the usage draws from the spend bundled into your subscription. You turn it on and your team starts working the same day, with nothing to procure.

The two are not exclusive. A workspace can run entirely on managed spend, entirely on its own keys, or both at once, leaning on the bundled models for everyday work and pointing a specific runtime at your own account when you want a particular model or your own billing relationship. The resolution cascade picks the right runtime the same way regardless of who is paying for it, and a managed key, like a key you bring, stays on the server and never reaches the agent.

Choosing managed spend or your own keys

Most workspaces do not have to choose once and for all, because the two paths coexist per runtime. But each has a shape it fits, and naming it makes the call quick.

Reach for managed spend when you want to start now. There is no provider account to open, no key to procure, no finance approval to clear before the first run: you turn a runtime on and the team is working the same day, and the usage lands on the subscription you already pay. It is the path that gets a new workspace from nothing to running agents in an afternoon, and the path that keeps the AI line on one invoice instead of a separate provider bill for each lab.

Reach for your own keys when you already hold a provider relationship you want to keep, when a model you need lives behind your own account, or when finance wants the AI usage on the provider's own invoice and rate limits. Bringing a key changes nothing about how the platform routes or how a credential is held; it changes whose account the usage bills to.

A common shape is both at once: managed spend carries the everyday runtimes so the team is never blocked on procurement, and one runtime points at your own account for the model or the billing relationship you specifically want. The cascade does not care which is which, so you can move a runtime from bundled spend to your own key later without rewiring a single skill or profile that runs on it.

Connect a runtime

Connecting a runtime with your own credentials means giving the platform the credential it needs to call the provider on your agents' behalf. (On managed spend there is nothing to connect here: the platform holds the runtime, and you turn it on and pick its models like any other.) How you connect your own depends on the provider:

• Claude and Google Gemini connect with an API key. You store the key as a managed secret, and the runtime references it.
• GitHub Copilot connects through its OAuth sign-in, the same GitHub authorization the rest of the platform uses.
• Codex connects with a device-code sign-in to your account, or with an API key if you prefer.

In every case the credential is stored server-side and referenced by the runtime, never pasted into a place an agent could read it. The platform calls the provider on the agent's behalf, which is why a key never reaches the agent: the runtime is the boundary, and the secret stays behind it.

Connect with an API key

Claude and Google Gemini connect with a key you hold with the provider. On the runtime's card, open Configure secret, paste the key once, and it is stored as a managed secret that the runtime references by name from then on. The card never shows the key back; it shows that a secret is set. Turn the runtime on, run the Test, and a green result means the credential and a model both answered. If your team rotates the key, you update the one secret and every run that resolves to this runtime picks up the new value, because nothing downstream ever held a copy.

GitHub Copilot connects the same way the rest of the platform uses GitHub: open its OAuth sign-in, authorize, and the platform holds the resulting session. There is no key to paste and none to rotate by hand.

Codex device-code sign-in

Codex signs in with a device code rather than a pasted key. Choose the Codex-managed option and start the sign-in: the platform shows you a short code and a link, you open the link, enter the code, and authorize the connection with your account. The platform completes the handshake, stores the session server-side, and refreshes it silently from then on, so you sign in once and the runtime keeps working without you re-entering anything. Disconnect from the card to drop the stored session, and sign in again to reconnect. An API key is there as the alternative if your team would rather manage one.

Choose which models are on

A runtime exposes a set of models, and you decide which of them your workspace can use. For providers that publish a model-list API, the list you see is fetched live when a key is present, so it reflects what the provider actually offers right now; without a key yet, or for a runtime the platform keeps on a curated set, the page shows a known list so you always have something to pick from.

The models you turn on are an allowlist. Turn on the two or three you trust and leave the rest off, and those are the only models any person, skill, or Flow in the workspace can reach through that runtime. One of them is the runtime's default model, marked with a star, used whenever a run on that runtime does not pin a more specific model; star a model that is off and it turns on as the default at the same time. The allowlist is enforced at run time: if a skill or a sandbox profile pins a model the runtime no longer has on, the run stops and tells you rather than quietly swapping in a different one.

Which models to turn on

The allowlist is short on purpose, and a good one is three or four models, not the provider's whole catalog. A pattern that holds up across teams:

• One strong reasoning model for the work that earns it: implementation, tricky design, the plan that has to be right. This is the model your heavyweight skills pin to.
• One fast, cheaper model for the routine: cleanup, triage, summarizing a thread. The work that does not need the premium model should not cost like it does.
• A model from a second provider, when you run more than one runtime, for the cross-provider check, so a change can be graded by a lab that did not write it.

Leave the rest off. A model nobody turned on is a model no skill, person, or Flow can reach, so the costly ones you do not want in everyday use stay out of reach by being off rather than by anyone remembering not to pick them. Turn a model on when a skill needs it and a person you trust asked for it, not because the provider shipped it. The shorter the list, the easier it is to reason about what your workspace can actually run.

Test a runtime

Before you rely on a runtime, test it. The test sends a small, real request to the provider and reports back whether the credential and the model both work, telling apart an authentication problem from a transient provider hiccup. A misconfigured key becomes an answer in seconds on this page instead of a failed run an hour later, and you rely on a runtime you have watched answer rather than one you hope is configured right.

Set the defaults

A runtime is chosen for a run through a cascade of defaults, and you set two of the rungs here.

• The workspace default is the runtime a run uses when nothing more specific applies. One runtime carries it for the whole workspace.
• Your personal default is the runtime you prefer for your own runs. It sits above the workspace default, so you can work on the provider you like without changing anyone else's setup.

Every runtime also has an enabled switch. A disabled runtime is never chosen, which is how an admin turns a provider off for the whole workspace without deleting its configuration, and a connection you are still setting up stays out of the way until you switch it on.

How a runtime gets chosen

When a run starts, the platform resolves a runtime through a cascade, and the first option that is both set and enabled wins. The full reasoning lives on the concept page; the order is what to know here.

1. A skill's pinned runtime, when the skill running carries one.
2. A resumed session's runtime, so a conversation you pick back up keeps the runtime it was already on rather than switching underneath you.
3. Your personal default.
4. The sandbox profile's runtime, when the profile the run uses specifies one.
5. The workspace default.
6. The first enabled runtime, as a final fallback, and when more than one is enabled the platform prefers Claude so the fallback is predictable. If you have turned every Claude runtime off, the platform refuses this fallback rather than reaching for a disabled one, so a deliberate choice to disable a provider is never quietly undone.

Disabled runtimes are skipped at every rung, and the resolved runtime also has to be present in the sandbox image the run uses.

When a runtime is not in the sandbox image

Resolving a runtime is one half of the picture; the other is that the runtime has to actually be present in the sandbox image the run uses. The image carries each provider's command-line bundle, and a slimmer image may not carry all of them. When the cascade lands on a runtime the image does not include, the run does not fail somewhere deep and leave you guessing: it reports the gap up front, naming the runtime it resolved and the image that is missing it.

The fix is one of two moves. Point the run at a profile whose image includes that runtime, or set the runtime so the cascade lands on one the image does carry. This is why testing a runtime on this page and seeing it run in a real session are two different checks: the test proves the credential and the model answer, while the image decides whether the run can reach that runtime at all. A green test plus a profile on the right image is the pair that means a runtime is ready end to end.

Run several at once

A workspace can have more than one runtime enabled at the same time. That is what lets you route by provider as well as by model: a skill on one lab, a profile on another, a person on the one they prefer, all live in the same workspace at once.

Running more than one runtime at once, and pinning a runtime or off-default model to a skill or profile, is part of the multi-provider capability on your plan. A workspace without it runs a single enabled runtime, the workspace default, which covers the everyday case; a workspace with it can route by skill, by profile, by person, and by workspace all at once. You set which models are enabled per runtime no matter which plan you are on, so the set a workspace can reach is the short list you turned on, never the provider's whole catalog by default.

A cross-provider check, set up once

Sarah's Analytics team trusts Claude for implementation work on the Insights project, and they want the review graded by a different lab, so a model is never the only judge of its own output. Setting that up is two runtimes and two pins.

First she connects both. Claude is already on, carrying the workspace default. On the AI models page she adds a second runtime, signs it in with its own key, turns on the one model the team wants for review, tests it, and enables it. Two providers are now live in the workspace at once.

Then she routes the work, not by choosing a model each run but by pinning one to each skill. The team's implement skill is pinned to Claude; the verify skill is pinned to the second provider. The pins travel with the skills, so a plan that moves through In progress into In review is written on one lab and checked by another without anyone touching a dropdown. When Tom runs the implement skill and Maya's CSV Export Flow reaches its review step, each lands on the runtime its skill carries.

Nothing else in the workspace changes. Routine cleanup still runs on the workspace default; a person who set a personal default still gets it. The cross-provider check is now a standing rule on the two skills that need it, not a habit the team has to remember.

What it costs and how it is metered

How you pay depends on the path. On your own keys, the bill is the provider's, on the account whose key the runtime references, and you read it in that provider's own console; Disco Parrot holds the key and calls the provider but is not in the middle of that invoice. On managed spend, the usage draws from your subscription and Disco Parrot meters it for you.

The managed metering is detailed. Disco Parrot records the billable AI usage behind your runs and reports it as a running monthly figure, broken down by model, by person, by project, and by cost center, and you can export the line items to CSV when finance wants them in its own tools. Usage that has not been priced yet shows up as its own line rather than disappearing, and the AI spend sits alongside the rest of your plan's usage, not in a separate bill to reconcile.

Set a budget and watch it fill

A managed-spend workspace is not flying blind between invoices. You set a monthly budget on the AI spend, and the running figure fills against it in view, so the question "how much have we used this month" is answered on the page rather than reconstructed after the fact. As the figure approaches the limit the status turns over from neutral to a warning, so the signal reaches you before the month closes, not when the bill arrives. The budget is a line you watch, and the routing you already set is the lever you pull against it: send the premium model only to the skills that earn it and the figure rises slower, with no one having to remember to economize run by run.

Either way, routing by model is how you hold the number down: keep the premium model on the skills that earn it and send routine work to the cheaper one, and the spend follows the pins you set rather than a habit anyone has to remember. The full metering model, the dimensions it breaks down by and how unpriced usage is handled, lives on the AI models concept.

Keys stay server-side

Across every runtime, the credential is the platform's to hold, not the agent's. A model-provider key, a Copilot token, a Codex session: each is stored server-side and applied when the platform calls the provider, and every sandbox host blocks it from entering the container at launch. An agent produces work on a model without ever seeing what authenticates to it, which is the same principle that governs approved actions and MCP credentials across the platform.

Why this works the way it does

Tying a product to one AI vendor is a bet that one lab stays ahead at everything forever, and that is not how the models have moved. Disco Parrot treats the runtime as a setting so you are never holding that bet: run on the spend bundled into your subscription, bring the providers you want with your own accounts and billing, or mix the two, turn on the models you trust, and route each kind of work to the model that suits it.

For your team, that means running the model you trust for the work in front of you, set once on the skills and profiles that do each job rather than chosen by hand every run. For an engineer, the standout is the cross-provider check: let one provider write a change and a different one review it, so the work is graded by a model that did not produce it. For an admin, the choice of managed spend or your own keys, the enabled-model allowlist, and the two default switches are the levers you actually pull: start the same day on bundled spend or wire your own billing, leave a costly model off so no one can reach it, and let the per-skill pins spend the premium model only where it earns its keep. For a security owner, the credential never reaches the agent on any runtime, managed or your own, which is the same line the rest of the platform holds.