BYOK is a feature, not a compromise

Somewhere along the way, "bring your own key" got framed as the budget option — the inconvenient path for people too stubborn to let a platform handle things. I think that framing is exactly backwards. BYOK AI tools are the serious option, and the hosted-key convenience layer is the compromise: you're trading rates, rate limits, and control of your data path for the privilege of not pasting a string into a config file.

I built Frugal BYOK-only, no account, on purpose. This post is the reasoning, including the part where I tell you what BYOK genuinely costs you.

Your keys are your rates

When a middleman resells API calls, you pay their price, not the provider's. The markup is sometimes explicit — a per-call fee, a subscription gating "credits" — and sometimes buried in a bundled price you can't decompose. Either way, a margin now sits between you and the rack rate, on every call, forever.

With your own keys, you pay what the provider charges: Serper's $0.001/call is $0.001/call, You.com's $0.005 is $0.005. When you negotiate volume pricing, you get it. When the provider cuts prices, the cut reaches you instead of widening someone's margin. And your usage accrues to your account — the history that gets you higher tiers builds under your name, not a reseller's.

There's a subtler version of this too: a middleman with pooled keys has no incentive to route your call cheaply, because the spread is their revenue. The rack-rate gap in search — $0 to $0.005 for the same query — is margin waiting to be captured. The only party guaranteed to want your per-call cost minimized is you, and you can only act on that with your own keys in hand.

Your keys are your rate limits

Pooled-key services share one quota across every customer. Their limit is your limit, their noisy neighbor is your throttling, and their peak hour is your queue. You can't buy your way out, because the quota isn't yours to raise.

With your own keys, the rate limit is a relationship between you and the provider. You know your tier, you can see your headroom, and when you need more you ask for more. For an agent workload with bursty fan-out — a research agent issuing 50 searches in a minute — knowing exactly whose quota you're spending is the difference between capacity planning and hoping.

Your keys are your data path

This is the argument I'd keep if I had to drop the others. Every query your agent makes says something — what your product does, what your users ask, what your team is investigating. Route those calls through an intermediary and you've added a second data controller: their logs, their retention policy, their subprocessors, their breach surface, their subpoena scope. Your vendor-review spreadsheet just grew a row, and so did your actual risk.

BYOK collapses the path back to two parties: your machine, the provider you already chose to trust. Nothing in the middle to log, retain, or leak. In MCP terms — and this is where the MCP ecosystem makes the distinction unusually crisp — the question to ask of any server is whether it's software you run or a service you call. The protocol permits both. Only one of them adds a tenant between your agent and the web.

No control plane, nothing to breach

The strongest version of BYOK isn't just "you hold the keys" — it's that there's no central place your keys go at all. Frugal is one Go binary. No account, no signup, no control plane. Keys live in your environment; the usage ledger is a JSONL file at ~/.frugal/usage that never leaves the machine. Cost tracking happens where the costs happen — the receipts argument from agent cost observability works better locally, because the ledger is yours to grep, not a dashboard someone else hosts.

The security property is structural, not promised. A hosted key vault can be operated impeccably and still be a vault: one place where thousands of customers' provider keys concentrate, one target worth the effort. An architecture with no vault has nothing to harden and nothing to disclose. "We can't lose your keys" beats "we protect your keys" — the first is a fact about the design, the second is a claim about execution.

That's why I'd call BYOK trust architecture rather than a checkbox. It doesn't reduce the trust you must place in vendors; it removes a vendor from the set entirely.

The tradeoff, stated honestly

BYOK hands you jobs a platform would have done. You sign up with each provider yourself. You store keys properly — environment variables or a secrets manager, not a committed .env. You rotate them when someone leaves. You watch spend across several dashboards instead of one bill (a local ledger helps, but it's your ledger to read). If you expose a BYOK server over the network, securing it is on you too — bearer tokens and per-IP rate limiting exist for this, and I covered the transport side in stdio vs HTTP for MCP.

For a solo builder that's an hour of setup and a mild ongoing tax. For a larger team it's real operational surface, and there are contexts — procurement rules that demand one throat to choke, teams with zero ops appetite — where a managed layer is the right call, margin and all. The mistake isn't choosing managed. The mistake is not noticing you're paying twice for it: once in markup, once in a data path you no longer control.

The test I apply

When I evaluate anything in the agent-tooling stack now — MCP servers especially, and there's more on evaluating them across the mcp-ecosystem hub — I ask one question early: whose keys, whose path? If the answer is "ours, trust us," the product has to be dramatically better than the BYOK alternative to justify the margin and the extra controller. Occasionally it is. Usually it's the same upstream APIs, resold with a login screen.

Your keys, your rates, your limits, your data path, your receipts. That's not the stubborn option. That's the default the convenience layer should have to argue you out of.