Will my account get suspended? — what is actually observable, and how to monitor it yourself

[askalf]

This is the most common question about dario, and it deserves better than a shrug or a reassurance.

The short answer: I can't promise you won't be actioned, and I'd be skeptical of anyone who does. Only Anthropic decides how it enforces its terms. Anyone claiming certainty here — in either direction — is guessing.

What I can do is more useful than a guess: explain what the risk actually looks like in the signals you can observe, and show you how to watch those signals on your own account instead of taking my word for anything.

---

The distinction almost everyone misses

The question is usually framed as "will I get banned?" But the thing that's actually measurable — the thing that shows up in response headers you can read yourself — is billing classification, not account standing.

When Anthropic's classifier decides a request doesn't look like Claude Code, the request still succeeds. It gets routed to extra-usage billing, and you pay per-token instead of drawing on your subscription.

We documented this in #178, reproducing a finding first reported by Theo: the classifier fires on the specific namespaced string openclaw.inbound_meta.v1, and when it fires the request routes to extra-usage. Users with extra-usage credit see claim: extra_usage in the response header and silently pay per-token. The observable consequence there was a change in billing, not a change in account standing — though I have no visibility into those users' accounts beyond what was reported, so treat that as a bounded observation rather than a general finding.

Why this reframing is practically useful: the risk you can actually detect and act on is an unexpected bill. That's a real cost, worth taking seriously, and — unlike speculation about enforcement — it's something you can monitor in real time and respond to. So that's what the rest of this post is about.

I'm not telling you account risk is zero. I'm telling you it isn't the thing you can measure, and the thing you can measure is worth measuring.

---

Check your own billing bucket — do this first

One command, one request, prints the rate-limit headers Anthropic returns:

dario doctor --usage

Look at representative-claim:

value	meaning
five_hour	subscription billing ✅
seven_day	subscription billing ✅ (a different accounting window, not a downgrade)
extra_usage / overage	per-token billing — you are being charged per request

If you see five_hour or seven_day, your traffic is drawing on the subscription you already pay for. If you see extra_usage or overage, it isn't — and you'll want to know that today rather than at the end of a billing cycle.

For the full breakdown of these headers and how the 5-hour and 7-day windows interact, see #1.

The running proxy also exposes this continuously at /analytics, broken down per account:

billing bucket:  subscription 568 · extra_usage 0 · api 0
claim:           seven_day (568)

Check it periodically, not once. A reclassification is silent — no email, no warning banner. The header is the notification.

---

Automating that check — and what ours has caught

Rather than remember to run it, we automate it. cc-billing-classifier-canary.yml issues one real request on a schedule, reads the billing bucket back, and opens an issue when anything looks off. It's a small workflow and you're welcome to copy it.

It has run 103 times since 2026-05-17, across 93 days. Every run that successfully captured the signal read seven_day → bucket subscription.

I'd rather show you the failures than the headline, because the failures are what tell you whether the monitoring is worth anything. The canary has raised 8 warnings. All 8 are public issues here:

alert	captured representative-claim	bucket	what it meant
#1003 (8/18, open)	seven_day	subscription	billing fine; served-model field unparseable
#956 (8/12)	seven_day	subscription	same
#829 (7/21)	seven_day	subscription	same
#689 (7/08)	seven_day	subscription	same
#799 (7/18)	<missing>	unknown	probe captured no signals at all
#786 (7/17)	<missing>	unknown	same
#738 (7/13)	<missing>	unknown	same
#733 (7/12)	<missing>	unknown	same

Two failure modes, and the difference matters because you'll hit them too:

• Four read seven_day → subscription. Billing was healthy; the warning was a secondary probe signal (which model got served) coming back unparseable. Noise, not signal.
• Four read <missing> → unknown. Every signal absent — representative-claim, fallback-percentage, 5h-utilization. That's the probe failing to capture, not Anthropic making a decision. A real reclassification reads claim: extra_usage, not <missing>. All four self-resolved on a later run the same day.

The useful lesson for anyone building their own version: distinguish "the probe failed" from "the answer changed." A monitor that conflates those will cry wolf until you stop reading it — at which point it's worse than no monitor.

---

Why fidelity is the whole mechanism

dario rebuilds each request into the shape Claude Code actually emits, captured live from your own installed binary rather than guessed at. Same client shape, same classification. That isn't a trick — it's the design premise, and it's why the billing bucket reads the way it does.

What our testing narrowed down about what classification keys on:

• #13 — Claude Code's "defaults" aren't defaults; they're signals. We identified 8.
• #183 — CC's 27kB system prompt is not an input. Across 7 controlled mutations, including replacing it entirely with a 321-character prompt, every variant still routed to five_hour. Content, length, and block count don't matter.
• #178 — but specific namespaced identifiers do. The trigger is narrow and string-specific.

The upshot: classification appears to key on structural request properties, not on your content. dario sends your own subscription's requests in the form the official client sends them.

---

Limitations — please actually read this

1. n = 1. One account, one operator, one usage pattern. A case study, not a population study. I can't tell you what happens across thousands of accounts and won't pretend otherwise.
2. Three months is not forever, and policy has moved on short notice before. On 2026-05-13 Anthropic announced that from 2026-06-15 Agent-SDK and claude -p traffic would leave the subscription pool for a separate monthly credit, then metered rates. They paused it before it took effect — nothing changed, no credits were issued — but it was announced once on short notice and could return. This is exactly why the answer is "monitor it," not "it's fine."
3. My usage may not resemble yours. Moderate steady volume from a single subscription. I have no data on much higher volume, on many pooled accounts, or on commercial/multi-tenant use, and I'd expect the risk profile to differ there.
4. Nothing observable here speaks to account standing. Billing classification is what's measurable. Account enforcement is a separate question that response headers simply do not answer, and I'm not going to infer one from the other.
5. Absence of a signal is not permission. Nothing here says any of this complies with your agreement with Anthropic. Read their terms and DISCLAIMER.md, and decide deliberately.
6. I have an obvious bias. I wrote the tool. I've shown the warnings alongside the clean readings precisely because of that, and every claim here is checkable from this repo's public issues and workflow history — but weigh the source.

---

Reducing your own risk

• Monitor your billing bucket; don't assume it. dario doctor --usage, or automate it — copy the canary workflow.
• Keep Claude Code installed. dario captures the template from your own binary; without it you fall back to a bundled snapshot that ages out of date.
• Don't treat this as a commercial API. The terms question gets harder the further you get from personal development use.
• Keep a fallback. dario routes OpenAI-compatible backends too, so a policy change is a config change rather than an outage.

---

If you're running dario and see something different — especially a bucket that isn't five_hour or seven_day — please post it here. One maintainer's account is a weak dataset, and this page gets more useful with more readings in it, not fewer.