AI models

Every agent runs on an AI runtime, and you choose which one. Disco Parrot is not wired to a single vendor. You configure one or more runtimes, pick which models each exposes, set a default, and the platform resolves the right one for each run. You can power those runtimes two ways: bring your own provider keys, or let Disco Parrot run the models for you on the spend bundled into your subscription.

For the step-by-step of connecting a runtime, choosing the models to turn on, testing it, and setting the defaults, see AI models & SDK configs.

The runtimes

A runtime is a provider and the way the platform talks to it. Four are supported:

Each runtime exposes a set of models. The list is fetched live from the provider when a key is present, and falls back to a curated list when it is not, so you always have something to pick from.

That list is the source of truth for what a runtime can run. A model has to be on it to be used, so if a skill or a sandbox profile pins a model the runtime no longer offers, the run stops and tells you rather than quietly swapping in a different model. You can also test a runtime before you rely on it: a test sends a small real request to the provider and reports whether the key, the endpoint, and the model all work, which turns a misconfigured key into an answer in seconds instead of a failed run later.

Bring your own model and keys

A runtime is configured with your own credentials. Its key is stored as a managed secret (your Anthropic key, your OpenAI key, your Google key, your Copilot token), and the key stays on the server. Agents never receive it, which is part of approved actions: the platform calls the provider on the agent's behalf rather than handing the agent the key.

• Claude and Google Gemini authenticate with an API key.
• Codex signs in with a device-code flow, or with an API key.
• GitHub Copilot authenticates through its OAuth sign-in.

Or let Disco Parrot run it for you

Bringing your own keys is one path. The other is to let Disco Parrot run the models for you. Choose this 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 usage is metered, and the metering is detailed. Disco Parrot records the billable AI usage behind your runs and reports it as a running monthly figure, broken down the ways a finance owner actually needs it: by model, by person, by project, and by cost center. You can set budgets and watch them fill, with a status that turns over as you approach a limit, and usage that has not been priced yet shows up as its own line rather than disappearing. The AI spend sits alongside the rest of your plan's usage, not in a separate bill you have to reconcile. As with your own keys, a managed key stays on the server and never reaches the agent.

You are not locked into one path. A workspace can run entirely on managed spend, entirely on its own keys, or both at once: lean on the bundled models for everyday work, and point a specific runtime at your own provider 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.

Run several providers at once

You are not held to one provider. A workspace can have Claude, Codex, and Gemini enabled at the same time, each configured with your own account or run on managed spend. Running more than one at once is part of the multi-provider capability on your plan.

For each provider, you choose which models are turned on. The list you curate is the list the workspace can reach, not the provider's entire catalog: turn on the two or three models you trust and leave the rest off, and those are the only models anything in the workspace can use. A model you never enable cannot be reached by any person, skill, or Flow.

Having more than one provider on is not about novelty. It is about putting the right model behind each piece of work, and three things follow from it.

The best model for each job

Models are good at different things, and you do not have to pick a single winner. An agent can implement a plan on a strong reasoning model, and then a different model can run the verify skill over what it produced. You set this once by pinning a model to a skill, and the same kind of pin works on a Flow, on a sandbox profile, and on the workspace default. The routing becomes a setting rather than a choice someone makes by hand each time. Defaults and overrides, below, is the exact order the platform follows to decide which pin wins.

The most valuable version of this is a check that crosses providers. Let one provider write a change and a different provider review it, so the work is graded by a model that did not produce it. A second opinion from the same model is a weaker thing than a second opinion from another lab, and Disco Parrot lets you make that a standing rule instead of a hope.

Cost, controlled at the model level

The strongest model is rarely the right model for every task, and it is usually the most expensive one. Routing by model is how you hold the bill down without giving up quality where quality counts. Keep a top-tier model for the work that earns it, the hard implementation and the tricky design, and send routine work to a smaller, faster, cheaper model that does the job just as well.

You set this in two places. You decide which models are enabled on a provider at all, so an expensive model can be left off entirely for a workspace that does not want it. And you pin specific models to specific skills and flows, so everyday actions run on the economical model and the premium one is spent only where you decided it should be. For an admin who watches the bottom line, that is the difference between an AI bill you can predict and one that surprises you. Managed spend then reports what each model and each person actually used, so the policy you set and the number you pay line up.

Who can use what

The same controls govern access, not only cost. The enabled-model list is a workspace-wide allowlist, so a model that is off is off for everyone. Pair that with status-scoped skills, where a binding decides which skills a record offers and your roles decide who can author and curate them, and the answer to what an agent will do, and on which model, is something you set rather than something you hope holds. The people who should reach a premium model for a sensitive task can, and everyone else works inside the set you drew for them.

Defaults and overrides

You rarely pick a runtime by hand for each run. The platform resolves one through a cascade, and the first option that is both set and enabled wins.

• A skill's pinned runtime. A skill can pin a specific runtime or model for its kind of work, so a chore skill can run on a fast, cheap model while implementation runs on a stronger one.
• Your personal default. Each person can set the runtime they prefer.
• The sandbox profile's runtime. A sandbox profile can specify the runtime its sandboxes use.
• The workspace default. A workspace has one default runtime that applies when nothing more specific is set.
• The first enabled runtime, as a final fallback.

Two details round out the cascade. When you resume an existing session, it keeps the runtime it was already running on rather than re-resolving from your defaults, so a conversation never switches models underneath you. And the final fallback is deterministic: when more than one runtime is enabled and nothing more specific applies, the platform prefers Claude.

Any runtime can be enabled or disabled. A disabled runtime is never resolved, which is how an admin turns a provider off for the whole workspace without deleting its configuration. A resolved runtime also has to be available in the sandbox image the run uses; if the chosen image does not include that runtime's bundle, the run reports the gap rather than failing silently.

Why it matters

For your team, this means you run the model you trust for the work in front of you, and you can match the model to the task: a light model for routine chores, a strong one for hard implementation, pinned right on the skills that do each.

For prospects and enterprise buyers, it means no single-vendor lock-in and no forced procurement. Bring your own models and keys, let Disco Parrot run the models on bundled spend, or mix the two; either way the keys are held server-side and never reach the agent, and you can route by workspace, by person, and by skill. Managed spend is metered and reported against your plan, so finance sees one number. Running more than one runtime at once is part of the multi-provider capability, which depends on your plan; without it a workspace runs a single enabled runtime, and that runtime is the workspace default.