Why does free server-side classification need to "verifiably identify" the request as legitimate — what's technically being checked?
Think of it as the server needing confirmation that the request genuinely originates from an official Claude Code client, with its identifying characteristics unaltered by any intermediary, before it can safely treat that classification as internal operating cost rather than billable user usage. Gateways and proxies, in order to do rate limiting, request logging, and similar functions, typically rewrite headers, pool connections, or otherwise change how a request's origin is identified — and those exact changes are what break the server's ability to verify the original source.
This isn't Anthropic deliberately charging gateway users more; it's that the free mechanism's technical precondition depends on a clean, unmodified request path.
Beyond falling back to the billed classifier, does "this session isn't eligible" affect any other Auto Mode behavior?
Currently published behavior notes only cover the billing-path switch — there's no mention of any difference in classification accuracy, speed, or the underlying decision logic. In other words, once it falls back to the billed classifier, the quality of Auto Mode's judgment about whether human confirmation is needed is theoretically unaffected; the only difference is that this check now counts against usage.
That said, if your gateway does more than header-level rewriting during forwarding — actually modifying request content — it's still worth observing Auto Mode's behavior for a while to confirm there are no other unexpected differences beyond billing.
If I'm not sure whether my setup counts as a "gateway," how do I quickly tell?
A practical test: does your Claude Code or API traffic hit Anthropic's official endpoint directly, or does it first pass through a relay service you (or a third party) set up before being forwarded on? If there's any additional server layer — controlled by you or a third party — doing request forwarding, logging, or rewriting, you should assume you're in a gateway scenario rather than assuming you're connecting directly.
Common enterprise setups like a unified internal API gateway, an internal compliance audit proxy, or certain third-party LLM routing services (used to switch between multiple model providers) all fall into this category, even if your team doesn't internally use the word "gateway" to describe it.
If /status shows Auto mode server as ineligible after upgrading, are there fixes besides restructuring the gateway?
Two realistic short-term options: first, evaluate whether your gateway actually needs to intercept this specific category of classification traffic — if not, consider carving out an exception so Auto Mode classification traffic bypasses the gateway and hits the official endpoint directly. Second, if the gateway exists for a hard compliance or security requirement that can't be bypassed, treat this classification cost as an inherent operating cost of your existing gateway architecture and budget for it normally, rather than assuming it will disappear on its own.
Which option is workable depends on why your gateway exists in the first place, and that's usually a decision to make jointly with whoever owns the gateway (security or platform engineering), not something an individual Claude Code user can decide alone.
Claude Code's Auto Mode runs a safety classifier in the background to judge whether the current conversation turn or tool call falls within allowed behavior. That classifier used to count against usage — every classification check consumed Token budget or API cost, even though most users never noticed it running at all. A recent release changes this to run server-side for free by default, which sounds like a straightforward cost reduction. But if your team accesses Claude Code through a gateway or proxy, that word "free" comes with an exception you need to actively verify.
The new default behavior: as long as your account uses one of these access paths — Claude API, Enterprise, Amazon Bedrock, Google Vertex AI, or Microsoft Foundry — Auto Mode's safety classification now runs directly on Anthropic's servers, doesn't count against your token usage, and doesn't show up on your bill. For teams that lean heavily on Auto Mode (letting Claude Code decide on its own whether a step needs human confirmation), this is a real cost reduction, because these background classification calls, at high automation frequency, were quietly adding up into a non-trivial line item that many teams never noticed sitting in their bill.
The catch is that server-side free execution depends on Anthropic's servers being able to directly and verifiably identify the request as a legitimate classification call. If your team runs its own gateway or proxy in front of the API — common in enterprise setups for unified request logging, rate limiting, or multi-tenant cost allocation — that intermediary layer changes the request's identifying characteristics, which breaks the server's ability to confirm eligibility for free classification. Claude Code doesn't fail outright in this case; instead it displays a notice reading "this session isn't eligible," and automatically falls back to the older, billed classifier to keep functioning. In other words, the feature keeps working, but the cost silently reverts from free to billed — and that switch happens automatically, with no additional confirmation prompt asking you to accept it.
This update also adds a new "Auto mode server" row to the /status command, directly indicating whether the current session qualifies for free server-side classification. If your team runs any form of gateway, an internal enterprise proxy, or forwards API traffic through any unofficial channel, the first thing you should do after upgrading is run /status and check this row — rather than assuming "the announcement said free, so it must be free." This matters especially if your architecture already layers multiple proxies (say, an internal security audit gateway that forwards on to Anthropic) — even if the final request itself is fine, the intermediary layer alone can be enough for the server to flag the session as ineligible.
If your team uses official Claude Code directly with no gateway of your own, this update is a pure cost reduction and requires no action. But if your organization has set up an API gateway for compliance, auditing, or multi-account cost-splitting reasons, you need to actually run /status and check the "Auto mode server" field — don't assume you're automatically getting free classification just because you upgraded. Many teams won't discover until next month's reconciliation that their Auto Mode classification costs never actually dropped, because they'd been sitting on the billed fallback path the entire time.