Every capability your agent lacks is another API key to manage
Two capabilities already meant four providers, four bills and four keys. This is one connection, prepaid, with no key to store anywhere.
Your agent cannot read a scan, so you go and find something that can. Comparing the options takes an afternoon. Then there is an account, a card, terms someone should probably read, a key, a place to keep the key, and a response format that looks nothing like the last one you integrated.
Then it needs to transcribe audio, and all of it happens again from the top. And each capability wants a second provider for the day the first one is down, so it was never one provider per capability, it was two. Two capabilities, four providers, four bills, four rotation schedules and four response shapes to normalise into whatever your code expected to receive.
Not one of those four integrations is hard. The number is what hurts, and the number only goes in one direction.
There is no missing technique here, which is exactly why it never gets solved. Every piece is easy and every piece is permanent: the key that has to be present in development, in CI and in production, the rotation nobody schedules until an incident schedules it, the invoice from a provider you called twice last quarter, the normalisation layer that quietly drops a field the week a provider changes its response.
A key in a configuration file is also the thing that ends up in a commit. Usually not through carelessness: a .env that was never in .gitignore, a fixture copied with real values still in it, a debug line printed into a log that goes somewhere else. Every provider you add is one more chance for that, and the chance is not additive in a comforting way.
The fallback is the part that stays unbuilt. Writing a second integration against a provider you hope never to call is work with no visible reward, so the second provider remains a comment in the code until the first one is down, which is the one moment you have no time to write it.
One line. The client registers itself, a person approves it once in a browser, and the account exists. There is no key anywhere in this.
claude mcp add --transport http mcpbelt https://mcpbelt.com/mcp/
-> the client registers and authorises itself
-> the account exists with trial credit, nobody had to be there
account()
-> credits_available_eur, top_up_url
account(estimate_for="listen")
-> estimate_eur per mode, unit: minuteThe account starts with 0.10 EUR of trial credit and no card. No signup, no email, no key to paste, and nobody has to approve anything: the client registers and authorises itself. Reading costs 0.007 EUR per page and listening 0.005 EUR per minute in balanced mode, and the whole list is on pricing.
It is prepaid credit: no subscription, no per-call invoice, no monthly minimum, nothing to cancel. Top up when you want to, from 5 EUR. The tools that do not do paid work cost nothing at all: upload, result, cancel, account.
One balance instead of four bills, and the second provider you were never going to write is already there. Every capability has more than one engine behind it, and if the first fails the second answers at the same price with the same guarantees. Each response says which one ran, in engine and used_fallback.
- There is no API key to issue. Authorisation is OAuth 2.1 with dynamic client registration and PKCE, which is what MCP clients implement. A client that expects a key in a header will not connect.
- The account belongs to the browser that approved it. Approving from another machine creates a different account, with its own balance.
- The capabilities are two: reading documents and transcribing audio. This does not stand in front of every model API you use, it replaces the providers behind those two.
- Files are fetched from the address you upload them to and passed to an engine that runs elsewhere. If a document cannot leave your machine, this is the wrong tool.
Without markup
This page in markdown: /problems/stop-managing-one-api-key-per-provider.md. All 20 of them in one file: /llms-full.txt.