SUTRA: Less Output. More Signal.

SUTRA started because I couldn't get Caveman working properly with Hermes Agent. I was looking for a way to reduce the amount of tool output going into my coding sessions, so I decided to build my own solution instead of spending more time trying to fix that integration.

It started out as a small script to clean up command output. Remove repeated lines, get rid of noise, keep the useful parts and send less back to the agent. Nothing particularly complicated. But the more I worked on it, the more problems I ran into. Cutting output was easy. Making sure the agent could still get the information I'd removed was a different story.

The problem with tool output

A coding agent can spend a lot of time running tests, searching files, building projects and inspecting logs. Some commands return thousands of lines when only a few actually matter. A test run might have hundreds of successful tests followed by three failures. Build output repeats the same messages, and large JSON responses often contain far more information than the agent needs.

All of that goes into the context. It adds up, especially during longer coding sessions.

The obvious solution is to shorten the output, but blindly cutting it creates problems of its own. The useful information might be at the end of a traceback or buried somewhere in the middle of a log. I didn't want to build something that saved output at the cost of making the agent miss important details.

What SUTRA actually does

SUTRA sits between tool execution and the agent. It processes eligible output using deterministic rules, without asking another model to summarise it.

Depending on the result, it can remove terminal escape sequences, collapse repeated lines, keep the beginning and end of long output, or shorten long strings inside JSON while preserving its structure. Tracebacks get special handling so the actual error details aren't lost.

Not everything gets touched. Diffs and patches are left alone because changing them could hide actual code changes. Results that don't meet the compression rules pass through unchanged. If something goes wrong during processing, SUTRA fails open and returns the original output.

Here's roughly what happens:

Agent
  |
Tool execution
  |
Original output
  |
SUTRA
  |
Eligibility checks
  |
Deterministic processing
  |
Compressed or original output
  |
Agent

There is no attempt to understand what the agent is working on or guess which information matters to its task. SUTRA works on the output itself.

Getting information back

One thing I didn't want was compression that permanently threw information away. If an agent needed something that had been removed, there had to be a way to retrieve it.

SUTRA keeps the original output in a local recovery store when retention is available. The compacted result carries a reference that the agent can use with sutra_restore to retrieve the original, request a specific byte or line range, or search for a literal string.

This is useful with large logs. Instead of putting the entire thing back into context, the agent can retrieve the section it actually needs.

The store has limits on entry size, total capacity, entry count and expiration. It's local and permission-protected, but not encrypted, so that's something to consider when working with output containing secrets. Retention is also optional in practice: if saving the original fails or storage is disabled, SUTRA reports that it cannot be recovered rather than returning a restore reference that doesn't work.

             Original output
                    |
                    v
                SUTRA
                    |
             +------+------+
             |             |
             v             v
        Compact result  Local store
             |             |
             v             v
        Agent works    Restore if needed

From Hermes to other agents

Hermes was the starting point, but I didn't want the entire project tied to one agent. I eventually separated the compression and recovery logic from the integration code so different hosts could use the same core.

The current integrations are:

• Hermes Agent: native tool_execution middleware.
• Claude Code: PostToolUse hook with MCP recovery.
• OpenCode: tool.execute.after plugin with MCP recovery.
• Codex CLI: PostToolUse feedback hook with MCP recovery.

There's also a CLI and an MCP server for manual compression and recovery. An important detail here is that MCP by itself doesn't intercept normal tool output. Automatic compression needs an integration point provided by the host.

I also built an installer because manually setting up every integration gets old quickly. It detects supported clients, offers a dry run, backs up configuration before changing anything, and provides an uninstall path for the changes SUTRA owns.

A couple of things I added along the way

SUTRA eventually grew beyond just shortening output.

One addition is exact-output reuse. If an eligible result appears more than once during the same process session, SUTRA can recognise it and return a reference to the previously retained result. It checks that the stored content is still valid first; otherwise, it goes through normal processing.

Another addition is a cost-aware execution policy for Hermes. It uses Hermes' documented plugin API to provide bounded guidance at the start of new sessions. The idea is to reduce unnecessary tool calls and encourage agents to read only what they need. There are balanced and aggressive modes, with safeguards around tests, security checks, fresh evidence and error investigation. It doesn't modify the user's task or override the host's instructions.

Testing it

The first benchmark was pretty small. I used eight generated fixtures and measured a 54.3% reduction in bytes and 55.2% in estimated tokens. All eight planted clues were recoverable, and no diffs were changed.

I later expanded that to 23 fixtures, including cases specifically designed to make sure SUTRA didn't modify output that should remain untouched.

The zero-reduction cases are just as important as the compression results. If a diff is supposed to remain untouched and SUTRA leaves it alone, that's the expected result.

These are deterministic fixture benchmarks, not measurements from live coding sessions. I haven't done live-model A/B testing to establish how much this changes actual provider input tokens or whether it improves task completion. Reducing the size of a test payload doesn't automatically mean the API bill goes down by the same amount.

The benchmark methodology and results are in the repository if you want to reproduce them.

Where it stands

SUTRA is now a shared Python core with four agent integrations, a CLI, MCP recovery, an installer and a growing test suite. It's MIT-licensed and available on GitHub.

There are still things to work on. Every integration depends on what its host actually exposes. Codex can truncate very large results before SUTRA gets them, Cursor and Windsurf don't currently provide a supported generic result-replacement integration, and the local recovery store isn't encrypted. The real-world effect on model performance also remains unproven.

I'm focusing on reliability and testing the existing integrations against actual workflows before expanding support further. I'd rather support four agents properly than list ten integrations that barely work.

I didn't set out to build all of this when I started. I just wanted my Hermes sessions to produce less unnecessary output. Most of what SUTRA has become came from trying to solve the next problem I encountered while building it.