Bundle LLM costs into your subscription price by default (managed keys), and offer bring-your-own-key (BYOK) as an opt-in for enterprise accounts that already have their own model contracts or compliance requirements. The wrong default either kills your margin at scale or adds enough setup friction to tank your self-serve conversion.
This decision shows up the moment you add any LLM-powered feature to a SaaS product: a chat assistant, an AI search box, an agent that drafts emails. Someone has to pay for tokens, and someone has to hold the API key. Get it wrong and you either eat unpredictable inference costs as your product goes viral, or you force every trial user through an OpenAI signup before they see any value.
The two models, plainly
Managed keys: your backend holds one (or a few) API keys, calls the LLM on behalf of every tenant, and you fold the token cost into your subscription price. The customer never sees a key or a provider name.
BYOK: the customer generates their own API key from Anthropic, OpenAI, or Azure, pastes it into your settings page, and your app uses their key and their billing relationship. You charge for the software and workflow, not the inference.
Most products default to managed because it's the better onboarding experience. Nobody wants to leave your signup flow to go set up a separate account somewhere else before they can try your product. But managed pricing means your gross margin moves with token prices and usage patterns you don't fully control, which is exactly the failure mode covered in multi-llm-provider-failover: a single vendor price change or outage becomes your problem, not a line item you can pass through.
Why this is a pricing decision, not just an architecture decision
Teams often treat BYOK as a technical toggle: add a settings field, store the key, done. It's actually a pricing and packaging decision that determines your unit economics.
With managed keys, every heavy user erodes your margin. A customer who runs 50,000 completions a month on your $99/month plan is subsidized by the customers who run 500. That's fine at small scale, but it breaks down once usage-heavy customers cluster on your cheapest tier, which is a version of the same trap covered in saas-pricing-models: flat pricing works until usage variance gets wide enough to punish your best customers or your margin.
With BYOK, your margin is protected because the customer pays the LLM provider directly. But you've now pushed setup friction onto every user, and you've taken on a support burden: expired keys, hit rate limits, wrong model access tiers, and confused customers debugging why "your product" returned an error that was actually their provider's account issue.
The cost math worth doing before you decide
Before picking a default, instrument actual token usage per feature, not a guess from one demo session. Log input and output tokens per request in staging, run your real prompts and expected output lengths, and multiply by projected monthly active users at each pricing tier. The gap between "what we assumed" and "what real usage looks like" is usually 3-5x, especially for agentic features that make multiple tool calls per user action.
This is also where call architecture matters as much as pricing model. In our own outreach tool, we originally split lead qualification into separate calls: one to extract company facts from a scraped page, another to draft the email. Collapsing that into a single call that extracts the facts and drafts the email in one pass cut token spend meaningfully and, if anything, improved output quality, because the model had full context in one shot instead of losing it across a handoff. If you're running managed keys, this kind of consolidation is the difference between a feature that's profitable at $49/month and one that isn't. It's worth doing the audit described in llm-cost-optimization before you finalize either pricing model, because a chain-heavy feature makes managed pricing much harder to sustain and makes BYOK friction much harder to justify.
When BYOK is the right default
Run the same 50,000-completions-a-month customer from the margin example above through a BYOK lens: on managed keys they're the one subsidized by your 500-completion customers; on BYOK, their token bill goes straight to their own OpenAI or Anthropic account and stops being your problem. That's the pattern to watch for, not a checklist to apply blind. BYOK tends to be the right call when:
- Your customers are enterprises that already have negotiated LLM contracts (volume discounts, data residency terms, or a specific vendor mandated by their own compliance team)
- Usage is inherently high-volume and spiky, like a coding assistant or bulk document processor, where per-seat pricing can't absorb the variance the way it broke down in the $99/month tier above
- Your buyer's security team requires that no third party (including you) can access their prompts or outputs, which is common in healthcare and legal verticals
- You're selling a developer tool where the audience already manages API keys as part of their normal workflow
When managed keys are the right default
Managed keys make the most sense for exactly the profile our outreach-tool anecdote describes: a feature where you control the call pattern closely enough that consolidating two calls into one is your lever for protecting margin, rather than pushing that cost onto the customer. That only works if you're the one holding the key and the bill. Managed tends to be the right call when:
- You're selling to non-technical buyers who will never generate an API key on their own
- Usage per customer is predictable enough to price into flat or tiered plans, the way a $49-or-$99-a-month tier assumes
- Time-to-value matters more than margin protection, which is almost always true pre-product-market-fit
- The AI feature is one part of a broader product, not the whole product, so token cost is a small fraction of your overall COGS
The hybrid approach most mature products land on
Start managed for self-serve and lower tiers, where onboarding friction is the bigger risk than margin. Add BYOK as an enterprise-tier option once you have customers asking for it, usually the same customers who need SSO, audit logs, and a signed DPA anyway. This mirrors how most multi-tenant-saas-architecture decisions get made generally: build the simple default first, add the configurable path only when a real customer segment needs it, and keep the two paths behind the same feature interface so switching a tenant from managed to BYOK doesn't require a rewrite.
Whichever default you pick, don't hardcode it. Store the key source (managed vs tenant-provided) as a per-tenant config value from day one, even if every tenant starts on managed. Retrofitting BYOK into a codebase that assumed one global API key is a bigger project than it sounds, and it's the kind of technical debt described in technical-debt-management that's cheap to avoid up front and expensive to unwind later.
If you're scoping an AI feature and aren't sure which model fits your customer base and margin targets, let's talk.
Originally published on the Pykero blog.
Top comments (0)