An AI profile decides which models run your work. You pick one profile for a piece of work — not one per agent — and it stays fixed for the whole workflow.
A profile is a set of models, one per agent
This is the part worth understanding properly.
A profile is not a single model. It holds an assignment per agent role: a model for the Architect, one for the Developer, one for QA, one for the Reviewer — each with a fallback model if its first choice is unavailable.
Architect
Developer
QA
ReviewerThe per-agent thinking is already done inside the profile. Take Budget: it does not simply pick the cheapest model for everything. It pairs a low-cost model with strong world knowledge for the architect — because planning needs breadth — with a low-cost but genuinely capable model for the developer, because writing code that compiles is a different demand. Both are inexpensive; neither is the same model.
So choosing a profile is choosing a balance across the whole pipeline, not a single quality dial.
The shipped profiles
| Profile | Optimised for |
|---|---|
| Budget | Cost. Routine tasks, documentation, straightforward changes |
| Smartest | Capability. Architecture, debugging, critical code paths |
| Quick | Latency. Iterative work where you want an answer now |
| Ludicrous | Raw speed, with relaxed quality gates |
| EU Only | Models hosted in the EU, for data-residency requirements |
| Free | No model cost; Coroid routes to cost-efficient models |
| Low carbon | Smaller models on lower-intensity grids |
The profile locks while work runs
A profile is assigned when work is created and is fixed once execution begins. The interface shows a padlock on the profile chip while a task is running.
Two consequences:
- You can change it when the task is not running — before it starts, or while it is stopped.
- A completed task keeps the profile it ran with. The record of what produced a change stays accurate, and a task's cost can always be explained by the models it actually used.
Locking matters because a workflow that switched models halfway through would produce a plan from one model and an implementation from another, with no consistent account of why the result looks the way it does.
Choosing a profile
Since one profile covers the whole pipeline, the question is what this piece of work deserves:
- Routine, well-specified, near existing tests → Budget.
- Architecturally significant, or in code you cannot afford to get wrong → Smartest.
- Iterating and reviewing closely → Quick or Ludicrous.
- Data residency requirements → EU Only.
EU Only and Low carbon
These two are constraint profiles rather than quality tiers.
EU Only restricts routing to models hosted in the EU. If you have a data residency requirement, this is how you meet it — and it is a genuine restriction, so some capability is unavailable.
Low carbon prefers smaller models on lower-intensity electricity grids. Coroid reports estimated operational inference emissions; the estimate covers inference only and is not a carbon-neutrality claim.
Custom profiles
Paid plans can define custom profiles, which is where per-agent assignment becomes yours to control: you choose the model and fallback for each agent role rather than accepting a shipped balance.
Reach for this when a shipped profile is nearly right but wrong in one place — for example a Budget profile everywhere except a stronger reviewer, because your organization's review rules are demanding.
Bringing your own keys
Models can be served through Coroid or through your own provider credentials, and a profile's model options record which applies. Under BYOK you pay your provider directly at your own rates, and Coroid adds no markup either way.
Keys are encrypted at rest, never returned by the API, and never included in settings exports. See Provider keys.
Where to change them
Organization defaults live at Settings → AI profile. The profile for a specific piece of work is set on the New Work form, under advanced settings.