Sign in from the CLI

evalrouter login opens your browser at auth.kimpton.ai. After you sign in, the browser hands the session back to the waiting CLI, which then selects a workspace.

evalrouter login
evalrouter whoami

The CLI offers to open the browser. Press Enter, choose your account and finish at auth.kimpton.ai. The browser returns to the waiting CLI and shows the email you signed in as, or what went wrong. Choose Try again if sign-in wasn't completed.

When sign-in finishes, the CLI shows your email and workspace. It selects your only workspace, the one named with --workspace ID_OR_NAME, or one you pick. Signing in costs nothing. Paid runs need credit. The CLI never asks for your password.

Sign in with a code#

On a remote machine, or when the browser can't return to this computer, use a one-time code. The CLI also falls back to this flow, and says so.

evalrouter login --no-browser

1. Open the printed URL on any device and check that the account and code are yours.
2. Choose Continue to Kimpton sign-in, confirm the code and sign in if asked.
3. Keep the tab open until it says Device connected, and keep the command running. Confirming the code alone doesn't finish sign-in.

The CLI issues one code per command and exits when it expires. If the code expires or you close the browser, press Ctrl+C and sign in again. You keep your account and workspace. Use Use another account if the browser shows the wrong identity. If you open /device directly, run evalrouter login first and enter its code.

A failed attempt says why and leaves older CLI credentials in place. Older CLI versions may start with a code even when the browser can return. Upgrade with uv tool upgrade evalrouter.

Commands#

Google and email-and-password sign-in open the same account when both use the same verified email, on the website and in the terminal. Settings › Account › Sign-in methods lists them.

Store a workspace API key#

For unattended agents and CI, use a scoped workspace key. The CLI never takes it as an argument: it asks with hidden input at a terminal, or reads stdin.

evalrouter login --with-api-key
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. A device keeps either a sign-in or a stored key: storing a key revokes the sign-in, evalrouter login replaces a stored key, and evalrouter logout deletes it.

The CLI uses the first credential it finds:

1. the EVALROUTER_API_KEY variable
2. a stored key
3. a stored sign-in

In a non-interactive shell it never prompts. With no credential it fails and asks you to sign in or set the key variable. With --json, the result goes to stdout and the sign-in code to stderr.

Access and revocation#

Each workspace a device uses is a separate signed-in device. It can read evaluations, the credit balance and billing records, and write evaluations when your role allows. EvalRouter checks membership and role on every request. Removal from a workspace takes effect immediately. A CLI sign-in can't create API keys, add credit or change billing settings. A device signed in before credit reads existed must run evalrouter login once more. It is never upgraded silently.

Review and revoke devices in account settings. Revocation applies on the device's next request. evalrouter logout revokes the device on the server before deleting local credentials.