Claude Code Auto Mode Classifier Billing: Why 'This Session Isn't Eligible'

The auto mode classifier billing notice means Anthropic's free, server-side safety checks aren't reaching your session, so the CLI is running its own classifier requests and billing them as token usage, exactly as before. Nothing is broken. The usual cause is an LLM gateway or proxy that drops the safety fields; the fix is to make it pass them through, then start a new session.

This is the notice, in its two forms:

We're changing auto mode to no longer charge for classifier requests in Claude Code.
However, this session isn't eligible because your requests go through a LiteLLM gateway,
which isn't compatible with this update.
Nothing breaks: auto mode keeps working, and its classifier requests are billed as before.
To fix it and access the new version of auto mode, ask your gateway to implement:
https://code.claude.com/docs/en/auto-mode-classifier-billing

We're changing auto mode to no longer charge for classifier requests in Claude Code.
However, this session isn't eligible.
Nothing breaks: auto mode keeps working, and its classifier requests are billed as before.
If this keeps happening, contact support or your company's admin:
https://code.claude.com/docs/en/auto-mode-classifier-billing

The first appears when the CLI can tell which gateway sits in the way, and names it. The second appears when it can't.

What I checked

I downloaded Claude Code 2.1.296, the latest release on npm when I wrote this, and read the notice straight out of the program: both wordings above, the conditions that show it, and the gateway names it can print. Then I checked each point against Anthropic's billing page, its permission modes reference and gateway compatibility guide, and LiteLLM's notes on fixing their gateway. I didn't trigger the notice on a live account, so nothing below depends on a bill I've seen.

Does Claude Code auto mode use more tokens?

Only when the safety check falls back. If Anthropic's server reviews actions inside your normal model requests, Claude Code auto mode adds no separate classifier charge. If Claude Code makes its own classifier requests instead, each check costs extra tokens on Enterprise, Claude API and cloud-provider accounts.

In auto mode, a second model, the classifier, reviews shell commands and network actions before they run, instead of asking you. Reads and edits inside your working directory skip it.

Who pays for those reviews, and what Claude Code auto mode costs you, depends on where the check runs:

Anthropic's docs describe the fallback's cost plainly: each check "sends a portion of the transcript plus the pending action," and "the overhead comes mainly from shell commands and network operations." So a session that runs a lot of shell commands in auto mode is the one where the fallback costs you most.

The server-side checks are the new part. The CLI started asking the server for them by default in versions 2.1.271 to 2.1.281, depending on how you connect, and LiteLLM dates Anthropic's rollout to September 18, 2026. The notice exists to tell you when that free path isn't working for you.

Why does Claude Code say this session isn't eligible?

Claude Code shows "this session isn't eligible" when Anthropic's free server-side checks can't reach it. Usually an LLM gateway drops the safeguards request field or the safeguard_results reply. Less often, your platform or region simply hasn't been rolled out yet.

There are two causes, and the notice's wording tells you which one you're more likely to have.

1. A gateway or proxy is dropping the safety fields. This is the common cause. Server-side review works by sending an extra field with each request, safeguards, and reading the verdicts back from a safeguard_results field in the reply. A gateway that only forwards the fields it already knows about, rewrites requests, or edits responses breaks that round trip. The server never sees the request for checks, or the CLI never sees the answer, so it falls back.

When Claude Code can identify the gateway, it names it. If your ANTHROPIC_BASE_URL points anywhere other than an anthropic.com address, the 2.1.296 build prints that host, for example your requests go through llm.internal.example.com. It also has wording for eight gateway products it can recognise:

• a LiteLLM gateway
• a Helicone gateway
• a Portkey gateway
• Cloudflare AI Gateway
• a Kong gateway
• a Braintrust proxy
• a Bifrost gateway
• a Databricks gateway

2. Your platform, region or credential doesn't have server-side checks yet. Anthropic says availability "depends on that platform's rollout." If you see the short version of the notice, with no gateway named and no gateway in your setup, this is the likely cause. There's nothing to fix on your side. Report it with /feedback or ask your admin.

How do I check if my session gets free server-side checks?

In a session that's in auto mode, run:

/status

Look for the Auto mode server row. Enabled means the server's checks are deciding your actions, at no classifier charge. Disabled means the session has fallen back to Claude Code's own classifier requests.

It's the quickest way to confirm a gateway fix worked: start a new session after the change and check the row says Enabled.

How do I fix "this session isn't eligible"?

Make the gateway pass traffic through unchanged, then start a new session. The fix lives in the gateway, not in Claude Code. Anthropic's gateway compatibility guide asks gateways to treat headers and body fields "as open lists, not closed ones":

