What the Gateway Can Safely Promise

OmniRoute's claims about savings, free capacity, privacy, and safety are useful only when their conditions are visible. This chapter examines those conditions: what the compression pipeline can remove, how the free-tier catalog counts capacity, where a local-first deployment still sends data, and how authorization, guardrails, and audit records divide responsibility. The goal is to judge an efficiency or privacy feature as an operator would—not by its headline, but by its eligibility rule, failure behavior, and evidence.

Compression works by removing eligible redundancy

In a coding-agent session, the expensive part of a request is often not the user's latest sentence. It is the accumulated context around it: repeated build errors, long shell output, old turns, verbose tool results, and instructions that appear again and again. OmniRoute's compression pipeline runs before provider translation so it can reduce that context without requiring the client to change its protocol. The gateway chooses a plan from global settings, a routing-combo override, an active profile, an automatic threshold, or a per-request instruction.

The repository describes a current stack of 12 composable engines, while its older user guide groups the experience into seven visible modes: off, lite, standard, aggressive, ultra, RTK, and stacked. These are different levels of description. The conceptual division is more important than the exact menu: some operations are light and lossless, some understand command output, some condense prose or age history, some use heuristic or machine-learning pruning, and some are experimental. Not every request runs every engine, and a profile can choose a narrower path.

Lite mode illustrates the conservative end. It can collapse redundant whitespace, remove duplicate system material, shorten image data references, and clean verbose tool results with minimal semantic change. RTK operates on a different kind of redundancy: it recognizes command, build, test, git, linter, and shell output, then aims to keep failures, warnings, changed files, summaries, and the useful tail while removing progress noise and repeated lines. Caveman-style rules condense natural-language phrasing by removing filler and redundant words. History aging applies stronger reduction as turns become older, rather than treating every message as equally important.

The default stacked example combines RTK and Caveman in that order. The savings are multiplicative because the second engine acts on what remains after the first. If RTK removes 80% of an eligible tool payload and Caveman removes 46% of the remaining input, the combined reduction is:

1 − (1 − 0.80) × (1 − 0.46) = 0.892, or 89.2%.

The documented range is approximately 78.4–94.6% for the stated overlapping assumptions. That arithmetic is sound, but it does not mean that every request will be 89.2% smaller. It describes a payload on which both engines have useful work to do.

The guide gives a revealing contrast. A test using a tool result containing 300 identical error lines produced 95.93% token savings with the stacked path. A clean grep result, a short file read, or ordinary conversation produced near-zero savings because there was little redundancy to remove. This is not a failure of the compressor. A system that aggressively rewrote already-compact code or a precise error message would be creating risk to claim a larger percentage.

That is why eligibility and fidelity gates matter. OmniRoute documents protection for code blocks, URLs, file paths, JSON and other structured data, technical identifiers, mathematical expressions, tool definitions, and—in the safest mode—system prompts. Its validation layer can refuse a rewrite that would drop or alter protected structures, headings, versions, or all-caps identifiers.