Anthropic does not ship native account switching for Claude Code. If you have multiple Claude.ai accounts and you want to use them all, you have two options: write a script that swaps ~/.claude/.credentials.json between accounts, or install something that does it for you.
The script approach is what most multi-account devs land on first. It is appealing — cp two files, restart claude, you are on the next account. Five lines of bash. Why pay for a tool?
This post is the honest answer. Manual scripts can rotate accounts. They cannot do the work the proxy does. Below is a direct, factual comparison of what each approach actually delivers, where the gap is, and where manual is genuinely good enough.
What a manual rotation script actually does
The minimum-viable manual switcher is something like:
#!/usr/bin/env bash
# claude-switch.sh
set -euo pipefail
PROFILE=${1:?}
cp "$HOME/.claude-profiles/$PROFILE.credentials.json" "$HOME/.claude/.credentials.json"
pkill -f "claude " || true
echo "Switched to $PROFILE. Restart your claude session."This works. It rotates accounts. The cost is that every visible Claude Code session has to restart: the agent loses its conversation thread, the open tool-call state, the spawned sub-agents, the working file set. You re-prompt from the beginning of the new session.
A slightly more advanced version writes a wrapper around claude that pre-checks utilization, picks the next account before launch, and persists the choice. That gets you "rotate on launch" but still cannot rotate mid-session, because Claude Code reads ~/.claude/.credentials.json once at startup and holds the OAuth token in memory until the process exits.
The architectural ceiling for any manual switcher is "rotate between sessions." Mid-session rotation requires intercepting the HTTP calls themselves.
What the Power Claude proxy does that scripts cannot
The proxy sits between Claude Code and api.anthropic.com on port 3456 (default; configurable). Claude Code points at the proxy with CLAUDE_API_URL=http://127.0.0.1:3456. The proxy supplies the upstream Authorization header per-request from whichever account in your pool is currently active. Account rotation happens at the HTTP-request boundary, not at the process boundary.
This unlocks five categories of behavior no manual script can replicate.
1. Mid-session rotation with no thread loss
When the active account's anthropic-ratelimit-unified-5h-utilization header crosses 0.98 (configurable), the proxy switches the credential for the next request. The Claude Code client never sees the swap. Same conversation, same tool-call state, same sub-agents — only the upstream account changes.
The manual script equivalent would have to: kill Claude Code, swap credentials, restart Claude Code, manually re-attach to the session JSONL, hope it resumes cleanly. That is not equivalent. It is a different workflow.
2. Pre-emptive rotation (the 429 you never see)
Rate-limit 429 responses consume quota from the account that just rejected you. Engineers have observed double-digit percentage burns from individual failed requests. The longer you stay on an account that is about to throttle, the more quota you waste on errors that produce no output.
The proxy rotates at 0.98 utilization, before Anthropic returns the 429. The error never fires; the quota is preserved. From the README:
Smart 429 routing is the second half of the multiplier. When an account returns 429 (whether it's a per-minute throttle or a hard quota signal), the proxy used to sleep
Retry-Afterseconds and retry the same account. Now it tries a healthy alternate first — flipping to another account in your pool instead of waiting up to 120 seconds.
A manual script that runs on a cron tick to check utilization and rotate accounts cannot do this. Even at a 10-second tick, the proxy is reading utilization on every single response — orders of magnitude finer resolution. By the time a cron job has noticed the account is at 96%, the proxy has already rotated.
3. Balanced Mode — pool-wide load balancing
Manual switching is serial. You drain account A to exhaustion, switch to account B, drain it, switch to account C. Each account hits its 5-hour cap independently and you pay the rotation cost N times.
Balanced Mode (Pro) is parallel. Every inbound request is scored across all healthy accounts on every call — by 5-hour utilization, in-flight count, and recent burn rate — and routed to the account with the most headroom. With three healthy accounts in the pool, the per-minute ceiling is roughly 3× single-account; with five, it is roughly 5×. From the README:
Each Claude.ai account has independent 5-hour, 7-day, per-minute token (TPM), and per-minute request (RPM) rate-limit windows. With three accounts in Power Mode you get an effective ~3× ceiling on every one of them — heavy Opus sessions that used to stall every 30 minutes run uninterrupted, and the per-minute throttling that sometimes choked single-account streaming during heavy sub-agent fan-out simply doesn't happen.
The throughput visualizer on the home page models this with T(N, M) ≈ T0 × max(1, N/M). At 10 concurrent sessions across a 5-account pool, the typical speedup is 5× per round. A serial manual switcher gets none of this.
4. Telemetry and the Runout Forecaster
The proxy parses Anthropic's rate-limit response headers (anthropic-ratelimit-unified-5h-utilization, -5h-reset, -7d-utilization, -7d-reset) on every API call and persists them to ~/.power-claude/state/rate-limits.json. The Runout Forecaster reads this state, fits a linear regression over the last 30 minutes of utilization samples, and projects whether the pool will exhaust before the next window reset.
A single color-coded banner sits at the top of the Overview tab:
- Green — pool safe through next reset
- Amber — some accounts at risk
- Red — pool exhausts before earliest reset
Per-account ETA chips (✓ safe, ETA 1h 47m, ETA 14m) make the bottleneck account visible without opening drawers.
A manual script can curl Anthropic and parse headers. It cannot do the regression fit, the cold-start handling, the per-window-tighter-of-the-two math, or the UI surfacing. You can build all of this — it is several hundred lines of code and a few weeks of debugging — or you can install the extension.
5. The session-resilience watchdog
Rate-limit rotation is one failure mode. The watchdog handles four:
| Trigger | Signal | What it means | |---|---|---| | heartbeat-stale | No lifecycle heartbeat in N seconds AND JSONL idle | Process kill, OOM, IDE crash, network drop | | tool-truncation | Last assistant record is stop_reason: tool_use with no follow-up | Died mid-tool-call | | ended-with-pending | Stopped cleanly but task items still pending | Session said "done" but work remains | | rate-limit | pending-recovery.json written by Stop hook | Standard rate-limit rotation |
None of these are recoverable from a credential-swapping script. They require knowing what the session JSONL looks like, what the stop_reason field means, what a TodoWrite snapshot encodes, and what the right resume prompt is for each failure shape. The Power Claude changelog catalogs the detection rules and the reason-aware resume prompts for each. That is multiple person-weeks of design and testing, not a weekend hack.
A direct feature comparison
| Capability | Manual script | Power Claude | |---|---|---| | Switch accounts | cp credentials.json, restart Claude Code | Automatic at HTTP-request boundary, no restart | | Rotation trigger | You notice the stall, run the script | Pre-emptive at 0.98 utilization (configurable) | | Session continuity through rotation | Lost — full session restart | Preserved — same thread, same tool state | | 429 quota waste | Every rate-limit error burns quota | Avoided — rotation happens before 429 | | Multi-account parallelism | Serial only | Balanced Mode load-balances across pool | | Per-account telemetry | None (you'd build it) | Persisted in rate-limits.json, surfaced live | | Runout forecasting | None | Regression-fit ETA per account + pool-wide | | Process-death recovery | None | Watchdog heartbeat-stale rule | | Tool-truncation recovery | None | Watchdog tool-truncation rule | | Lazy-stop detection | None | Auto-Nudge family (4 default detectors, 4 opt-in) | | OAuth token refresh | Manual re-login per account | Auto-refresh 5 min before expiry, coalesced | | Setup friction | DIY for each new machine | VS Code marketplace 1-click | | Audit log of rotations | None (you'd build it) | rotation-audit.log + events.jsonl | | VS Code integration | None | Sidebar, status bar, dashboard, tree view | | License / paid features | N/A — free | 7-day free trial or Pro |
Where manual is genuinely good enough
There are cases where a script is the right answer.
- You have exactly one account. Power Claude is built for multi-account workflows. With a single account there is nothing to rotate; the proxy still gives you telemetry, but rotation is moot.
- You only run Claude Code in one short interactive session at a time. If you never hit a rate limit because you never run long enough, the friction of multi-account management does not apply to you.
- You explicitly want zero third-party software in your dev loop. This is a legitimate stance. The trade-off is everything in the comparison table above; the cost is engineering time you spend reinventing pieces of it.
- You are on a system Power Claude does not run on. Power Claude requires Node.js and VS Code (or
pcCLI). If your dev environment is incompatible, a bash script may be your only option.
For every other case — multiple accounts, long agentic sessions, anything that runs unattended — the manual approach hits an architectural ceiling that scripts cannot cross.
The hidden cost of "free, but I'll just script it"
Engineers who build their own switching scripts almost always underestimate the maintenance cost. The Power Claude changelog has thirty-plus releases of rate-limit-handling refinement — false-positive guards on the heartbeat-stale rule (the 0.13.1 hotfix), the overageStatus=rejected regression in 1.0.0 (where rotation died with "no eligible account" when 6/12 accounts were actually healthy), the multi-window settings-mutation lock so concurrent VS Code windows do not clobber each others' hook installs, the systemd-cgroup decoupling so an editor crash does not kill the proxy.
Each of those was a real bug that took real time to find. A hand-rolled script will hit the same bugs — quietly, in production, without telemetry to tell you what went wrong.
There is also the OAuth refresh problem. Anthropic's OAuth access tokens expire. Refresh requires the refresh token, a coalesced retry path so multiple in-flight requests do not all trigger independent refreshes, and atomic writes back to the profile JSON. Power Claude's 0.15.0 release notes:
OAuth token auto-refresh. Access tokens are refreshed 5 minutes before expiry, with concurrent refresh coalescing so parallel requests don't trigger multiple refreshes.
A script that just swaps credentials.json does not refresh tokens. The first time one of your accounts' tokens expires, the script silently swaps in an expired credential and rotation fails.
When the math works in your favor
The five-account pool framing on the pricing page makes the economics explicit: five Pro accounts cost roughly half what a single Claude Max-20× subscription does, and give you five fully independent rate-limit windows instead of one larger one. The ceiling is structurally higher; the cost is structurally lower.
But you only realize the savings if you actually use all five accounts. Manual switching means you log in once, rotate when you remember to, and end up using maybe two of the five in any given week. The friction quietly destroys the math. Pre-emptive rotation + Balanced Mode means every account in the pool is doing work continuously, automatically. The five-account budget gets fully utilized without you thinking about it.
What to do next
If you are running a manual switcher today and want to see the gap on your own workload, the 7-day free trial of Power Claude includes pre-emptive rotation across your pooled accounts. Install via the VS Code marketplace. Existing manual-script users have a migration guide in the docs covering the credential layout and how to bring an existing pool of accounts in.
If you decide your single-account script is the right answer for your workflow, that is a defensible choice. Just know what you are trading: the proxy's mid-session rotation, the watchdog's failure-mode coverage, and the telemetry that tells you when your accounts are about to fall over. Those are the load-bearing features, and they do not exist in a bash one-liner.
Quick Reference
Q: Can I just swap ~/.claude/.credentials.json between Claude accounts? A: Yes, but only between sessions. Claude Code reads the credential file once at startup and holds the OAuth token in memory. To rotate mid-session you need an HTTP proxy that intercepts the request and supplies the credential per-call, which is what Power Claude's proxy does.
Q: What does a manual script lose compared to Power Claude? A: Mid-session rotation, pre-emptive rotation before 429s fire, Balanced Mode load-balancing across the pool, the Runout Forecaster, the watchdog's four failure-mode detectors, OAuth token auto-refresh with coalescing, and live telemetry. Plus the ongoing maintenance burden — Power Claude has 30+ releases of rate-limit-handling bug fixes.
Q: Why can't a cron-tick script do pre-emptive rotation? A: The proxy reads anthropic-ratelimit-unified-5h-utilization on every API response. A cron job tick is orders of magnitude coarser — by the time it notices an account is at 96%, the proxy has already rotated. Pre-emption requires per-request resolution, which requires sitting on the request path.
Q: Will my manual script work alongside Power Claude? A: Generally yes, but you should disable the script's auto-rotation while the proxy is active to avoid both processes fighting over ~/.claude/.credentials.json. Power Claude writes that file on every rotation; a competing writer will corrupt the state.
Q: Does Power Claude work without VS Code? A: A standalone CLI for running Power Claude without VS Code is coming soon. For now, Power Claude runs as the VS Code (or Cursor) extension. The VS Code extension adds the dashboard and sidebar, but the proxy and CLI work headlessly.
Q: How does Balanced Mode compare to manual round-robin scripting? A: A manual round-robin script picks the next account in sequence, regardless of utilization. Balanced Mode scores all healthy accounts on every request — by 5-hour utilization, in-flight count, and burn rate — and routes to the lowest-loaded. The difference shows up under heavy concurrent load, where round-robin can route to a near-throttled account while a fresh one sits idle.
Q: What's the cost of building my own equivalent to the watchdog? A: The watchdog's four detection rules each require knowing the Claude Code JSONL schema, the stop_reason semantics, the TodoWrite snapshot shape, and the right resume prompt per failure mode. Plus systemd integration so the watchdog survives editor crashes. Plus the false-positive guards (the 0.13.1 healthy-idle fix is one example). Realistically several person-weeks for a careful implementation, with ongoing maintenance as Claude Code's internals evolve.
Q: Can I use Power Claude with just one account? A: Yes, but most of the value is multi-account. With one account you still get telemetry, the watchdog, and Auto-Nudge, but rotation is moot. The product is built for the pooled-account workflow.
Q: Does the proxy add latency to Claude Code requests? A: Sub-millisecond decision overhead per request, dominated by upstream API latency. SSE streaming is piped unbuffered byte-for-byte, so no perceptible latency for streaming responses.
Q: What's the all-in price comparison? A: Five Pro accounts at Anthropic's per-seat pricing plus Power Claude Pro comes in well under a single Claude Max-20× subscription, and gives you five independent rate-limit windows instead of one larger one. Exact comparison on the pricing page.