Cutting Claude Opus Token Cost for Security Agents at Scale

A security agent that triages one alert beautifully is a demo. A security agent that triages forty thousand alerts a day without bankrupting you is a product. The gap between those two is almost entirely about token economics and latency. Claude Opus is the most capable model in the Claude 4.x family, and capability is exactly what you want pointed at a suspicious login or a malformed packet — but if every alert replays a 30,000-token system prompt and a full playbook through the most expensive model, your bill and your queue both explode. This post is about keeping Opus-powered security agents both sharp and affordable at real volume.

Where the tokens actually go

Before optimizing, measure. In a typical security triage agent the token spend breaks into four buckets: the static preamble (system prompt, tool definitions, playbooks, and detection logic), the per-alert input (the event payload and enrichment), the model's reasoning and tool-call outputs, and the accumulating conversation history as the agent works a multi-step investigation. The surprising part for most teams is how dominant the static preamble is. A rich security agent might carry 25,000 tokens of unchanging context into every single run, and at thousands of runs a day that fixed cost dwarfs the variable per-alert cost.

This matters because the static portion is the most optimizable. It's identical across runs, which means it's a perfect candidate for caching. The variable portion — the actual alert — is small and irreducible. So the first rule of cheap security agents is: make the big part cacheable and keep the small part small.

Prompt caching: the highest-leverage lever

Prompt caching lets you mark a stable prefix of your context so that subsequent requests reusing that exact prefix are served far more cheaply and faster than reprocessing it from scratch. For a security agent whose system prompt, tool definitions, and playbooks don't change between alerts, this is transformational — you pay full price to establish the cache, then a steep discount on every reuse within the cache's lifetime.

flowchart TD
  A["Incoming alert"] --> B{"Static prefix cached?"}
  B -->|Yes| C["Reuse cached prefix, cheap & fast"]
  B -->|No| D["Process full prefix, write cache"]
  D --> C
  C --> E["Append small per-alert payload"]
  E --> F["Opus reasons & calls tools"]
  F --> G["Emit triage verdict"]

To get the benefit you must structure your context deliberately. Put everything stable at the front — system prompt, then tool schemas, then static playbooks — and place the volatile per-alert data at the very end. A single moving token near the top (a timestamp, a run ID, a shuffled tool order) invalidates the prefix and you pay full freight again. Treat your prompt prefix as an immutable artifact you version intentionally, not a string you casually interpolate. Order your tool definitions deterministically and keep dynamic values out of the cached region entirely.

One nuance for high-volume pipelines: caches have a finite lifetime, so caching pays off most when alerts arrive frequently enough to keep the prefix warm. If your traffic is bursty, consider a lightweight keep-warm strategy or simply accept that the first request in each burst pays full price. For a SOC firehose running continuously, the prefix stays hot and the savings are dramatic.

Batching the work that doesn't need to be instant

Not every security task is interactive. Overnight log summarization, weekly access-review enrichment, retroactive sweeps of historical events against a new indicator — these are throughput problems, not latency problems. For non-urgent, high-volume work, batch processing trades immediacy for a substantial cost reduction: you submit a large set of independent requests and collect results asynchronously rather than paying the premium for synchronous, low-latency responses.

The architectural move is to split your pipeline by urgency. A live, interactive triage lane handles alerts a human is waiting on, optimized for latency with a warm cache. A separate batch lane handles everything that can wait minutes or hours — enrichment backfills, periodic re-scoring, bulk classification of low-severity events — optimized purely for cost. Misrouting work between these lanes is the silent budget killer: paying interactive prices for a job nobody is watching, or making an analyst wait on a batch queue.

Independence is the requirement that makes batching work. If each alert's analysis depends on the previous one's verdict, you can't batch them; if they're genuinely independent classifications, you can fan out thousands at once. Most security enrichment is embarrassingly parallel, so design your tasks to be self-contained from the start.

Route by difficulty, not by habit

Reaching for Opus on every task is the most common and most expensive mistake. The Claude family spans Opus, Sonnet, and Haiku precisely so you can match model to difficulty. A huge share of security work — "is this a known-benign scanner?", "does this log line match a simple policy?", "extract the source IP and severity" — is well within a smaller, faster, cheaper model's reach. Reserve Opus for the genuinely hard reasoning: correlating a multi-stage attack, judging an ambiguous insider-threat signal, deciding whether to take a containment action.

A practical pattern is a triage cascade. A cheap model does first-pass classification on every event; only events it flags as ambiguous or high-severity escalate to Opus for deep analysis. This is the same shape as a SOC's own tiering, and it concentrates your most expensive reasoning exactly where it changes the outcome. The win compounds with caching: each tier has its own stable prefix, each stays warm, and the expensive tier sees a small, pre-filtered fraction of total volume.

Keeping context lean as investigations grow

Multi-step investigations accumulate history, and history is tokens you re-pay on every turn. A ten-turn investigation that carries every raw tool result forward can balloon the context until each subsequent turn costs more than the last. Compaction is the answer: periodically summarize completed sub-tasks into a tight findings block and drop the verbose intermediate results. The agent keeps the conclusions it needs and sheds the raw bulk it doesn't.

Be deliberate about what you keep. In security, the indicators, the verdicts, and the actions taken are load-bearing; the raw JSON of a fully-processed enrichment call usually is not. Sub-agents help here too — spinning a focused sub-agent to handle a noisy sub-task means its token-heavy back-and-forth never pollutes the orchestrator's context, and only the distilled result comes back. Used together, caching, batching, routing, and compaction routinely turn an Opus security agent from a budget alarm into a line item nobody questions.

Frequently asked questions

What is prompt caching and why does it help security agents?

Prompt caching is a feature that lets you mark a stable prefix of your prompt so reused requests skip reprocessing it, serving them faster and far more cheaply. Security agents carry large unchanging preambles — system prompts, tool schemas, playbooks — into every run, so caching that prefix removes the dominant repeated cost across thousands of alerts.

When should I use batch processing instead of live requests?

Use batching for high-volume work that nobody is waiting on in real time — overnight log summarization, enrichment backfills, retroactive indicator sweeps. It trades immediacy for a large cost reduction. Keep latency-sensitive triage that an analyst is actively watching on a synchronous, cache-warm interactive lane.

Should every security task run on Claude Opus?

No. Route by difficulty: use a smaller, cheaper model for simple classification and extraction, and escalate only ambiguous or high-severity cases to Opus. A triage cascade concentrates your most expensive reasoning where it actually changes the decision and keeps the cheap tier handling the bulk of volume.

How do I stop long investigations from getting expensive?

Compact the context. Periodically summarize finished sub-tasks into a concise findings block and drop the verbose raw tool results, keeping only load-bearing indicators and verdicts. Offloading noisy sub-tasks to focused sub-agents also keeps their token-heavy chatter out of the main context.

Bringing efficient agents to your phone lines

Caching the stable parts, routing by difficulty, and keeping context lean are exactly what make a real-time voice agent affordable at scale. CallSphere builds voice and chat agents that answer every call and message, call tools mid-conversation, and stay fast and cost-efficient under heavy load. See it live at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.