Workspaces, API Keys, and Environments

Every platform demo shows the model answering. Nobody demos the operations layer — the keys, the workspaces, the environment boundaries — because it is invisible until it fails. But the operations layer is where production teams actually live: it decides who can spend, how spend is attributed, and how fast an incident can be contained.

On Run BiOS the layer is deliberately small: workspaces group usage and budgets, API keys carry permissions, and the org wallet sits above both. This post is about using that layer well — the habits that separate a team that survives its first incident from one that discovers its key hygiene in the retro.

If this sounds like the budgets post, it is adjacent: that post was about watching spend. This one is about the plumbing the watching depends on.

The first habit is the mental model: an API key is not a password, it is an identity. A password authenticates a person; a key authenticates a caller — a service, a script, a pipeline — and it should be issued per caller, not per person. One key per service means a leaked key identifies its leaker, a misbehaving service is revocable without touching the others, and the usage page reads like an org chart instead of a mystery.

Keys should also carry the minimum scope they need. A key that can only call the models a service uses is a smaller blast radius than a key that can do everything the account can. The same principle as the least-privilege rule in every security handbook, applied to a billing surface.

And keys expire. Rotation is not paranoia; it is the difference between a leaked key being a problem for a week and a problem for a year.

Because experiments are supposed to be wasteful, and waste needs a container. The budgets post made the arithmetic case: dev spend mixed into production graphs lies in both directions. The operations version is simpler — a key per environment means a stuck loop in development is a lesson, and the same loop on the production key is a procurement meeting.

Environments also make limits meaningful. A development key with a low rate limit and a small budget is a sandbox with walls; a shared key with production limits is a sandbox with a sign. The walls are what make experimentation safe.

On Run BiOS the natural mapping is a workspace per environment, each with its own keys and its own view of spend. The setup is minutes; the habit is permanent.

Rotating a key in production is the operation that separates the layer from the folklore. The pattern that works: issue the new key first, deploy it alongside the old, watch the old key's traffic fall to zero, then revoke. Rotation is a migration, not a swap, and migrations have an overlap window.

The failure mode is the midnight swap: revoke the old key, deploy the new one, discover the one service nobody remembered. The overlap window exists so that discovery happens while the old key still works.

And rotation is only possible if keys are per-service. A shared key cannot be rotated without a flag day; a per-service key rotates one service at a time, on a schedule, without drama.

The ability to answer three questions without asking anyone: which team spent what, which workload grew, and where the balance stands. That is the entire job of the org wallet and the per-workspace usage views — turning the invoice from a monthly mystery into a live dashboard.

Visibility also changes behavior. Teams that can see their own spend spend differently than teams that find out at the end of the month; the budgets post's review ritual only works because the numbers are visible before the meeting.

And visibility is the precondition for every guardrail in this series. An alert needs a number to watch; a budget needs a boundary to compare against; a review needs a history to read. The operations layer is where all three live.

For a prototype, a hackathon, a solo founder — one key is fine, and the entire apparatus above is ceremony. The layer exists to contain the cost of mistakes, and a project with no other people and no paying customers has small mistakes.

The trigger to upgrade is boring and specific: the first time two things need different limits, the first time spend needs attributing to a team, the first time a key leaks. Any one of those means the layer has stopped being ceremony and started being load-bearing.

What is never fine, at any scale, is the production key living in a shared document. That is not simplicity; it is a scheduled incident.