• Forward request headers and body fields as they are, including ones the gateway doesn't recognise, such as safeguards, and the anthropic-beta header verbatim. Don't allowlist the values you've seen so far. New Claude Code releases add new ones.
• Return responses and streaming events without dropping keys, such as safeguard_results, and without rewriting tool-use IDs.
• Don't cut streams short. If the review results arrive late or mangled, you get a different, more disruptive error. More on that below.

If you run LiteLLM, this is a known, fixed bug: its /v1/messages route silently dropped the safeguards field, while the /anthropic/v1/messages pass-through route was unaffected. According to LiteLLM's notes:

• Fixed versions: v1.104.0, with backports in v1.99.3, v1.100.2, v1.101.1, v1.102.1 and v1.103.2. No configuration needed.
• Bedrock behind LiteLLM: point Claude Code at a bedrock/<inference profile> deployment, not the Converse route.
• Beta header involved: dangerous-tool-use-2026-09-03.

For other gateways, send your admin or vendor the compatibility guide. That's the link the notice itself points to.

Once the gateway passes traffic through, new sessions use the server's checks again. A running session that has already fallen back stays on the fallback.

What Enter, Esc and the 24-hour reminder do

At an interactive prompt, the notice holds the first action it would have checked until you answer:

• Enter continues. That action and the rest of the session use the CLI's own classifier requests, billed as before, and the notice won't appear again in that session. If the notice named a gateway, acknowledging it also keeps it away on this machine for 24 hours. If it didn't name one, it comes back the next time a session falls back.
• Esc or Ctrl+C cancels. The held action doesn't run and the turn stops, still in auto mode. Nothing is remembered, so you'll see the notice again before the next checked action.

The 24-hour window isn't only in the docs. The 2.1.296 build stores when you acknowledged it and shows the notice again once a full day has passed.

In non-interactive runs (claude -p), the notice goes to stderr and the run continues. In stream-json output it arrives as a system warning message, which an Agent SDK app can read from the stream. If you parse CI logs for unexpected stderr, expect this line.

CLAUDE_CODE_AUTO_MODE_SERVER=0 hides the notice. It doesn't cut the bill

Setting CLAUDE_CODE_AUTO_MODE_SERVER=0 stops Claude Code requesting server-side checks. That hides the notice but doesn't change what you're billed:

export CLAUDE_CODE_AUTO_MODE_SERVER=0

That tells the CLI not to ask the server for checks at all. Every classifier request is then its own, billed the same way, and the notice has nothing to warn about. LiteLLM's notes say it bluntly: the variable only hides the notice, and you keep paying for classifier requests until the gateway is fixed.

Use it when you already know your gateway can't carry the checks and you want quiet logs. Three things to know before you rely on it:

• On a direct connection to the Anthropic API, it needs version 2.1.281 or later.
• Anthropic calls it "a temporary setting" that "may be removed in a later release."
• CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1, which many gateway setups already use to avoid 400 errors, also turns the server's checks off while CLAUDE_CODE_AUTO_MODE_SERVER is unset. If you set that variable months ago, it may be why you're not eligible.

How do I turn off the auto mode classifier?

Leave auto mode. The classifier only runs in auto mode, so pressing Shift+Tab to switch permission modes, and approving actions yourself, is the only way to stop it reviewing your commands. CLAUDE_CODE_AUTO_MODE_SERVER=0 doesn't turn the classifier off; it only moves the checks from Anthropic's server to billed classifier requests.

If what you actually want is to stop paying for classifier checks, the options are making the gateway pass traffic through, connecting directly, or leaving auto mode.

Not the same as "gave no verdict"

A gateway can break server-side review in two ways, and they look very different:

• The review request or results go missing entirely → the CLI quietly falls back and shows this billing notice. Your actions still run.
• The results arrive truncated or in a form Claude Code can't read → it refuses to run the action unreviewed, and you get "The server-side auto mode classifier gave no verdict", and the turn stops after ten consecutive no-verdict denials.

If you're seeing denials rather than a notice, read Claude Code auto mode "gave no verdict" instead. Both trace back to the same rule: the gateway has to pass traffic through unchanged.

Quick reference

If your gateway is also a TLS-inspecting company proxy, the same "something in the middle changed the traffic" problem causes Claude Code's SSL certificate errors. To see where the rest of your tokens go, read why Claude Code uses so many tokens, and for every other message, the Claude Code troubleshooting index. On Google Cloud, the gateway is often not the problem at all: see Claude Code on Google Cloud returning model not found. I help teams roll out Claude Code behind enterprise gateways and proxies. See recent projects.