Claude Code for teams

Searches for “Claude Code teams” mostly mean Claude for Teams, Anthropic’s self-service plan, so start there. It needs at least two members and supports up to 150 seats. A standard seat is $25 per member per month, or $20 billed annually, with 1.25 times Pro’s per-session usage; a premium seat is $125, or $100 annually, with 6.25 times. Claude Code is included on every seat, and limits are per member — the same five-hour session and weekly windows as Pro and Max, shared with Claude chat.

Members install Claude Code and /login with the account the admin invited, choosing the Team plan at the authorization prompt. Admins get billing, seat management, an analytics dashboard with daily active users and sessions, and a spend report once usage credits are turned on — credits let members keep working past the seat allowance at API rates, capped at the organization, group, or member level. Remote Control is off by default on Team and Enterprise until an Owner enables it, and cloud sessions depend on an organization policy an Owner controls.

Enterprise is Team plus the controls a security team asks for: SSO and domain capture, SCIM, audit logs, role-based permissions, a compliance API, custom data retention, and managed settings that push a Claude Code configuration to every machine and cannot be overridden locally. Billing changes shape — a seat fee for platform access, with all usage billed at standard API rates and no per-seat limits. Self-serve Enterprise starts at 20 seats; sales-assisted at 50.

Two other routes exist for organizations that want metered billing without a claude.ai plan: the Claude Console, where each developer gets a key in a “Claude Code” workspace with spend limits, and Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry, where the CLI bills to the cloud account and the web features — Remote Control, cloud sessions, Claude on the web — do not apply.

What the plan and the files do not cover is where the agents run. A team’s Claude Code sessions are spread across every laptop, a shared build box, the Mac mini someone set up for overnight runs, a GPU host. Each is reached its own way; each person keeps their own tmux discipline; Remote Control shows each member only their own sessions, one per process. The question a lead actually asks at four o’clock — what is running right now, on which machine, and what is it waiting for — has no answer in the plan.

That is where spawnd fits. One daemon on each host you own; it dials out, so nothing listens and there is nothing to expose. Workspaces, one per project, put sessions from every host in one grid, with attention cues when an agent waits on a yes and notifications on the phone. Access is by device: a new device is approved once against a short code, and revoking it is one click every host honors. Agents authenticate on the host, so each person’s seat is used exactly as the CLI uses it, and spawnd holds no provider credentials. Every session’s PTY is owned by a worker process on the host, so an overnight run survives the closed laptop; your browser talks to each daemon peer-to-peer, end-to-end encrypted, and the server that introduces them never sees session content. Workspaces per project and per-device approval give a team one console over its own hosts — the plan supplies the seats, the repository supplies the practice, and this supplies the machines.