Anomaly detection for AI workloads is not exotic. It is the same discipline you already apply to cloud spend and API traffic, pointed at a new service. The goal is simple to state: know what "normal" looks like for your Claude usage — tokens, requests, models, callers — so that a deviation triggers a question within hours, not at invoice time. This article covers what to measure, where the data lives, and how to turn a baseline into alerts without drowning your team in noise.
What to baseline
Four dimensions cover most incidents worth catching:
- Volume — input and output tokens per hour and per day, per workload. Output tokens deserve their own line: they cost more, and an anomaly in output length (a prompt-injection attempt or a broken loop producing enormous responses) can hide inside a normal request count.
- Request patterns — requests per minute, error rates, and time-of-day shape. Most internal workloads follow business hours; sustained 3 a.m. traffic from an internal tool is a signal.
- Caller identity — which API key or workspace generated the traffic. A key that has been quiet for weeks suddenly producing volume is a classic sign of leakage or a forgotten scheduled job gone wrong.
- Model mix — which models are being called. A workload approved for a small, cheap model quietly switching to the most expensive one is both a cost problem and a governance problem.
Where the data comes from
On the first-party Claude API, Anthropic's Usage and Cost Admin API is the natural source. The usage endpoint (GET /v1/organizations/usage_report/messages) returns token consumption with breakdowns by model, workspace, and service tier, in time buckets of one minute, one hour, or one day. You can filter and group by API key, workspace, model, and service tier. Data typically appears within about five minutes of a request completing, and Anthropic's documented recommendation for sustained monitoring is to poll about once per minute. The companion cost endpoint reports spend in USD at daily granularity. Note that this Admin surface requires an Admin API key and is not available on Claude Platform on AWS.
On Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, usage telemetry flows through the cloud provider's own monitoring and billing tooling instead — the same systems your operations team already uses for other cloud services. The mechanics differ per platform, so lean on your provider's documentation; the dimensions to track are the same.
Structure first: workspaces make baselines meaningful
A single org-wide number is a weak baseline, because growth in one team masks anomalies in another. On the Claude API, workspaces exist for exactly this reason: they separate projects, environments, or teams while keeping billing and administration centralized, and API keys are scoped to a single workspace. If each significant use case has its own workspace, "usage per workspace per day" becomes a set of small, stable time series that are easy to reason about — and usage reports can be grouped along the same lines.
Backstops: limits that cap the blast radius
Detection takes time; limits act instantly. On the Claude API, organizations sit on a usage tier with a monthly spend cap, and you can set your own spend limit below that cap in the Console (Settings > Limits). Workspace-level limits can be set lower than — but never higher than — the organization's limits, which lets you give an experimental project a tight budget while production runs looser. Rate limits per model class (requests and tokens per minute) bound how fast anything can go wrong; a configured-limits API lets you read them programmatically and check that reality matches your records. On the cloud platforms, use the provider's native budgeting and quota mechanisms for the same effect.
From baseline to alert
Keep the alerting logic boring. Two layers catch most problems:
- Static thresholds for the unambiguous cases: any usage from a key that should be inactive, any usage of a model not on the approved list for that workspace, spend beyond an agreed daily ceiling.
- Relative deviation for everything else: alert when a workspace's daily tokens exceed some multiple of its trailing average. Start loose (say, alert on large multiples only), review the alerts weekly, and tighten gradually. A noisy anomaly channel gets muted, and a muted channel is worse than none.
Finally, make anomaly review a named responsibility, not a shared hope. The owner of each use case (see defining AI roles) should be the first responder for their workspace's anomalies, with a documented escalation path when the explanation isn't benign.
Where to go next
Pair this with cost anomaly alerting for the spend-focused view, misuse monitoring for content-level signals, and observability for the broader instrumentation picture.