API Key

What It Is

An API key is a secret string of characters a service hands you when you sign up for programmatic access, and that you then send along with every request so the service knows the call is really from you. When you use an app through its website, you log in with a username and password. When a script or a program talks to a service directly through its API, it proves who it is with a key instead. For the model router you might build this weekend, one OpenRouter API key is the single credential that reaches hundreds of models at once: the key says who is calling, which account to charge, and what that account is allowed to do. Guard it the way you would guard a house key, because anyone who holds it can spend on your behalf.

How It Actually Works

A key is usually a long, random-looking string like sk-or-v1-3f9c.... When your code makes a request, it attaches the key in a hidden part of the message called a header, typically labeled as a bearer token, meaning “the bearer of this token is authorized.” The service checks the key against its records, confirms the account is in good standing, notes what that key is permitted to do, meters the usage, and then answers. All of this happens in a fraction of a second and stays invisible to anyone using the tool. The key never appears in the reply and should never appear in the visible code either. The safe pattern is to store it in an environment variable, a named slot on your machine or server that your program reads at runtime, so the secret lives outside the file you might share or push to GitHub.

Why It Matters Right Now

Nearly every AI tool is now metered, charging by the request or by the token, and the API key is the thing that ties usage to a bill. It is how usage credits get drawn down and how a provider tells one customer’s traffic from another’s. The moment you move past clicking around in a chat window and start wiring models into your own scripts, the key becomes the center of the whole arrangement. It matters even more once you route across providers. A design like model routing, where a cheap model handles routine work and a frontier model handles the hard reasoning, only stays simple if a single key reaches all of them; otherwise you are juggling a separate secret for every vendor. One key across many models is what makes a personal switchboard buildable in a weekend instead of a month.

The Risk and the Tradeoff

The convenience of a key is also its danger. A leaked key is a spending key. If it lands in a public repository, a screenshot, or a chat message, someone can run up a bill against your account before you notice, and automated bots scan the web for exactly this. A second, quieter risk is your own code: a loop that calls a model over and over by mistake can drain an account fast, with no malice involved. Both risks have the same two answers. First, scope the key to a single purpose and give it only the access that one job needs, so a compromised key cannot reach everything. Second, set a hard spending cap on the key so that even a runaway process stops at a ceiling you chose. Most serious providers, OpenRouter included, let you set a per-key credit limit in the dashboard. The tradeoff is small: a few minutes of setup against the peace of a bill that cannot surprise you.

How TWO Uses It

We treat an API key as a spending instrument, not a convenience, and we set its ceiling before we write a line that uses it. Every key in a TWO build is scoped to one job and capped, so the worst case of a leak or a loop is a known, small number rather than an open tab. The discipline is the same one the Saturday build teaches: keep the deciding, and the spending, in your own hand. Scott’s Take: A key you have not capped is a blank check you signed and forgot about, so set the ceiling first and build second. For a non-technical operator, the single habit worth forming is this: the day you create a key, you also set its cap and store it in an environment variable, never in the file itself. Do those two things and the rest of the risk mostly disappears.