Orgs and keys

The question this page answers: which organization does my data land in, and how do I check?

The short answer: one key = one org. A rig_sk_ key belongs to the organization it was minted in, and every row it exports lands there. Which organization you happen to be viewing in the console doesn't change that. The rest of this page is how to see which org a key belongs to, how the console decides which org it shows you, and what to do when the two disagree.

Why "valid key, wrong org" looks like an empty console

Telemetry export never blocks or fails your pipeline, by design. So a key that is valid but belongs to a different organization produces no error anywhere: your runs export successfully, into the other org. From the console you're watching, that looks exactly like "nothing is being recorded". It's the most common reason a working pipeline shows an empty /runs, and it's why every on-ramp in these docs has a "confirm the org" step.

Confirm the org before you trust an empty console. Run modelrig doctor from the same environment your app runs in, once your app has started with the key. It asks GET /v1/whoami which organization the key belongs to and prints the org's name and, in parentheses, its slug; the name must match the org badge in the console header. If it names a different organization, your data is landing there: switch the console to that organization, or mint a key in the one you meant (https://modelrig.dev/orgs-and-keys.html).


npx modelrig doctor
# [modelrig] key rig_sk_…AbCd → org «Your Org» (your-org) ✓  (ingest https://api.modelrig.ai, …)

# No CLI in that environment? Ask the API directly (same host the SDK uses):
curl -H "Authorization: Bearer $MODELRIG_API_KEY" "${MODELRIG_INGEST_URL:-https://api.modelrig.ai}/v1/whoami"

Three ways to see a key's org

Where	What you run or look at	What it tells you
CLI	`npx modelrig doctor`	`key rig_sk_…AbCd → org «Your Org» ✓`. On a rejected key it prints `AUTH FAILED (401)` and exits non-zero. With no key in the environment it prints `no export sink configured`.
API	`GET https://api.modelrig.ai/v1/whoami` with `Authorization: Bearer $MODELRIG_API_KEY`	JSON: `org` (`id`, `name`, `slug`), `key` (`name`, `last_four`, `scopes`) and the org's capture `posture`. No scope is needed; a revoked or unknown key gets `401`.
Console	The org badge in the header	The organization every page is showing you. Compare it with the name `doctor` printed.

Run doctor (or the curl) from the same environment your app runs in: on a hosted worker that means a shell on the worker, not your laptop. Your laptop's .env may hold a different key from the one the worker reads. See Deploying.

To see what a key's org actually contains, without the console, use the key-authenticated read API:


curl -H "Authorization: Bearer $MODELRIG_API_KEY" https://api.modelrig.ai/v1/read/runs

If your runs are listed here but not in the console, the key and the console are looking at different organizations.

How the console chooses an org

The console shows one organization at a time, and every page (Runs, Calls, Costs, Routes, Bake-offs and the rest) reads only that organization's rows.

You belong to one organization. The console uses it automatically.
You belong to several. Choose one in the header picker. Until you do, pages show a "Choose an organization" prompt instead of data; the API answers that read with 409 org_required. The picker's choice applies to every page you read, not only to what you create.
Your organizations couldn't be loaded. The prompt says "We couldn't load your organizations — retry in a moment". Reload the page; it never shows an empty picker or another organization's data.
Your session has expired. Pages say "Your session expired — sign in" (the API answers 401 session_expired). You never see another organization's data, or the public demo, in its place.
The sign-in service is briefly unreachable. The API answers 503 auth_unavailable. That's an outage, not an expired session: retry in a moment, and you don't need to sign in again.
Signed out entirely. The console shows ModelRig's own public demo traffic, under a "You're viewing the demo — sign in to see your rig" callout.

Coding agents and scripts that read the console API pass the chosen org in the x-modelrig-org header. A header naming an organization you aren't a member of gets 404 not_found, the same answer as one that doesn't exist.

Make a mismatch loud

Two guards turn a wrong-org key into a visible failure instead of a quiet one:

In CI or after a deploy: npx modelrig doctor --expect-org <slug> exits non-zero when the key belongs to any other organization. Take the slug from the org.slug field of /v1/whoami.
In your app: pass expectOrg when you create the rig:

``ts const rig = createRig({ ...loadConfigFromEnv(), expectOrg: "your-org-slug" }); ``

On the first export the SDK logs one line naming where your data is going, [modelrig] exporting to org «Name» (slug) as key «name» rig_sk_…last4. If the key resolves to a different organization, it logs ORG MISMATCH on every flush until you fix the key. It never blocks the export and never throws.

Fixing a wrong-org key

1. Decide which organization the data belongs in. 2. If it's the org the key already names, switch the console to that org. Nothing else needs to change. 3. Otherwise, in the console, switch to the org you want, open API keys, and mint a new key there. 4. Replace MODELRIG_API_KEY everywhere the old one was set: every service, worker and cron. On a hosted platform, redeploy and confirm from a new shell (Deploying). 5. Run doctor again and check it names the right org. Then revoke the old key.

Rows that already landed in the other organization stay there. Re-pointing the key changes where new rows go.

Key basics

Mint a key in the org you want the data in. Sign in at https://app.modelrig.ai, check the organization name in the header badge, and create a key on the API keys page. The rig_sk_ secret is shown once. One key = one org: every row the key exports lands in the organization it was minted in, whichever organization you happen to be viewing in the console. Set it on every service, worker and cron that creates a rig; your provider keys stay where they are.


# Wherever your app reads configuration: .env.local, your platform's env vars, a secret manager. Never in code.
MODELRIG_API_KEY=rig_sk_…

The secret is shown once, when you create the key. The API keys page keeps only its name and last four characters. If you lost the secret, rotate the key.
A key carries scopes. Telemetry export needs ingest; other scopes cover grades, proposals, live route config and managed serving. Mint the narrowest key that does the job.
Rotating or revoking a key takes effect immediately. A process still holding the old key gets 401 on its next export; doctor and the SDK's AUTH FAILED warning both say so.