How Maggie chooses a model¶
Why this page exists¶
Magieva does not run on one AI model. It runs on many, and picks per request. This explains how that choice is made, why it changes over time, and what you control.
There is no single "the model"¶
Different jobs suit different models. Writing prose, reasoning over a long document, generating an image, transcribing audio, and producing code are genuinely different problems, and the best available option for each is rarely the same — and rarely the same for long, since the field moves monthly.
So Magieva keeps a registry of available models, each recorded with what it is good for, and resolves a model per capability at the moment of the request rather than hardcoding one.
Requests are matched to a capability¶
Every request is first classified by what it needs — a conversational reply, text-to-image, text-to-video, speech, code — and the registry answers with the model currently configured for that capability in your organization.
This is why the same phrasing can behave differently depending on what you asked for: "make me a picture of our new packaging" and "write me a paragraph about our new packaging" take different routes from the same sentence.
Why costs differ between requests¶
Because the model differs, so does the price. A short conversational reply is cheap. A long analysis is more expensive because there is more material to read. Image, video, and audio generation cost substantially more than text.
Magieva estimates the cost before running the request and checks your balance first, so an expensive request is declined up front rather than failing partway through having already spent tokens. See Understanding Intelligence Tokens.
The catalogue changes, deliberately¶
New models are added and older ones retired as the field moves. Because resolution happens per request against a live registry, you benefit from a better model without waiting for a Magieva release, and a retired model stops being selected without breaking anything that referenced it.
The consequence worth knowing: the specific model behind a given capability is not a fixed contract. If you need a particular one, set it explicitly.
What you control¶
Under Settings → Model Preferences you can express a preference rather than accept the default. Administrators can set organization-wide preferences; you can set your own within what the organization allows.
Reasons to override the default:
- Consistency. You have tuned prompts against one model's behaviour and want it to stay put.
- Cost. A cheaper model is good enough for a high-volume workflow.
- Policy. Your organization has requirements about which providers may see your data.
Reasons not to: if you have no specific requirement, the default tracks the best current option for each job, and pinning means you stop getting improvements.
When it cannot honour your preference¶
If a preferred model is unavailable — retired, rate-limited, or not offering the capability you asked for — Magieva falls back rather than failing the request. If output quality shifts unexpectedly, a fallback is a reasonable first suspicion, and the model used is recorded with the work.
Where to go next¶
- Model preferences — the how-to.
- Understanding Intelligence Tokens
- How Magieva works