Logo Header

Company playbook

Claude Code Usage

Table of Contents

TL;DR

  • Personal projects? Not on the work account, for now. For personal work, use a separate profile signed in with your own personal Anthropic account — the claude-personal alias or a separate OS user — so it draws on your limits, not the company pool. Details
  • Usage is finite and shared. Claude Code, Claude.ai chat, and Cowork all draw from the same pool (a rolling session window plus a weekly limit). There's no Copilot fallback anymore, so budget deliberately.
  • Hit your limit? Wait for the window to reset, or ask the platform team (#support-hr) about your extra allowance. No self-service upgrades; don't enable pay-as-you-go API credits on the work account.
  • Settings are managed. Signing in with your SparkFabrik account applies org-managed policy automatically — it takes precedence over your own settings and can't be overridden.

This page covers policy and limits. For installation, authentication, and the Agent SDK credit, see Tools and setup.

Usage limits

Unlike GitHub Copilot — which was, in practice, effectively unlimited for us — Claude Code runs on a finite usage budget provided through the SparkFabrik organization's Anthropic plan. Understanding the limits is now part of using the tool well.

How the limits work

Usage is shared across all interactive surfaces: your Claude Code sessions (terminal and IDE), Claude.ai chat, and Cowork all count against the same limits. Heavy chat use eats into the budget available for coding, and vice versa.

There are two windows:

  • A rolling session limit (a usage window that opens with your first message and lasts a few hours).
  • A weekly limit on a rolling 7-day window — not a fixed calendar reset. The window is tied to your own usage (it starts from your first activity in the cycle), so the reset moment differs per person and shifts over time. There's no "fresh quota every Monday morning" to plan around; check yours with /usage (press w).

As you approach a cap, Claude Code warns you about remaining capacity. When you hit it, the default option is to wait for the window to reset.

We provide each user with an extra usage allowance on top of the base limits. We do not support self-service plan upgrades for now. If you exhaust your allowance, contact the HR team (#support-hr) — we adjust it case by case for specific, justified needs rather than blanket upgrades. Do not opt into pay-as-you-go API credits on the work account; route the request through us instead.

The exact thresholds change over time, so we intentionally do not list numbers here. Check your own current usage and remaining capacity with the /usage command inside Claude Code (press w for the last 7 days).

Headless usage is separate. claude -p and Agent SDK usage draw from a distinct monthly credit and do not count toward these interactive limits. See Agent SDK and headless usage.

What changed from Copilot

With Copilot, the cost was a flat seat and capacity was a non-issue. With Claude Code, capacity is a shared, finite resource. The practical implications:

  • Budget deliberately. Reach for plan mode and scoped prompts on large tasks; avoid burning the weekly window on exploratory chat you could do elsewhere (remember we all have high-limits access to Gemini with our company accounts).
  • Match the model to the task — your biggest lever. Sonnet handles most coding well and costs far less of your budget; Opus burns through the weekly limit much faster. Default to Sonnet and reserve Opus for genuinely hard problems (architecture, gnarly multi-step reasoning). Switch mid-session with /model, or set a default in /config. Per the official guidance: "Sonnet handles most coding tasks well and costs less than Opus. Reserve Opus for complex architectural decisions or multi-step reasoning."
  • Work takes priority. The budget exists to get work done. Personal use comes second (see below).
  • This is a learning period. We don't yet know how comfortably the limits accommodate a full week of work. We'll watch real consumption and revisit the guidance with transparency.

Personal use under limits

Quick answers

Can I use Claude Code for personal projects? Not on the work account, for now. The work usage pool is finite and shared, and there's no Copilot fallback anymore — so don't spend it on side projects. If you want Claude Code for personal work, run it on a separate profile signed in with your own personal Anthropic account, so it draws on your personal plan and limits, not the company pool. See Profiles and multiple accounts.

What if I already have a personal Claude Code configured on this machine? After sparkdock provisioning, the default claude command is the work profile: it forces login to the SparkFabrik organization, applies the managed policy, and uses ~/.claude. If you had been signing ~/.claude into a personal account, that slot is now work — re-authenticate it with your work account. Keep your personal setup on the claude-personal profile instead (config dir ~/.claude_personal, your own login). To carry over your existing personal history/config, copy it across before re-authenticating:

cp -r ~/.claude ~/.claude_personal   # only if ~/.claude held your personal setup
# then: `claude` = work, `claude-personal` = personal (run /login with your personal account)

Don't run personal projects under the work login — that bills the company pool and runs under org policy.

The policy

Because the work budget is finite and shared, using Claude Code on the work account for personal or side projects is, for now, discouraged — unless your weekly headroom clearly covers your actual work needs first.

This is the inverse of the Copilot situation, where capacity was effectively free and personal use was simply allowed within boundaries. Here, every personal-project session competes directly with your (and potentially your team's) work capacity.

Guidance for now:

  1. Work first. Don't let personal use erode the budget you need to deliver.
  2. Provisional, not permanent. This stance is conservative on purpose. Once we understand how much headroom the limits leave, we'll relax or adjust it together, with transparency.
  3. No fallback tool. GitHub Copilot has been phased out — seats are no longer issued by default and are granted only on demand, case by case, for a few specific needs (ask the platform team if you think you have one). So there's no second, unmetered AI coding tool to fall back on: Claude Code's limits are effectively your whole AI coding budget, which is exactly why personal use comes second.
  4. When in doubt, ask. If you have a personal-project use case in mind, raise it with your manager.

Org-managed settings

Claude Code now has organization-managed settings. We deliver them as server-managed settings: the policy lives in Anthropic's admin console and is pushed to your client automatically when you log in with your SparkFabrik account. You do not deploy or edit a managed-settings file yourself — the policy is fetched from Anthropic's servers on login and cached locally (path below).

Anthropic also supports a file-based mechanism (/etc/claude-code/managed-settings.json on Linux, /Library/Application Support/ClaudeCode/managed-settings.json on macOS) and MDM/registry delivery. We do not use these — our policy is server-managed. The file paths are mentioned here only so you recognize them if you read the official docs.

These settings take absolute precedence over your user (~/.claude/settings.json) and project (.claude/settings.json) settings, and cannot be overridden from a session. This is by design: it lets us enforce consistent, compliant defaults for everyone.

To check what's active, run /status inside a Claude Code session — the output includes a line beginning with Enterprise managed settings (remote) when the org policy is applied. Settings propagate on next startup, or within about an hour during an active session.

Where it lives locally: the fetched policy is cached at ~/.claude/remote-settings.json — that is the file Claude Code actually reads. It is the local copy of the admin-console policy, not something you edit (changes are overwritten on the next refresh). You will not find a /etc/claude-code/managed-settings.json; that file-based path is an Anthropic fallback we don't use.

What the organization can lock

Managed settings can constrain, among other things:

  • Permissions — which tools require confirmation, and whether only managed permission rules apply.
  • MCP servers — which servers are allowed or denied.
  • Models — which models are available, and forcing login to the SparkFabrik organization.
  • Plugins, skills, hooks, and agents — restricting customization to approved sources.

For the full reference, see the official Claude Code settings documentation.

Support boundary

We support only the harness as configured by sparkdock. Custom plugins, skills, agents, MCP servers, or settings beyond what sparkdock provisions are not supported unless pre-approved — discussed and shared with the team first. If you have something you'd like to add to the standard setup, propose it so we can evaluate and roll it out for everyone rather than maintaining one-off local configs.

Warning! OpenCode is no more an authorized harness. Although OpenCode has been experimentally used by some team members in recent months, it is not supported by Anthropic and falls outside the approved setup. Do not use it as your primary Claude Code interface under the SparkFabrik organization account.

OpenCode can technically connect to Anthropic's models via a personal API key. However, this mode operates entirely outside the organization's managed plan: it consumes additional budget at per-token API cost, does not count against — or benefit from — the organization's usage limits and pooled allowance, and is not covered by any org-managed policy or support.

OpenCode may be considered for users who, for contextual or workflow reasons, are granted a GitHub Copilot seat. In that scenario, OpenCode can be used as a Copilot-backed harness rather than an Anthropic-backed one, which sidesteps the API cost and policy concerns above.

Profiles and multiple accounts

If you also use Claude Code for personal work, keep it separate from your work account — separate login, separate usage pool, no org policy on personal work. There are two supported ways to do this, strongest first.

Separate OS user account (strongest isolation)

Log out and use a separate operating-system user account for personal work, with its own harness and configuration. This is the cleanest separation: nothing — credentials, config, history, MCP servers, managed policy — crosses between work and personal. Recommended when you want strict separation.

CLAUDE_CONFIG_DIR profiles (lighter, same OS account)

Claude Code's built-in CLAUDE_CONFIG_DIR environment variable points the CLI at a different config directory, which isolates settings, credentials, MCP servers, and history per directory. sparkdock provides a ready-made claude-personal alias for this — your default claude stays on the work/org account, and claude-personal runs against ~/.claude_personal:

# default — work/org account, org-managed policy applies
claude

# personal — separate config dir (~/.claude_personal), log in with your personal account
claude-personal

Org policy is keyed to the logged-in account, not the directory. When you log in to the personal profile with a personal (non-SparkFabrik) account, no org-managed policy applies and usage draws on that account's own limits — not the work pool. Conversely, the work profile always gets the org policy.

The third-party claude-code-profiles tool is just a wrapper around CLAUDE_CONFIG_DIR; the sparkdock claude-personal alias covers the same need, so you don't need it.

References

Last updated on 29 May 2026