Blog · 2026-09-13 · By Dhrumil Barot, Founder

Lowfat filters 2-96% of CLI output; the whole-agent saving is smaller

Lowfat removes 2-96% from sampled CLI output, but only 7.6-18.0% from our full task bill. Reproducible math, retry break-even, honest limits.

Lowfat removes 2% to 96% from one command's output in its bundled samples. Under our editable 200k-input, 10k-output task, with 50k raw command tokens and GPT-4o Mini, that cuts the total API bill by 7.6%, 12.2%, or 18.0%. It does not prove 91.8% whole-agent savings. Prices verified 2026-09-13.

TL;DR

• Lowfat's current README reports 2% to 96% reductions across six commands and three compression levels. These are single-command bundled samples.
• The equal-command averages are 36.5% for lite, 58.5% for full, and 86.5% for ultra. Equal weighting is our assumption, not the project's benchmark.
• Our representative task falls from $0.0360 to $0.0333, $0.0316, or $0.0295. That saves $82.13 to $194.63 per 30,000 tasks.
• A full retry rate above 7.6% to 18.0% erases those savings. Cost per successful task matters more than tokens removed.

Verdict table

The useful finding is narrow. Lowfat can remove a large fraction of noisy CLI text before it enters an agent's context window. The README demonstrates that filter behavior. It does not establish fewer retries, unchanged completion quality, or a matching reduction in the full bill.

What Lowfat actually sits between

Lowfat is a local Rust CLI. It rewrites shell commands through filters, or it compresses returned file content. Its integrations include a shell wrapper, a Claude Code hook, OpenCode, and direct prefixes such as lowfat git status.

The tool targets input tokens, not model output. A raw git log, docker ps, or lock file reaches the model as prompt context on a later turn. Removing lines before that boundary can shrink billed input and preserve working context.

The default full level tries to retain useful detail. lite removes less. ultra can collapse successful output to a verdict. The README also says failed commands receive raw output. That guard matters because an error path often contains the one stack frame the agent needs.

This is a deterministic preprocessor, not a semantic judge. Filters use rules such as line selection, regular expressions, head or tail limits, and format-specific compaction. The project architecture keeps the core small and moves command knowledge into plugins.

The current sample table spans 48x

The live README changed the evidence beneath the queue headline. Its current bundled-sample range is 2% to 96%, not 53% to 91%. We use the current table.

The mean gives every command the same raw-token volume. Real workloads rarely do that. A Kubernetes-heavy operations agent may be dominated by logs. A small library task may spend more context on source files than shell output. Use command history, not row counts, to weight the table.

The 48x spread is the warning. ls -la at lite removes 2%; git diff at ultra removes 96%. A single headline cannot represent both without the command and level.

Our editable cost model

We priced a representative coding-agent task with these assumptions. None came from Vynaris traffic.

OpenAI's live model page lists $0.15 input, $0.075 cached input, and $0.60 output per million tokens. It also verifies the active API alias gpt-4o-mini.

The unfiltered task costs:

200,000 x $0.15 / 1M + 10,000 x $0.60 / 1M = $0.0300 + $0.0060 = $0.0360

Change the token shape in the cost calculator before applying this result to your agent.

Cost per task, not cost per filtered line

Why does an 86.5% slice reduction become an 18.0% bill cut? The filter touches only 50,000 of 200,000 input tokens. It does not change the 10,000 output tokens. Output also costs four times more per token in this rate card.

This is the same denominator problem we found in our 33,000-token coding-agent scaffold audit. A large number can dominate a visible slice without dominating the complete task.

The Amdahl-style ceiling

Let f be the share of total input that comes from filterable command output. Let r be Lowfat's reduction on that slice. Ignoring retries and repeated context, whole-input reduction is f x r.

These are input-token ceilings, not full API-bill reductions. They exclude output cost. They also assume the removed text never causes another call.

The project's Hacker News launch thread makes that distinction unusually visible. The author reported 4.4 million raw command tokens and 4.1 million removed over two months, or 91.8%. Commenters asked for paired task-quality tests and cost per correct answer. Both statements can be true: the personal command slice shrank 91.8%, while end-to-end task economics remain unmeasured.

