Self-hosted Claude Code: restricted mode, cross-session messaging, and a hard budget cap
On September 1 Anthropic opened a public beta of self-hosted environments for Claude Code on Team and Enterprise plans. A session runs on your own infrastructure, with access to your internal network, your own tooling and your compliance controls. It arrives days after the late-August batch that added restricted mode, cross-session messaging between agents, Enterprise usage credits, better diagnostics for server-managed settings, remote control and prompt caching improvements. Together those two drops turn Claude Code from a SaaS coding agent into something you can put inside a regulated perimeter.
What shipped, in order
The late-August release (around August 28) is the runtime half. Restricted mode is a locked-down operating profile for the agent. Cross-session messaging lets separate Claude Code sessions, and the agents inside them, send messages to each other. Server-managed settings now come with diagnostics that tell you which policy applied and why.
The September 1 release is the deployment half. Self-hosted environments run the session where your code and data already live, so nothing has to leave the network to be edited. On the platform side, Managed Agents get a hard budget cap: when a run hits it, the API returns the stop reason budget_reached and the agent stops. The Enterprise default model is now Opus 5. And Sonnet 5 stays at $2 per million input and $10 output; the planned increase was cancelled, so leave existing cost models alone.
Why the regulated case finally works
Before this, the blocker for banks, healthcare and public-sector teams was never the model. It was that the agent ran somewhere else, touched a clone of the repository somewhere else, and made network calls the security team could not see. Self-hosting closes that. Restricted mode gives you a profile to hand to a compliance reviewer. Server-managed settings with diagnostics give you an audit answer to "which policy was in effect when this happened".
The budget cap is the piece I would have asked for first. An agent that loops on a failing test at frontier prices is a finance incident, not a bug. A stop reason you can catch and alert on turns that into a bounded cost.
An agent inside your network with no spend ceiling is a compliance win and a budget risk at the same time; you need both halves.
Agent-to-agent messaging as a pattern
Cross-session messaging deserves a closer look because it is not just convenience. It is the primitive for a fleet: one session plans, several implement in worktrees, one reviews, and they coordinate through messages instead of a shared file that everyone races on. Every message channel is a path for one agent's mistake, or one injected instruction, to propagate to the others. Treat the message bus like any other tool input: log it, scope who can send to whom, and keep a human gate before anything irreversible. The rules I laid out for sandboxing coding agents apply to the channel between sandboxes too.
A deployment checklist
- Network: decide up front which internal hosts a self-hosted session may reach, and enforce it at the network layer, not in the prompt.
- Profile: start every regulated project in restricted mode and relax deliberately, with the diagnostics output attached to the change request.
- Spend: set budget_reached thresholds per agent role; a reviewer should not have a planner's budget.
- Identity: give each session its own scoped credentials. This week a shared authentication failure took Microsoft 365 Copilot down for two days along with Exchange and Teams; an agent inherits every weakness of the identity layer under it.
- Caching: self-hosting does not change the token bill, so keep prompt caching on; the mechanics are in prompt caching deep dive.
- Messaging: enable cross-session messaging only for roles that need it, and record every message.
The honest gap
Self-hosted environments are a public beta, and the release notes describe what they enable rather than what they cost or how they are operated at scale. I have not seen documentation of what air-gapped means in practice: whether a session can run with no outbound path to Anthropic at all, or whether the model calls still leave the network while only tool execution stays inside. For most regulated teams that distinction decides the whole project, and it is the first thing to test in the beta.