Sign in from the CLI

Sign in from your terminal. If you are new to EvalRouter, you can create your account in the browser it opens; verify your email when asked.

evalrouter login

When the browser can return to this computer, the CLI offers to open it. Press Enter, choose your account, and finish sign-in at auth.kimpton.ai. The browser returns to the waiting CLI; there is no device code. The browser page then shows the result: the email you signed in as, or what went wrong. If sign-in wasn't completed, choose Try again.

To sign in with a one-time code instead, run:

evalrouter login --no-browser

The CLI prints a code and URL. Open the URL on a device with a browser and approve the code. Keep the command running while you do this. The CLI also uses this flow if the browser callback is unavailable, and says so.

For a device-code sign-in, check that the account and code are yours, then choose Continue to Kimpton sign-in. The next page is auth.kimpton.ai:

1. Confirm your terminal code.
2. Sign in if asked, even if EvalRouter already recognizes your account.
3. Keep the tab open until it says Device connected. Confirming the code alone does not finish sign-in.

Keep the terminal command running. When sign-in finishes, it shows your email and workspace. It selects your only workspace, the one named with --workspace ID_OR_NAME, or one you pick. Connecting costs nothing; paid runs need credit.

If sign-in fails, the browser page or the terminal says why. Fix that, then run evalrouter login again. A failed attempt leaves older CLI credentials in place.

If you visit /device directly during a code flow, run evalrouter login first and enter the code it gives you. If the code expires or you close the browser before completion, cancel with Ctrl+C and run evalrouter login again. The CLI issues one code per command and exits on expiry. Your account and workspace are preserved. Use Use another account if the browser shows the wrong identity.

Older CLI versions may start with a device code even when the browser callback is available, or wait for account setup after device approval. Update with uv tool upgrade evalrouter for the current flow.

On a remote machine, open the code URL on your own device. For unattended agents and CI, use a scoped workspace API key.

The CLI never asks for your password. It saves and refreshes sessions locally. Run evalrouter whoami to check your account and workspace.

Use any of your sign-in methods#

Signing in with Google or with email and password opens the same EvalRouter account when both use the same verified email. This works on the website and in the terminal. The terminal always shows the email you signed in as, so check that it is the account you expect.

Settings > Account > Sign-in methods lists the methods connected to your account.

Store a workspace API key#

Where browser sign-in is not an option, store a workspace key with the same credential storage. The CLI never takes the key as a command argument. In a terminal it asks with hidden input; otherwise it reads the key from stdin:

evalrouter login --with-api-key
# EvalRouter API key (input hidden):

printf '%s' "$EVALROUTER_KEY_FROM_SECRET_MANAGER" | evalrouter login --with-api-key

The CLI checks the key with the API before saving it and never prints it. One server keeps either a device sign-in or a stored key: storing a key signs this device out (revoking its sign-in), and evalrouter login replaces a stored key. evalrouter logout deletes it.

Precedence and automation#

The CLI uses the first of these it finds: EVALROUTER_API_KEY, then a key stored with login --with-api-key, then a stored sign-in. EVALROUTER_API_KEY always takes precedence, so scripts and CI keep using workspace keys unchanged. In a non-interactive shell the CLI never prompts; without a key or a stored sign-in it fails with an error asking you to run evalrouter login or set EVALROUTER_API_KEY. --json keeps the result on stdout and the sign-in code on stderr.

Access and revocation#

Each workspace a device uses is a separate signed-in device entry. It grants evaluation reads and read-only access to the workspace credit balance and billing records, plus evaluation writes when your workspace role allows them. Your current workspace membership and role are checked on every request: if you are removed from a workspace, the device stops working there immediately. A CLI sign-in cannot create API keys, add credit or change billing settings. A device signed in before credit reads were available is asked to run evalrouter login once more; it is never upgraded silently.

Review and revoke signed-in devices in account settings. Revocation takes effect on the device's next request. evalrouter logout revokes the device on the server and ends the sign-in before deleting local credentials.

Local credential storage#

The CLI uses an available operating-system keychain, falling back to a private file readable only by your user. No extra installation is needed for sign-in. A system permission prompt may appear when the keychain is used. Tokens are never printed. logout removes the stored session as well as revoking device access.