>Freeing 10% of Your Agent's Context with Jev
When I first saw Jev, I was fascinated. It's a model that doesn't write text at all. It answers a question with a probability, in a few hundred milliseconds, for almost nothing. And people were already doing interesting things with it: triaging 500 emails for 3.5 cents and even playing Doom. I started thinking about how to put it inside my harness. But where? It should be a place where a fast decision helps. Maybe it could replace the main model for some small choices? I didn't know. There was no obvious spot. Then I noticed I had crossed 1,000 sessions with the Pi coding agent. That felt like enough data to find my harness's weakest point. So I decided to dig in.
What 1,000 sessions told me
I took all my meaningful Pi sessions and dropped the ones that lasted only a few rounds, like quick questions and aborted starts. That left 1,093 sessions and 520 million characters. Then I split every record in those sessions by type: what I typed, what the agent said and thought, what it sent to tools, and what tools sent back.
| What's in the session | Share |
| Tool outputs (file reads, command output, web pages) | 79.3% |
| Tool inputs (commands, file edits) | 11.7% |
| Agent replies | 2.8% |
| Messages injected by extensions | 2.6% |
| Agent reasoning | 2.1% |
| My prompts | 1.1% |
| Compaction summaries | 0.5% |
Most of the session was tool output: files the agent read, commands it ran, pages it fetched. And all of it stays in the context until compaction.
From this table it was clear: tool output was the one thing worth improving. So I dug deeper. Which tools produce it, and what do those outputs look like?
| Tool | Share of tool calls | Share of tool output | Average output |
read (file reads) | 23% | 43% | 6,100 chars |
bash (commands) | 50% | 35% | 2,300 chars |
fetch_url (web pages) | 5% | 10% | 7,200 chars |
| MCP tools | 2% | 6% | 10,300 chars |
edit / write | 10% | 0.3% | 100 chars |
| Everything else | 10% | 6% |
Bash is half of all calls, but file reads carry the most output. Most results are small, like a short ls or a quick git status. But results longer than 8,000 characters, only 10% of calls, hold 65% of all tool output. These are full file reads, long test logs, and whole web pages. The agent reads a whole file to change a few lines in it, then carries the entire file through every turn that follows.
So here's the idea: what if Jev looked at each big result the moment it arrived and decided which parts the agent would actually need?
Let's do Jev
I built a small Pi extension, pi-jev-triage. It runs on every tool result and passes only what's needed on to the agent. It only looks at big outputs from tools that read things: read, bash, grep, fetch_url, and MCP tools. Small results and edits pass through untouched. I borrowed the Jev-specific questions from winnow, a similar project made for Claude Code.
tool returns a big result
↓
split it into blocks of ~25 lines
↓
Jev scores each block: "will the agent need this?"
↓
blocks scoring 0.20 or lower → replaced with a short stub
↓
agent needs it after all? → pi_jev_recall brings it back
Jev doesn't judge blocks in isolation. It also gets the user's latest prompt, the end of the agent's last reply, and the tool name. So it answers "is this needed for this task".
A tool that deletes context has to be careful. A wrong cut can send the agent down the wrong path. So I made a few simple rules:
- Fail open. If Jev is slow or returns an error, the full result goes through. Nothing gets hidden without an answer.
- Forget at the door. Each result is judged once, when it arrives. Earlier messages are never rewritten, so the prompt cache stays warm.
- Keep the edges. The first and last block of every result always stay. Blocks Jev isn't sure about stay too.
- Don't bother with small cuts. If less than 20% of a result would be hidden, the result stays whole.
Does it actually work?
I tested it on SWE-bench Lite: 20 real GitHub issues, with GPT-6 Sol as the coding agent in Pi.
| Setup | Tasks solved | Context saved | Recalls |
| Jev, drop at 0.10 | 10 / 20 | 3.1% | 4 |
| Jev, drop at 0.15 | 10 / 20 | 7.0% | 6 |
| Jev, drop at 0.20 | 10 / 20 | 7.4% | 8 |
In every run, GPT-6 Sol with Jev solved the same 10 tasks, no matter how much Jev hid. Hooray! Nothing broke. On my own longest sessions, with big file reads and long logs, it freed 9.7% of the context at 0.20. SWE-bench tasks are shorter, so the saving there is smaller.
What about the agent needing something that got hidden? I checked every session. Agents re-read files all the time. Trimmed files didn't get re-read any more often than the rest. Even at 0.20, where Jev hid the most, the agent asked for a hidden block back only 8 times across 20 tasks. And not a single failure traced back to a hidden block.
What you get
The agent keeps more free space in its context, so it can work longer before compaction and stay focused on what matters, instead of dragging old file dumps along. However, there were no clean wins on task speed or cost.
This was hard to test. Jev is so popular right now that the gateway kept answering with 429s. Every run and every rerun fought rate limits.
I love experimenting with context. I like being brave enough to change it in the middle of an agent session and see how that affects the results. Having this built into the harness is one of the coolest parts of agentic engineering for me. A fast decision model makes it cheap enough to do on every tool result. We get to decide what enters the context in the first place.
Try it:
pi install npm:pi-jev-triage