Why my Claude accounts kept getting banned:the timeline, the device ID, and what I do now

The short version

I've had several Claude accounts suspended — all told, around $400 in prepaid balance gone. For a long time I was sure the problem was a "dirty" network exit.

This time I put my ban records back on a single timeline and went through the widely-repeated theories one by one, searching inside the Claude Code client on my own machine. The conclusion came out different from what I'd assumed:

• The top suspects are a browser extension that injects web login credentials, and multiple accounts sitting under one device ID.
• The exit IP ranks last. My paid main account ran on the same datacenter IP for three months without a problem.
• The Claude Code client itself carries a fixed device ID. Common account-switcher tools only swap the login info — they don't swap that.

Here's the evidence, and what I do now.

The ban timeline

The first time, two free accounts were suspended on the same day:

• Registered the first free account in early June, used it for 8 days.
• On June 9 I installed a browser extension for quickly switching accounts. The way it works is to write the web login credentials straight into the browser.
• On June 11 I logged into a second account; that day my network exit wasn't in its usual region.
• June 12, 20:37 — both accounts suspended at once.

The second time, a freshly-registered paid account. In August I spun up a new profile in a multi-profile ("anti-detect") browser, registered with a low-reputation email domain, and bought Pro right after signup. In hindsight, that profile probably had no proxy configured, so the new account first showed up from a domestic network.

There was also one false alarm in between. In July, a paid account showed "can't read quota," and I assumed it was banned too and deleted it from my switcher tool. A re-check at month end showed it had been fine all along — the login token had just expired.

Ranked by suspicion — IP comes last

I put every trace I could find on one timeline: browser cookies, client config, human-verification records, and exit-IP logs. From most to least suspicious:

1. The extension that injects web login credentials. Banned three days after installing it. Official login goes through OAuth; this kind of extension writes the web session straight into the browser — a different mechanism entirely.
2. Multiple accounts under one device ID. Both the Claude desktop client and the browser keep a device ID. Mine didn't change for seventy or eighty days, and I logged into several accounts during that window.
3. Accounts not registered in my own name.
4. Frequent account switching inside the client.
5. Datacenter IP. My paid main account used the same datacenter IP for three months with no issue.

One signal I ignored at the time: starting in early June, CAPTCHA challenges popped up 11 times.

This ranking is from my own records. It's an inference, not a rule Anthropic published.

What I confirmed inside the client

The target was Claude Code 2.1.282 on macOS. Method: searching for the relevant code and strings inside the client program. I did not capture traffic to confirm the full upstream payload.

The device ID is reported alongside the account

Claude Code stores a device ID in .claude.json in your home directory: generated randomly on first run, then kept constant. When usage data is reported, that ID shows up in the same record as the current account's ID.

Switcher tools don't replace the device ID

The switcher I used only swaps the account's login info; the device ID is left untouched. The tool's author even labels this ID "machine identity" in a code comment.

So several accounts rotated on the same computer look, from the server's side, like several accounts on one device.

Checking a few of the common theories

• "The client reads your system proxy settings." I couldn't find the macOS system-proxy APIs being called anywhere in the client.
• "The client detects your timezone." The client does read the timezone; the two places I found both use it to display time. Separately, I did a byte-by-byte diff of 2.1.90 vs 2.1.91 back in June: from 2.1.91 on there's a tagging path that uses the timezone, but only when the request endpoint is pointed at a third-party relay. A direct official connection doesn't trigger it.
• "Deleting the .claude folder cleans everything up." The .claude.json that holds the device ID sits at the root of your home directory, not inside the .claude folder. Delete the folder and the ID is still there.

One false alarm: "can't read quota" ≠ banned

When it says "can't read quota," the more common cause is an expired login token. Refresh your login state before you rush to delete the account.

There's another easy-to-misread case: the same account handed to two tools at once. When the token refreshes, one tool gets the new token and the other's stored token instantly goes stale — it looks like the account suddenly died. One account, one managing tool, and you avoid it.

What I do now

1. One profile, one account. On the computer with my main account, I don't rotate others.
2. Official login only. No extensions that inject login credentials.
3. Fixed network exit, not shared with anyone. Claude's connection goes down its own path, and when it drops it stays dropped rather than auto-failing over to another network.
4. DNS resolver location matches exit location. I once had an exit IP in the US while 11 of 32 resolvers were in China.
5. Timezone matches exit location. This one matters more for the web client.
6. When quota won't read, check the login token first; one account, one managing tool.
7. For automated jobs, cap retries and concurrency so a failure doesn't retry forever.

What this article doesn't prove

• I didn't capture traffic to confirm the full reported payload — I only confirmed the fields and how they're organized in the client code.
• The ranking of ban factors comes from one person's timeline. It's an inference, not an official conclusion.
• Anthropic doesn't publish its risk-control rules. These practices lower the risk; they can't guarantee an account won't be banned.

If you only have one account, the simplest thing is just to use that one, normally.