VynarisEarly betaGet your API key

Blog · 2026-09-13 · Vynaris Team

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

Verdict table

Claim or scenario             Numeric result                             Verdict
----------------------------  -----------------------------------------  -----------------------------------------------------
Bundled sample range          2%-96%                                     Real project-published command-output measurements
HN author's personal report   4.4M raw, 4.1M saved, 91.8%                Useful field report, not a controlled agent benchmark
Equal-command average, lite   36.5% of command output                    Becomes 7.6% of our complete API bill
Equal-command average, full   58.5% of command output                    Becomes 12.2% of our complete API bill
Equal-command average, ultra  86.5% of command output                    Becomes 18.0% of our complete API bill
Quality evidence              No published cost-per-correct-task result  Run a paired eval before broad rollout

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.

Command             lite   full   ultra
------------------  -----  -----  -----
git diff            16%    38%    96%
git log             53%    80%    91%
git status          62%    62%    74%
docker ps           38%    38%    85%
docker images       48%    58%    86%
ls -la              2%     75%    87%
Equal-command mean  36.5%  58.5%  86.5%

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.

Horizontal log-scale chart of Lowfat bundled-sample reductions from 2% to 96% across six commands and three levels.
Lowfat bundled-sample command-output reductions. Source: zdk/lowfat README at commit d1d0b5c, fetched 2026-09-13. Single-command samples, not whole-agent savings.

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.

Assumption                     Value                               Why it is explicit
-----------------------------  ----------------------------------  -----------------------------------------------
Non-command input              150,000 tokens/task                 Code, instructions, history, and tool schemas
Raw CLI output entering input  50,000 tokens/task                  The slice Lowfat can affect
Model output                   10,000 tokens/task                  Unchanged by the filter in this model
Command mix                    Equal raw volume across six rows    Makes the published table reproducible
Billing passes                 One                                 No claim that the same output is rebilled later
Retry effect                   Zero in the base case               Tested separately as the break-even
Model price                    $0.15 input, $0.60 output per MTok  Live GPT-4o Mini API rates

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

Level  Mean CLI reduction  Input after filtering  Cost/task   Saving/task  Saving/30k tasks  Total bill cut
-----  ------------------  ---------------------  ----------  -----------  ----------------  --------------
none   0%                  200,000                $0.0360000  $0           $0                0%
lite   36.5%               181,750                $0.0332625  $0.0027375   $82.13            7.6%
full   58.5%               170,750                $0.0316125  $0.0043875   $131.63           12.2%
ultra  86.5%               156,750                $0.0295125  $0.0064875   $194.63           18.0%

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.

Filterable share of input  lite, 36.5%  full, 58.5%  ultra, 86.5%
-------------------------  -----------  -----------  ------------
25%                        9.1%         14.6%        21.6%
50%                        18.3%        29.3%        43.3%
75%                        27.4%        43.9%        64.9%

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.

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