Last updated on July 22nd, 2026 at 12:14 pm
Put the default AI model on the prompt, not in every client application. This keeps API requests simple and lets administrators replace an unavailable model without updating every integration.
The problem
A prompt API often starts by requiring clients to send both a provider and a model. That creates avoidable coupling. If a model is retired, renamed, or disabled, every website, service, and script may need a code change.
It can also produce invalid combinations, such as choosing a model that does not belong to the selected provider.
The essential design
Store one default_ai_model_id on the prompt. The selected model already belongs to a provider, so the server can derive the provider automatically.
Keep this setting outside immutable prompt-version content. Prompt versions preserve instructions and templates; the default model is operational configuration that may need to change independently.
How to implement it
- Add a nullable model relationship. Add
default_ai_model_idto the prompts table and link it to the models table. Use a safe delete rule such as setting the value to null if the model is removed. - Add one admin selector. Show active text models as
Provider · Model. Saving only the model ID prevents provider and model values from drifting apart. - Validate before activation. Require the prompt to have an active model from an active provider before it can become active.
- Resolve the model on the server. When a prompt runs, load its configured model and derive the provider through the relationship.
- Record the actual execution choice. Save the model and provider used for each request so usage and errors remain auditable.
Simplify the client request
After centralizing the default, clients only need to send prompt variables:
{
"variables": {
"topic": "Queue processing",
"language": "English"
}
}The request goes to a route such as /api/v1/prompts/{prompt-slug}/runs. The client no longer decides which AI provider or model should execute it.
Handle unavailable models clearly
Do not silently choose the first available model. A hidden fallback can change cost, quality, context limits, or output behavior.
Return a clear validation error instead:
The prompt's default model is unavailable. Select another model in the prompt settings.An administrator can then select a replacement model without changing client code or rewriting the prompt.
Common mistakes
- Saving both provider and model: this allows mismatched values. Save the model ID and derive its provider.
- Letting clients override the model: this weakens centralized control. Reject unsupported override fields unless overrides are an intentional feature.
- Silently falling back: this hides configuration problems. Fail clearly and require an explicit replacement.
- Changing prompt text to replace a model: model selection is operational configuration, not prompt-version content.
Conclusion
Centralizing the default model makes prompt APIs smaller, safer, and easier to maintain. The next action is simple: add a default-model relationship to each prompt, then remove provider and model selection from client requests.