Use cases
Reductions are whole-request input-token cuts measured on each workload's benchmark payload
(how they're measured). The strategy ids link into the
strategy reference. One routing rule explains most of the table: the
same data takes context_compression when it
arrives as JSON and relevance_filter when it
arrives as text.
Engineering
Most of these are one paste away: a log, a diff, a test run, or a pile of re-read files where the
answer lives in a few lines. command_digest works off
the output's shape rather than the question, so it keeps cutting even on cached traffic.
code_graph savings track how targeted the question is: a
broad "map everything" keeps more bodies than a single call-path trace, which is why its two rows
differ.
| Workload | What you ask | Strategy | Reduction |
|---|---|---|---|
| Access log | "find the failing 5xx requests" | relevance_filter | ~99% |
| Incident debugging | "why did p99 spike at 10:05?" | relevance_filter | ~98% |
| GitHub issues | "which open issues are P0 auth bugs?" | relevance_filter | ~83% |
| JSON dump | "which of these 500 orders failed?" | context_compression | ~39% |
| Test-suite output | "which tests failed and why?" | command_digest | ~77% |
| Code search | "where is the retry policy configured?" | relevance_filter | ~72% |
| Git diff review | "any change that weakens an auth check?" | relevance_filter | ~72% |
| Codebase exploration | "map the architecture; where do retries live?" | code_graph | ~15% |
| Multi-file code trace | "how does submitOrder capture a payment?" | code_graph | ~33% |
| Long agent session | "given all the above, where should X live?" | window_budget | ~72% |
| MCP tool-schema bloat | any request from a tool-loaded assistant | tool_pruning | ~91% |
| Verbose tool descriptions | a tool-loaded assistant on cached traffic | tool_schema_compression | ~8% lossless |
| Catch me up on a branch | "where does the payments-retry branch stand?" | relevance_filter | ~86% |
| Decision recall | "what did we decide about the job queue, and why?" | relevance_filter | ~74% |
The two tool-schema rows compound. Schema overhead runs roughly 1k tokens per tool, and a
tool-loaded assistant ships every schema on every request, used or not: tool_pruning drops the
ones the task can't use, and tool_schema_compression shrinks the descriptions of the ones that
stay, including on the warm cached turns where pruning holds its pinned set.
Working with data
The engineering mechanics pointed at analyst traffic: exported rows ranked against the question, result-set JSON shrunk, a dbt or ETL run digested exactly like a test run, and a nightly template's repeated instruction block collapsed to one copy.
| Workload | What you ask | Strategy | Reduction |
|---|---|---|---|
| Spreadsheet export | "which orders are EMEA refunds?" | relevance_filter | ~90% |
| Database schema for text-to-SQL | "write the query for revenue by region" | relevance_filter | ~88% |
| Query result set | "which accounts are past due?" | context_compression | ~96% |
| Data-pipeline run | "which models failed, and why?" | command_digest | ~75% |
| Recurring report | nightly summary over N datasets | prompt_compression | ~80% |
The text-to-SQL row is the extreme case: a "chat with your data" tool ships hundreds of
CREATE TABLE definitions on every question when any single query touches a handful of tables.
Dropped tables stay retrievable, so the model can pull one back if it needs it.
Knowledge & operations
Handbooks, RAG chunks, and recalled notes: rank what was pasted or retrieved against the live question, keep what answers it. Most RAG pipelines over-fetch 3 to 5 times what the answer uses. Recall-driven workflows (research notes, a back catalogue, the week's activity) are the same ranking pointed at an agent's memory store, and the saving grows as the store does.
| Workload | What you ask | Strategy | Reduction |
|---|---|---|---|
| Policy lookup | "what's the parental-leave policy?" | relevance_filter | ~80% |
| RAG over-retrieval | "what does the refund policy say about X?" | relevance_filter | ~67% |
| Repeat question | the same support question, asked again | semantic_cache | provider call skipped |
| Templated batch prompt | nightly classification over N tickets | prompt_compression | ~82% |
| Research brief | "everything I found on vector DBs, in one brief" | relevance_filter | ~85% |
| Content memory | "what have I published on onboarding?" | relevance_filter | ~81% |
| Open loops | "what is still open and waiting on me?" | relevance_filter | ~79% |
Agent automations
Multi-step pipelines (fetch, process, write back) call the model once per item, and every call
drags the full fetched payload into context. Anyray cuts the token cost of those bulky data legs;
it does not parallelize or remove steps, since that orchestration lives in your agent runtime, so
the saving is per-call cost, not wall-clock. On recurring runs
semantic_cache also skips re-processing an item an
earlier run already handled: an article already summarized, a company already enriched.
| Workload | What you ask | Strategy | Reduction |
|---|---|---|---|
| Email filtering | "which are assigned to sarah@company.com?" | context_compression | ~95% |
| Article summary pipeline | summarize each of 20 fetched articles | context_compression | ~70% |
| Customer data enrichment | enrich 150 records, write back | context_compression | ~93% |
| Multi-source aggregation | weekly report from three source dumps | relevance_filter | ~88% |