Token saving

Every request through merido can be made cheaper without changing your tools. Two mechanisms do the work; the one with a measurable before/after — tool_result compression — is recorded in the savings ledger, while Caveman mode is intentionally left out of the ledger (see below). A hard rule underpins both: the token-saver must never grow or empty content — it fails safe.

tool_result compression (automatic)

Coding agents send large tool_result blocks back to the model — file dumps, command output, search results. These are mostly low-signal tokens. merido runs RTK-style compression filters over tool output, auto-detecting the kind of content and shrinking it while preserving meaning.

This is on by the gateway's defaults and requires no per-request configuration. You can inspect which filters are active via GET /api/token-saver/filters (or the dashboard).

Caveman mode (opt-in output compression)

Where tool-result compression shrinks input, Caveman mode cuts output verbosity by injecting an intensity-tuned, format-aware system prompt that nudges the model toward terser responses. Set MERIDO_CAVEMAN_LEVEL to one of:

Level	Effect
lite	Light trimming of filler; safest.
full	Noticeably terser output.
ultra	Aggressive compression.
wenyan-lite / wenyan / wenyan-ultra	Classical-Chinese-style ultra-dense variants.

Leave it unset (or blank) to disable; an unrecognised value is ignored and logged at startup.

The tradeoff: more aggressive levels save more output tokens but can strip nuance, formatting, or explanation. Start at lite, measure, and increase only if the terser output is acceptable for your use case. Caveman affects style, not correctness-critical content.

Caveman savings are not booked into the savings ledger. Unlike tool_result compression (which has a measurable before/after byte count), Caveman shapes the model's future output, so there is no honest per-request counterfactual for "what the response would have cost without it." merido deliberately does not record a Caveman line in the ledger rather than book an estimate it cannot prove. Its effect shows up indirectly as lower output-token usage, not as a ledger receipt.

Ponytail mode (opt-in, cuts how much code the agent writes)

Ponytail mode is opt-in and independent of — and stackable with — Caveman: Caveman compresses response prose, Ponytail targets code volume. It injects a "lazy senior dev" system prompt that pushes the model down a reuse-first ladder (YAGNI → reuse what's already in the codebase → stdlib → native platform feature → an already-installed dependency → one line → the minimum code that works) before it writes anything new. Set MERIDO_PONYTAIL_LEVEL to lite, full, or ultra (leave unset/blank to disable); like Caveman, both knobs can be set at once since they act on independent axes.

Honesty note: Ponytail is not booked into the savings ledger either, for the same reason as Caveman — there's no honest per-request counterfactual. And unlike prose compression, less code written is not automatically fewer net tokens: on reasoning models the extra thinking spent choosing the leaner approach can outweigh what's saved, and if the leaner prompt busts a large cached prefix, the cache-miss cost can exceed the output savings. Measure on your own workload before enabling it broadly.

The savings ledger

merido records what each measurable optimization saved into a savings ledger — the "the gateway paid for itself" receipts. tool_result compression is booked here with directly measured token counts; Caveman mode is not booked (there is no honest counterfactual — see the note above). View it:

• CLI: merido gain — usage totals and estimated cost.
• API: GET /api/savings (raw receipts), /api/savings/totals, /api/savings/rollup, /api/savings/export.
• Dashboard: the savings view renders these totals and rollups.

Related

• Caching — avoid paying for a request twice.
• Usage & the Advisor — find more savings automatically.
• Built-in MCP endpoint — call the same filters from an MCP client via rtk_compress.