Admin guide · Platform
Developer tools
Let developers point Claude Code at the gateway with a personal identity token, so their coding-agent sessions are recorded alongside the rest of your traffic. The switch and the org-wide token list live at Admin → Developer tools.
What you are enabling
Visibility, not a new way to spend money.
- Each developer mints their own token and sets two environment variables. Their own claude.ai login still authorizes every call — the gateway relays the request untouched and records the trace.
- A developer token is an identity, not a credential. It grants no access to models, keys or endpoints, and it consumes no organization budget: these calls are billed to the developer's personal subscription, so every cost column on the resulting traces is a structural zero.
- It is self-service by design. Every member can mint and revoke their own tokens; no administrator is in the loop for day-to-day use.
The org-wide switch
A kill switch, not a way to hide the page.
The capability ships disabled and has to be turned on explicitly. Until it is, developers see the feature in their sidebar with a note that the organization has not switched it on.
warning · Switching it off breaks existing tokens
Auditing and offboarding
The question the list exists to answer: who still has a working token?

The token list covers every token minted in the organization, with its owner, and is sorted active-first rather than purely by date — so the rows that still work are the rows you see. It is paged and searchable by token name, owner email or owner name. Clicking a row opens the sessions that token carried.
| Field | Type | Description |
|---|---|---|
| Revoke | any token | Stops the token working at the gateway. Traces already recorded are kept and the row stays visible, so the history remains auditable. This is the offboarding action. |
| Delete | any token | Removes the row entirely — nothing in the list shows it ever existed, though the audit log keeps the record. Recorded sessions are NOT removed: they stay, attributed to the developer, no longer linked to a token. |
| Regenerate | owner only | Deliberately has no admin override. The flow reveals a plaintext token that files sessions under the owner's name, so anyone else holding it could impersonate their developer identity. |
note · Revoke, then decide about delete
Who can do what
Self-service for everyone, org-wide reach for owners and admins.
| Field | Type | Description |
|---|---|---|
| developer_token:create · :read · :revoke | owner · admin · member | Mint, list and revoke your OWN tokens. Every role holds these — that is what makes the feature self-service. |
| developer_token:read_all | owner · admin | See every token in the organization, with owners, and read any developer's sessions. |
| developer_token:revoke_any | owner · admin | Revoke or delete someone else's token. |
| developer_tools:update | owner · admin | Flip the org-wide switch. A member cannot enable the capability for the organization. See Users & roles. |
note · A pasted admin URL degrades safely
developer_token:read_all the developer parameter is ignored and the reader sees their own sessions, rather than a broken page or someone else's data.Retention
A fixed 30-day cap, separate from the org policy.
Coding-agent traces are capped at 30 days, rows and payloads alike. The cap is not org-configurable, and it is deliberately much shorter than the default generation window: these are development diagnostics rather than billing or audit records, and their volume profile is inverted — hundreds of turns per session, each payload carrying the agent's whole context window.
note · Shorter org policies still win
What developers need from you
Then point them at their own page.
- The Developer tools feature entitled for the organization, and the switch on.
- Nothing else — they mint their own token and configure their own client. The setup they need is on Developer tools in the developer guide.