Jev doesn't write text. It answers typed questions in milliseconds, and charges only for what you show it. That combination turns three things that were too expensive or too unreliable to do per-turn into things you can do on every tool call.
Every number on this page came out of a working implementation — the repo runs the same code offline. Nothing here is illustrative.
The shape
Context is [frozen prefix] + [work area]. The prefix is append-only, so the
KV cache over it is never invalidated and every edit happens in the tail. Tool output is
judged on the way in rather than summarised on the way out.
And the gate relocates rather than deletes: what it removes goes to a store and leaves a pointer the agent can expand. Jev scores what to move out at write time and what to pull back at read time — the same call in both places.
Constraint → consequence
A request carries at most 32 questions against one shared state, and only input is billed. So the shape that matters is many questions over one state — and the mistake that costs real money is re-sending the same state once per item.
state. The
implementation has a test asserting every request's state holds exactly the items its
questions ask about — no more, no fewer.Phase 0
Eight turns of an agent session. The frozen prefix only ever grows; all the churn is in the work area. At a commit point the work area folds into the prefix and the cache boundary moves forward — it never moves back.
When is folding the tail in worth it? At 0.1× cache reads and 1.25× writes, compacting P down to P′ pays back after k = 12.5·P′/(P−P′) turns:
Phase 1
Jev can't generate text, which is the feature here: compaction becomes extractive. Every retained line is a verbatim original, so memory can never contain a fact some model invented while rewriting a summary of a summary.
expand tool with the agent: a gate
the agent can't undo isn't safe to turn on.The part that used to be impossible
Every decision is logged with its score. When the agent later calls expand,
that's ground truth the gate was too aggressive — it went looking for exactly what was
taken away. Replaying the log against a different threshold costs nothing and needs no
second agent run.
Below: 15 real decisions from three turns. Three of them the agent later came back for. Drag the threshold and watch what each choice would have cost.
That last column is what you actually tune on: of the things the agent had to go back for, how many would this threshold still have taken away. It's the number that says a gate is set too tight, and before Jev nobody could afford to collect it per-item.
Failure design
A false drop becomes a round trip instead of lost data. This is the one decision that makes the rest safe to turn on.
Jev unreachable means every item scores 1.0 and text passes through untouched. An outage degrades context to uncompacted, never to silently missing things.
If the scorer wants to remove more than 70% of an output, keep all of it. A scorer that wants to drop almost everything is reporting a bad question, not a worthless output.
Stack traces and diffs survive a low score. A halved stack trace isn't a stack trace, so segmentation never splits one either.
Rollout
These steps are ordered because each one produces what the next needs. Turning a context gate straight on is how you lose a week to “the agent got worse and nobody knows when”.
Phase 0 alone. The append-only buffer and a commit policy. No Jev, no store. Measure the cache hit rate you gain.
Shadow mode. shadow_only=True scores and logs everything and
changes nothing. A supported mode, not a debug flag.
Replay to choose a threshold. The slider above, against your own traffic instead of this demo's.
Turn it on and watch the false-negative rate. Above roughly 2%, the threshold is too tight.
Honest accounting
Four further ideas follow naturally from the same primitive, and none are implemented. Each needs metadata or hit data that doesn't exist on day one — so the hooks are in place and the collection is already running.
“Is this subtask finished?” as a typed question. Commit policies already go through a protocol so one can drop in without touching the buffer.
One call, ~15 parallel questions per record: type, lifecycle, entities, whether it corrects an earlier record. Memory management becomes code operating on metadata rather than a model rewriting text. The 32-question cap is the natural budget.
Ask whether a new record replaces each candidate old one, and keep a version chain with provenance instead of a pile of contradicting facts.
Combine Jev's expected relevance with observed hit counts. The collection half ships now — that's what the log above is.