Try it with your own rules
Start from the preset below, adapt the questions, and inspect the typed answers. Run it live in the playground — it is the same request shape your application will send.
What Jev returns
Illustrative output for the preset below — run it live to get real values for your input.
Ship the payment-retry fix behind a feature flag
Note from step 3: "Stripe test key expired; rotated to rk_test_… — billing sandbox now green."
14 steps old · tool note · 41 tokens
What kind of context item is this?
Is this item still needed to finish the current goal?
P(yes) = 0.22 — the fix landed; the rotated key is recorded in env, not needed in context
If kept, how valuable is this item relative to its token cost?
From one example to a reusable workflow
Judge items, not summaries
Ask Jev about each context item against the current goal — keep/drop decisions stay auditable, unlike a rewritten summary you can't diff.
Archive, don't delete
Dropped items go to an archive the agent can re-query; a reversible drop beats a confident deletion when the next step fails.
Score against the goal, not importance
An item can be important and still irrelevant to the current step — the instructions must anchor on the goal, not the item's general worth.
Keep the criteria separate
| Check | What it measures | How to use it |
|---|---|---|
| Category · Choice | What kind of item is this? | Facts, plans, artifacts and stale notes want different retention — route them differently. |
| Keep · Yes/No | Is it needed for the current goal? | The noul threshold is your aggressiveness dial: lower it when the agent keeps losing needed context. |
| Value · Score | Is it worth its tokens? | Score value-per-token so a 400-token marginal item loses to a 20-token essential one. |
Selection over summarization
A summary rewrites evidence into prose you can't verify. Selection keeps items verbatim and drops the rest — every kept token is exactly what the tool produced, so the next step still sees ground truth.
Per-item decisions share the goal
Each question carries the same current goal in the state, so every item is judged against the same anchor — no drift, no summary-of-a-summary decay.
Measure the recovery rate
The metric that matters is not tokens saved but how often the agent needs archived context back. Log drops and recalls; a compaction policy that never recalls is probably over-keeping.
FAQ
Why not just summarize with the main model?
Summaries are lossy and unauditable — the model rewrites what it keeps. Jev selection keeps items verbatim, so downstream steps see ground truth, not a retelling.
How many items can I judge per call?
Ask up to 8 questions in one request — e.g. keep, category and value for two items, or one question each across a batch of items.
Does this replace a memory store?
No — it sits between your store and the prompt. Your store owns persistence; Jev decides what gets re-loaded into the next context window.