Honest tradeoff: lost evidence can cost more than saved tokens

Compression fails economically when it removes evidence and triggers enough rework. Under our assumptions, one full retry costs $0.0360.

• Lite saves $0.0027375 per task. A full retry on more than 7.6% of tasks erases the saving.
• Full saves $0.0043875. Its full-retry break-even is 12.2%.
• Ultra saves $0.0064875. Its full-retry break-even is 18.0%.

Those thresholds are derived, not measured quality results. A retry may be smaller than a full task. A hidden failure can also cost much more if it reaches review or production.

Do not filter novel stack traces, security diagnostics, migration output, or unfamiliar deployment failures aggressively. Lowfat's raw-failure fallback helps, but a successful command can still contain a warning that matters. Start with repetitive success output where the retained signal is easy to specify.

Caching does not automatically double the win

The live rate card prices prompt caching at $0.075 per MTok for GPT-4o Mini, half its fresh-input rate. If a removed prefix would have qualified for that price, each removed token saves half as much.

Most CLI output is dynamic. It may not form a reusable cached prefix. We therefore use fresh input pricing in the base model and make no cache-hit assumption. Our reasoning-token bill teardown shows the complementary problem: filtering input does nothing to expensive model-generated reasoning or visible output.

A rollout that can falsify the benefit

Measure the system in pairs. Run the same task corpus with and without filtering. Keep model, harness, repository state, task order, and tool permissions fixed.

Record four values per task:

1. Raw command-output tokens before filtering.
2. Filtered tokens after the same tokenizer.
3. Total billed input and output tokens across every turn.
4. Whether the task passed the same deterministic checks.

Then compute cost per task and cost per passed task. Include retries. Report the failure categories that changed. If ultra saves tokens but misses warnings, the correct result is not a larger saving. It is a failed filter policy.

Roll out by command. git status and successful docker ps are easier starting points than arbitrary logs. Keep the raw output available out of band so the agent can request detail without re-running the command.

When this does not need a filtering layer

Skip Lowfat when commands are already narrow, CLI output is a small fraction of input, or the agent runs on a fixed subscription with no useful token meter. A direct --json query plus a field selector can be clearer than another plugin.

Also skip it when the team cannot maintain filters. The tool is local-first and configurable. That is a strength for privacy, but configuration has an owner. Stale filters become hidden policy.

The per-request cost in our example is already $0.0360. At 1,000 tasks, full mode saves $4.39. If setup and review consume two engineering hours, the dollar payback may be absurdly long. Context pressure can still justify it, but call that a context benefit rather than an API-cost win.

FAQ

Does Lowfat save 91.8% of an agent's total tokens?

No controlled result establishes that. The HN post reports 91.8% removed from the author's raw command-output history. The current README explicitly says its percentages are not end-to-end agent savings.

Which published sample saved the most?

git diff at ultra removed 96% in the bundled sample. ls -la at lite removed only 2%. The result depends on command, sample, and level.

What did the representative task save?

It saved 7.6%, 12.2%, or 18.0% of the complete API bill at lite, full, or ultra. The task has 150k other input tokens, 50k raw command tokens, and 10k output tokens.

Is ultra the best default?

No. Ultra has the largest token reduction and the highest information-loss risk. Use the least aggressive level that passes paired task-quality tests.

Is this a Vynaris production benchmark?

No. The workload is an editable public-source cost model. It contains no Vynaris traffic, customer, routing, or telemetry data.

Sources

• Lowfat repository and live README, commit d1d0b5c2d80ab1f3788f20414c5eb6c70575f7bc, fetched 2026-09-13.
• OpenAI GPT-4o Mini model page, model alias and prices verified 2026-09-13.
• Hacker News launch discussion, 156 points and 80 comments when fetched 2026-09-13.
• Reproducible arithmetic: artifacts/lowfat-cli-filter-53-91-percent-token-reduction-math.py.