Manage keys with the CLI

Use the CLI when your installed release supports keys; confirm with local help. Sign in and run unlimgpt whoami --json before changing credentials: plain whoami prints the email, while JSON also contains the organization ID. Match that ID with the organization selected in your browser. You need permission to manage its keys and an available operating-system credential store. An API key authenticates API requests; it is separate from your browser session and the CLI's OAuth grant.

Create and inspect

unlimgpt keys list
unlimgpt keys list --json
unlimgpt keys create --name Workstation --expires-in 90d

The plain list shows ID, name and active state. JSON additionally exposes safe metadata such as expiry and last use when present; neither format prints the full key or hash. Use a workload-specific name and an expiry no longer than the CLI's 90-day maximum. Creation stores the secret in the operating-system credential store and selects the new key for the active CLI profile. For a new client, configure can create a dedicated key as part of setup. If the secure store is unavailable, the CLI fails closed: do not move the secret into a plaintext config file to work around it.

Verify the new key with the free model catalog before relying on it for a paid request. Confirm that the organization and visible models are the ones expected. A successful list command only proves that you can read key metadata; it does not prove a particular client is configured to use a new secret.

Change permissions

Check unlimgpt keys permissions --help in your installed release. An owner or administrator of the selected organization can replace a key's permissions:

unlimgpt keys permissions KEY_ID --scope models:read --scope inference:write --json
unlimgpt keys permissions KEY_ID --scope models:read
unlimgpt keys permissions KEY_ID --clear

Repeat --scope for each permission. The second command keeps only catalog access and disables generation; --clear removes both permissions. Supply an explicit set or --clear, never both. The server checks the organization and permission to update the key. This does not select a different profile key, change its secret, expiry or budget, or expand organization or plan access. JSON returns safe metadata without the full key, hash or internal metadata. A server rejection produces a non-zero exit; local credentials stay unchanged.

Set key limits

Use the native policy command when a workload needs narrower access than its organization:

unlimgpt keys policy KEY_ID --policy '{"allowedModelIds":["gpt-5.6-sol"],"allowedFeatures":["streaming"],"concurrencyLimit":2,"rateLimit":{"max":10,"windowMs":60000}}' --json

The JSON object replaces the complete policy and must contain all four fields. null inherits the organization or plan setting; an empty array denies every model or capability. Limits are positive whole numbers. The command uses the selected organization and returns safe metadata only; it cannot change the secret, expiry, permissions, budget lineage, or organization settings. Use model IDs from the catalog; new model and capability IDs do not require a CLI release.

Rotate or revoke

unlimgpt keys rotate KEY_ID --client codex
unlimgpt keys revoke KEY_ID

Use keys rotate only when you know every consumer of the old key and all can be updated automatically by the CLI in that command. Supply --client for each such client. Do not use automatic rotation for Cursor, Cline, Roo or another guided or manually configured consumer: the published CLI cannot verify its native secret field, and it cannot discover a consumer you omit. Rotation creates a replacement, updates the named automatic clients, verifies the new key through the free model catalog, then immediately attempts to revoke the old key. A complete result does not prove a real request worked in every client.

If the key is shared with a guided, manual or otherwise unlisted client, use a staged change instead. For a mix of CLI-managed and guided clients, create the replacement with unlimgpt keys create --name RotatedWorkload: this stores it for the active CLI profile. Use configure to update each client, paste the key into guided clients' native secret fields, send a real request from each while the old key still works, and only then revoke the old key by ID. A key created in the browser cannot be imported into the CLI profile; use API keys for a fully manual group of clients. Prefer a separate key per workload to make the next rotation independent. The structured rotation result distinguishes complete, rolled_back and revoke_pending. On revoke_pending, the replacement works in the catalog but the old key still needs explicit revocation. On rolled_back, review the key list and any client receipt before retrying; a non-zero exit does not prove that no key was created.

Revoke by the key ID shown in the current organization's list; the command asks for confirmation. In non-interactive automation, review the exact ID before using --yes. Revocation stops that key, but does not sign out browsers or revoke the CLI OAuth grant. Re-check the list and test any replacement client after the change. You can perform the same lifecycle in API keys. See credential security for storage and account security for a lost device.