Bring your own LLM — explained
If you are buying a business platform that uses AI, you are also making a model decision. Often without realizing it.
Bring your own LLM — explained
If you are buying a business platform that uses AI, you are also making a model decision. Often without realizing it.
Most platforms ship one model behind the scenes. The platform vendor chose it. You inherit the trade-offs — cost, latency, quality, data-residency, model behavior, and the supplier relationship the vendor has with the model provider.
There is another way. Bring your own LLM (BYO LLM) lets you choose the model per workload and pay through your own provider relationship.
When BYO LLM is the right call
The privacy-led organization. If your data has unusual residency requirements — regulated industry, government contract, data-localization law — you may already have a vetted LLM relationship (often through Azure OpenAI, AWS Bedrock, or a private Anthropic agreement). BYO LLM lets you keep that relationship.
The cost-optimized organization. Large LLM users typically negotiate enterprise pricing directly. BYO LLM lets you keep the negotiated discount.
The multi-model organization. Some workloads work better on Claude. Some work better on GPT. Some are fine on a small local Ollama model. BYO LLM lets you route per workload.
When BYO LLM is overkill
- You're a 10-person company without a vetted model relationship.
- Your AI usage is light (under a million tokens per month).
- Your team doesn't have a clear policy on which model is preferred.
In these cases, use the platform vendor's default and iterate when you have signal.
How Atlas handles it
Atlas supports four providers out of the box: Anthropic Claude, OpenAI GPT, GitHub Models, and local Ollama. You configure per workload: which model handles drafting, which handles summarization, which handles analysis. Per-call token usage is metered against the org and attributed to the user or agent that triggered it.
You can switch providers without changing your workflows. The Atlas tool surface is provider-agnostic.
What to think about before adopting
- Quality — have you tested your primary workloads on the model you're considering?
- Latency — workspace assistant interactions are user-facing.
- Reliability — providers have outages. Configure a fallback.
- Cost — token pricing changes. Plan for it.
- Data terms — read the provider's data-retention and training clauses.
Atlas does not train on your data; your provider's policy is separate.
Related articles
See it on your own data.
Connect your tools and Atlas shows you what matters.
Related articles
How Atlas isolates your data — multi-tenant architecture explained
Atlas is multi-tenant by design. Every record is bound to an — a unique identifier for your organization. The data layer enforces this on every query. There is no path through Atlas where one tenant's data can be returne…
What is approval-first AI?
Approval-first AI is a design pattern for business automation. Every AI write action is proposed by the assistant, surfaced as an approval, and executed only after a human (or a configured policy) says yes.
What is the Atlas Audit log?
The Atlas Audit log is a complete, searchable record of every mutation in your workspace — by every user, by every agent, by every API key, in every product. It exists to make a single question answerable in three clicks…
What is the integration tax?
The integration tax is the hidden cost — paid in hours, not invoices — of running your business on nine SaaS tools that don't talk.