Agentic search cost is triangular, not linear.

Multi-step search inside a single agent loop: the agent issues a tool call (Grep, Glob, Read, WebSearch), receives the output, decides the next step, calls another tool, and repeats until it has enough context to answer or edit. The Claude Code CLI, Cursor's Composer agent, and Codex are all agentic searchers. The distinction matters because each tool result joins the input window for every subsequent turn in the same conversation, so search cost is cumulative within a session, not per-call.

Because the cache key for input tokens is byte-for-byte. A 5,000-token Read at turn 1 enters the input window and stays there for turns 2 through T (until the conversation ends or summarization fires). At Opus 4.7 input pricing of $15 per million tokens, that single Read is paid for 30 times across a 30-turn session, not once. The cumulative tokens for T turns each adding one fresh tool output of size S is S * T * (T+1) / 2, the triangular number times S. For T=30 and S=5,000 that is 2.3 million tokens, $34.88.

Cached input is 90% cheaper at Opus 4.7 rates, so yes, caching reduces the multiplier from 30 to roughly 3 once cache hits land. But cache hits require a byte-identical prefix from the previous request. Any volatile text (a dynamic date, a tool output that mutates between turns, a session-specific identifier) breaks the cache for everything that comes after it. The ccmd analyzer's cache_bust check at analyzer.ts:194 catches the worst offender (ISO date in the first 20 lines of CLAUDE.md). It does not catch every cache break inside a long agentic search session, that is on the agent's tool-use discipline.

Four moves, in order of impact. (1) Read large files in slices with offset+limit. A 400-line Read pulled as a single chunk is ~5k tokens; the 20-line slice you actually need is 250. (2) Grep before Read. A Grep call returns matching lines, not whole files. Read only the slices the grep surfaced. (3) Use a subagent for broad search. The main loop sees a 1-2k summary; the subagent's internal context never lands in your main session. (4) Stop re-reading files you already read this session unless they were edited. Each of these is a one-line rule in CLAUDE.md, but the agent only follows them if you make them load-bearing (concrete thresholds, a Why, an example).

The static formula at src/lib/analyzer.ts:263-269 models CLAUDE.md cost (totalTokens * 30 turns * $15/M Opus 4.7). It does not model the cumulative re-billing of tool outputs because the analyzer is a pure function with no session state. What it does is grade your CLAUDE.md on the four rules above: it flags missing Grep-before-Read patterns, missing slice-read directives, and vague tool-use language that the agent silently ignores. The bend in the agentic search cost curve happens upstream of the analyzer, in your config file.

Cost CLIs like ccusage and claude-meter report the bill after the fact and decompose by model, not by tool. They will tell you that this session cost $27.71; they will not tell you that $24.94 of it came from re-billed Read outputs. Anthropic's own context-engineering post mentions cumulative cost in one sentence but does not derive the triangular formula. LangChain and CrewAI explainers treat 'agentic' as a synonym for multi-agent, which is a different cost shape. ccmd is the only analyzer that points at the CLAUDE.md lines that control the per-turn search behavior, and this guide is the math behind that.

Yes. The same triangular cost applies to any agent loop where tool outputs accumulate in the input window across turns. Codex (AGENTS.md), Cursor's Composer (.cursorrules), and xAI Grok Build (.grokrules) all use the same tool-output-stays-in-input model. The ccmd analyzer detects type by content and runs the same rubric against all four file formats.

No. Agentic search is the reason these tools are useful at all. The argument is that the cost shape is non-obvious and that a small amount of tool-use discipline in your CLAUDE.md (or AGENTS.md, or .cursorrules) gives you 4-6x cost savings without changing how you work. The rules you want are short and specific. Paste your config into ccmd.dev and you get the same checks the analyzer would flag at code review.