Claude / Anthropic Admin Cheat Sheet

Team and Enterprise have fixed roles: Owner, Primary Owner, Admin, and Member. Enterprise adds custom roles that grant feature access at the group level — members set to “Custom” get no default permissions at all; their access comes entirely from the custom role on their assigned group.

There is exactly one Primary Owner per org, and it can be a service account rather than a person. If you don’t know who holds it, check Settings → Account.

Add and remove members, change roles, and manage pending invites. On Enterprise the same operations are available programmatically through the Admin API (see Part 2).

SSO applies to Team, Enterprise, and Console orgs alike. It requires domain verification in Identity and access settings first, and SCIM provisioning requires SSO to be working end to end before it will work at all — getting that order backwards is a very common setup mistake.

Groups can be created by hand or synced from your identity provider, and custom roles control feature access per group — “only Engineering gets Claude Code,” for example.

Watch for this: members left on the built-in User role bypass group restrictions entirely and get everything that’s enabled org-wide. Worth flagging to any client who believes they’ve restricted access.

Per-member spend caps can be set over a recurring period. The practical pattern is group-level caps as a baseline, with individual overrides for the outliers.

Admins and above can set org-wide custom instructions that Claude follows in every conversation — formatting standards, required compliance language, and the like. Org-level instructions override conflicting individual instructions.

Enterprise adds audit logs covering user actions, system events, and data access, plus the Compliance API for programmatic access to activity logs, chat histories, and file content, filterable by user and time range.

Several product surfaces are disabled by default and have to be turned on org-wide before anyone can use them.

Daily, weekly, and monthly active users by product live under Analytics in org settings. The same dashboard breaks usage and cost down by group and by user — filterable by SCIM group — and shows output metrics such as artifacts created, files edited, and skills or connectors used right next to the cost.

This is the one that trips people up live on a call, so it gets a full walkthrough. It lives under Organization settings → Usage.

• •Spend limits by user — a table of each member’s usage against their limit, including an MTD Spend column, so you can see who is actually consuming budget rather than just who has a high cap.
• •Review requests — when a member hits the usage included with their seat, they see a “Request usage credits” link. That sends a request to org Admins and Owners, who review it under Organization settings → Usage → Review requests. Each pending request shows the requester, their current seat, and when they asked; approving there is what actually raises that member’s limit. On Enterprise the same approval can be done through the Spend Limits API.
• •Extra usage — org-wide overflow, separate from per-user limits. Enabling it lets members keep working past their seat’s included usage instead of being blocked, billed at standard API rates. Team plans pre-purchase a pool with a spend cap; Enterprise plans are billed for actual overflow monthly. It can be scoped to specific users or to the whole org.
• •Claude Tag (Slack) usage — bills against the org’s shared usage balance rather than per seat, so it never shows up under per-user limits. Its spend cap has its own page at claude.ai/admin-settings/usage/claude-tag.

Regular API keys are created in Account Settings. Admin API keys (prefix sk-ant-admin...) are a different thing: one key authenticates the Admin API, the Analytics APIs, the Compliance API, the Spend Limits API, the Usage and Cost API, and the Rate Limits API all at once.

Only members with the admin role can create them, and Console admin keys carry full access with no selectable scopes — Enterprise-side keys, by contrast, do use selectable scopes.

Console orgs use workspaces to segment resources, keys, and usage. Useful for consultants running several client projects under one org, and for clients who want dev and prod kept apart.

Left nav in the Console → Usage. Visible to the Developer, Billing, and Admin roles.

• •Breaks usage down by model, date and time, and API key — click into the bar chart for hour or minute granularity.
• •Filters for specific models, months, or keys, with total input and output token counts.
• •A separate Cost view shows dollar spend rather than tokens.
• •Flags rate-limited requests — useful for diagnosing “why did our integration start failing” tickets.
• •Playground and Workbench usage appears here too, but with a null api_key_id, since it isn’t tied to a specific key.
• •The Usage and Cost API returns the same data the Console page shows (Admin API key required) — reach for it when a client wants the numbers piped into their own dashboard or finance tooling.

Console → Settings → Billing.

• •Shows the current prepaid credit balance and invoice history.
• •Buy credits adds prepaid balance, and auto-reload can be switched on with a minimum-balance threshold and a reload amount, so the account tops itself up instead of hard-stopping.
• •The payment method is edited here too, via the pencil icon next to the card on file — requires the Admin or Billing role.
• •Credits expire one year from purchase and are non-refundable — worth saying out loud before a client over-buys.

Console → Rate limits.

• •Shows the organization’s current usage tier and the limits that come with it (RPM and TPM per model), charted against actual usage.
• •The Request rate limit increase button on that page is how you formally ask Anthropic for a higher tier or a higher monthly spend cap. It’s the Console-side counterpart to the claude.ai review queue in §1.10 — except this request goes to Anthropic, not to an internal org admin.
• •Separately, a workspace-level spend limit lives at Console → Settings → Billing → Spend limits. It caps one workspace’s spend regardless of tier, and hitting it returns an invalid_request_error — distinct from a rate-limit 429.

These endpoints are the one exception to “the Admin API key does everything” — they require an OAuth bearer token with the org:admin scope instead.