Claude Code Enterprise Setup: Managed Settings

At small scale (under 10 engineers), Claude Code runs locally, everyone trusts the same model, and costs are predictable. At 100+ engineers spread across offices and remote, that model breaks. Each engineer has a different machine, operating system, installed tools, and network environment. Pushing policy updates—"switch from Sonnet to Opus," "enforce zero-data retention," "add spending caps"—requires shipping new configuration to every device, syncing it, and trusting everyone applied it the same way.

Centralized settings invert this: the company defines policy once (in a database or config service), and Claude Code instances fetch it on startup. If you need to change a model, adjust permissions, or tighten spending caps, it takes seconds—no restart, no per-device deployment, no sync problems.

The boundary between the two is clear: "what to allow" lives centrally; "how to execute" stays local. A centralized setting says "this team can use Claude Opus"; the local Claude Code instance interprets that and enforces it in the user's context.

A Claude Code instance needs to know: "Which model can I use? How many tokens this month? Is extended thinking allowed? What's the compliance mode?" All of this comes from a single settings API that the instance polls on startup and periodically refreshes.

The API is stateless and versioned. A request includes the instance's user ID, team, and environment. The response includes the effective policy: model list, spending cap, feature flags, and compliance settings.

No network access doesn't mean no settings. Instances cache the last known good settings locally (encrypted on disk) so they work offline for at least one session. If the network is unavailable, the instance falls back to the cached config; if the cache is stale (older than 24 hours), it warns but continues.

Once settings are loaded, Claude Code enforces them locally. If a user tries to use "claude-3-5-opus" but their team's policy only allows "claude-3-5-sonnet", the request is rejected before it hits the API. If they've exceeded their monthly spending cap, new sessions refuse to start.

Permission checks happen at two levels: the UI (reject disallowed options early) and the execution layer (prevent any call that violates policy). This dual enforcement ensures no accidental spend or compliance breach.

For federated or multi-region deployments, settings can include region-specific policies (e.g., "GDPR data must stay in eu-west-1"). Claude Code checks the user's current region and rejects requests if they violate residency rules.

New Claude Code features—computer use, vision, extended thinking, artifacts—are risky at scale. A bug in one could affect 500 engineers and halt productivity. Feature toggles let you roll out features gradually: 10% of engineers for 1 week, then 50%, then 100%.

Each feature has a flag in the settings: enabled (true/false), rollout_percentage (0–100), and excluded_teams (teams that must not see it). When a user's settings are fetched, the backend computes: "Is this feature enabled for this user?" It rolls a dice (user_id hash mod 100) and checks if it falls within the rollout range. If yes, the feature appears; if no, it's hidden.

If a feature breaks, you flip the flag to false, and it disappears from everyone's next settings fetch. No restart, no deployment, no rollback—just a database change.

Every Claude Code session must report: tokens consumed, model used, team, user, timestamp, and outcome (success/error). These events flow to a central analytics pipeline (e.g., Kafka or cloud event hub), are aggregated, and power dashboards, alerts, and usage reports.

The architecture: each Claude Code instance logs events locally, batches them, and sends to a collector endpoint. The collector de-duplicates, parses, and publishes to a data warehouse. Dashboards query the warehouse to show spend per team, per user, per model, and trend over time.

Costs are calculated per model per token type (prompt vs. completion). You maintain a cost matrix (e.g., Sonnet: $3/1M prompt tokens, $15/1M completion tokens) and apply it during aggregation. This lets you predict spend, allocate budgets, and chargeback to cost centers.

Not all teams should access all models. Finance teams may only use Sonnet (cheap, fast) for routine expense categorization. Research teams need Opus (smarter, slower) for complex analysis. This variation is encoded in team-level settings.

When a user's settings are fetched, they include their team's allowed_models list. The UI shows only those models. If a prompt tries to use a disallowed model, it's rejected.

For progressive rollout or A/B testing, you can configure model weights: "This team: 80% Sonnet, 20% Opus by default." If the user doesn't specify, Claude Code picks based on those weights.

Storing settings in a database is fine, but it's not version-controlled. Configuration-as-code treats settings like source code: checked into Git, reviewed in pull requests, deployed via CI/CD, and rolled back if needed.

A simple pattern: Git holds the source of truth for all settings. A YAML or JSON file per team describes their policy. A pre-commit hook validates schema. On merge to main, a GitHub Action (or equivalent) deploys settings to the API backend. Audit logs record every deploy with author, timestamp, and change.

This keeps policy auditable and reversible. If a change breaks compliance, you revert the PR, and the old settings are restored instantly.

A 500-engineer company (Product, Engineering, Finance, Research, Ops) decides to roll out Claude Code with centralized settings. Week 1: Settings API is live, all teams fetch from it. Week 2: Roll out extended thinking to 20% of Engineering for feasibility testing. Week 3: Expand to 50% of Engineering. Week 4: Full rollout to Engineering, exclude Finance (not needed). Week 5: Expand to 10% of Research. Weeks 6–8: Gradual rollout to Research, monitor costs.

In parallel, Finance sets a $500/month cap, Ops monitors errors and latency, and Leadership see a dashboard showing $2K/month total spend, trending up as more teams adopt.

A bug is discovered in week 3: extended thinking causes occasional timeout errors in 5% of calls. The team flips enabled=false in the feature config (one-line change), and within seconds (next settings refresh), extended thinking is hidden from all users. No restarts, no sync issues. The next morning, the bug is fixed and rolled out to 5% again.

This flow is impossible without centralized settings. Each engineer would need a manual config update, coordination would be chaotic, and rollback would be slow and error-prone.