Key Takeaway
A structured ADR for LLM provider selection creates a referenceable decision record that prevents re-litigation of the choice and documents the trade-offs accepted.
When to Use This Template
Use this ADR when your team is selecting an LLM provider for a new product feature, migrating between providers, or evaluating whether to add a secondary provider for redundancy. The template is designed for decisions that involve commercial API providers (Anthropic, OpenAI, Google, Cohere, Mistral), self-hosted open-weight models, or hybrid approaches. It is particularly valuable when multiple stakeholders have opinions about provider choice, because it forces structured evaluation rather than advocacy-based decisions.
ADR Template
# ADR: LLM Provider Selection
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Date
YYYY-MM-DD
## Decision Makers
- [Name, Role — e.g., "Jane Smith, Engineering Director"]
- [Name, Role]
## Context
### Business Requirements
- Primary use case: [e.g., customer-facing conversational AI, internal document processing]
- Quality bar: [e.g., "must match or exceed current human agent accuracy"]
- Latency SLA: [e.g., "first token within 500ms, complete response within 5s"]
- Throughput: [e.g., "sustained 100 requests/minute, peak 500 requests/minute"]
- Data sensitivity: [e.g., "PII present, must not be used for training"]
### Technical Constraints
- Integration requirements: [existing tech stack, SDK availability]
- Compliance requirements: [SOC 2, HIPAA, GDPR, data residency]
- Budget envelope: [monthly budget ceiling for inference costs]
## Options Considered
| Criterion | Provider A | Provider B | Provider C (Self-Hosted) |
|-----------|-----------|-----------|------------------------|
| Model capability | | | |
| Input pricing (per 1M tokens) | | | |
| Output pricing (per 1M tokens) | | | |
| Latency (p50 / p99) | | | |
| Rate limits | | | |
| Data handling policy | | | |
| Fine-tuning support | | | |
| SDK maturity | | | |
| SLA guarantee | | | |
| Vendor lock-in risk | | | |
## Evaluation Criteria (Weighted)
1. **Capability fit** (30%) — Does the model meet quality requirements?
2. **Total cost of ownership** (25%) — Inference + integration + maintenance
3. **Data handling** (20%) — Privacy, compliance, training data usage
4. **Operational reliability** (15%) — Uptime SLA, rate limits, support
5. **Migration flexibility** (10%) — Ease of switching if needed
## Decision
We will use [Provider] because [rationale tied to weighted criteria].
### Migration Path
[If switching providers: rollout plan, prompt adaptation work, testing approach]
## Consequences
### Accepted Trade-offs
- [e.g., "Higher per-token cost in exchange for better quality on our evaluation set"]
- [e.g., "Vendor lock-in on function calling format"]
### Risks
- [e.g., "Single provider dependency — mitigated by abstraction layer"]
### Action Items
- [ ] Implement provider abstraction layer
- [ ] Set up cost monitoring and alerts
- [ ] Establish prompt regression test suite
- [ ] Document fallback procedure
## Review Trigger
Re-evaluate this decision when:
- [ ] Monthly inference cost exceeds $[threshold]
- [ ] A new model generation is released by any evaluated provider
- [ ] Quality metrics drop below [threshold] for [duration]
- [ ] Contract renewal approaches (review 90 days prior)Section-by-Section Guidance
Unlock the full Knowledge Base
This article continues for 11 more sections. Upgrade to Pro for full access to all 93 articles.
That's just $0.11 per article
- Full access to all blueprints, frameworks, and playbooks
- Interactive checklists with progress tracking
- Downloadable templates (.xlsx, .pptx, .docx)
- Quarterly Technology Radar updates