Claude Code Is Tagging Requests: What It Means for Builders

A researcher recently found that Claude Code silently embeds invisible markers in its prompts before sending them to Anthropic's API. No announcement, no documentation -- just hidden bytes riding along with every request.

If you are building production AI agents on top of any LLM provider's tooling, this is worth understanding. Not because it is catastrophic, but because it reveals something important about the layer of infrastructure you are actually running on.

What Is Actually Happening

The technique is prompt steganography: encoding information into text in a way that is invisible to a human reader but detectable by a machine. In Claude Code's case, the markers appear to identify that a request originated from the Claude Code client specifically.

The mechanism is not malicious. The most charitable read is telemetry: Anthropic wants to distinguish Claude Code traffic from raw API calls to measure usage, debug issues, or apply client-specific behavior. The concerning part is not the what -- it is the lack of disclosure. Users of Claude Code had no documented way to know their prompts were being modified in transit.

Why This Matters If You Ship Agents

Most AI agent builders do not write raw HTTP to the Anthropic API. They use SDKs, frameworks like LangChain or LlamaIndex, or higher-level clients. Each of those layers can and does modify prompts before they reach the model.

That is mostly fine. But if you are:

• Running evals against prompt content and expecting exact strings
• Auditing prompt logs for compliance or debugging
• Building a multi-provider router that normalizes prompts across Claude, OpenAI, and others
• Doing any kind of prompt integrity checking

...then invisible modifications from your tooling layer are a real problem. Your logs will not match what the model actually received.

The Broader Pattern: Your Stack Has Opinions

This is one instance of a wider truth that bites agent builders at production: every abstraction layer between your code and the model has behavior you did not write and may not have read.

Some examples that come up regularly:

• System prompt injection: Several SDK wrappers prepend their own system prompt fragments without surfacing this in docs.
• Token trimming: Some clients silently truncate messages that approach context limits rather than throwing an error.
• Retry mutation: Auto-retry logic occasionally reorders or de-duplicates tool calls in ways that change agent behavior on the second attempt.

None of these are unique to Anthropic. They appear across the ecosystem. The right response is not paranoia -- it is instrumentation. Log what actually leaves your system, not what you think you sent.

What Good Observability Looks Like Here

For production agents, treat your LLM calls the way you would treat outbound HTTP to a third-party API: log the full request payload at the point it leaves your control, before any SDK transformation. This gives you a ground truth to diff against when behavior gets weird.

A few practical steps:

1. Intercept at the transport layer if you need to catch SDK-level modifications. In Python, this usually means a custom httpx client passed into the Anthropic SDK.
2. Snapshot prompt hashes in your eval pipeline so you notice when the same nominal prompt starts producing different token counts.
3. Pin SDK versions in production and review changelogs before upgrading. Prompt-touching behavior changes quietly.

If you are trying to figure out which parts of your workflow are worth instrumenting first, our free AI Opportunity Audit can surface the highest-impact spots from just your existing process -- useful if you are still mapping where agents fit before going deep on observability.

The Trust Model for Closed Tooling

Claude Code is a closed-source client. The steganography discovery happened through traffic inspection, not source review. That is the normal state of affairs with most commercial AI tooling: you are trusting that the abstraction does what it says.

That trust is usually fine. But it should be explicit, not accidental. Teams building on these tools should have a clear answer to: what would we need to verify if behavior changed unexpectedly? If the answer is "we would not know where to start," that is the gap worth closing before you hit production.

The marker behavior in Claude Code will probably get documented or removed now that it is public. The underlying point stands: your model is one layer of a stack, and the other layers have opinions.

Build on a Foundation You Can Inspect

None of this argues against using managed SDKs or tools like Claude Code. It argues for knowing what they do. The builders who ship reliable agents are not the ones who avoid abstractions -- they are the ones who know exactly where to look when something breaks.

If this is the kind of infrastructure thinking you want applied to an actual agent build for your business, book a call and we can talk through what that looks like in practice.