The Jev install prompt, checked line by line
A prompt is circulating that tells your coding agent to install Jev and consult it before expensive work. I checked every command and link against the sources. It holds up, with two things to know before you paste it.
A screenshot is doing the rounds with a large orange banner reading LLM → JEV → AGENT above a long prompt. Paste it into Claude Code, Codex or Cursor and the agent installs Jev from Typesafe AI as a decision layer, then consults it whenever a quick decision could save expensive work.
Earlier this week I wrote that Jev returns typed decisions in milliseconds and cannot write code at all. This prompt puts it where it belongs, as a gate in front of an LLM agent rather than a rival to one. I checked every command and link against the sources.
What the prompt asks the agent to do
It is organised as six steps, and the order is the most thoughtful thing about it.
- 1Understand my work. Name three situations from visible context where Jev could decide something before expensive work begins.
- 2Check this environment. Detect the agent, OS and capabilities, and test only the relevant install method.
- 3Use verified sources. Typesafe's official docs, plus a separate community repository for the routing code.
- 4Install and test. Offline dry run first, then set
TYPESAFE_API_KEYprivately and make one live call. - 5Make future use natural. Add a short instruction to
CLAUDE.md,AGENTS.mdor the equivalent. - 6Prove it works. Three test tasks, and no success claimed without evidence Jev was used on a real one.
What checks out
Nearly all of it. Taking the factual claims one at a time:
| Claim in the prompt | Verdict |
|---|---|
| Official quickstart and agent skill docs at docs.typesafe.ai | Correct. Both pages exist and cover the SDK, the API and the skill |
| The skill lives at github.com/typesafe-ai/skills | Correct. MIT licensed, installed in Claude Code with claude plugin install typesafe@typesafe-ai |
The key goes in TYPESAFE_API_KEY | Correct. The Python SDK reads it automatically |
Jev returns typed Choice, Score and Noul answers | Correct. Noul looks like a typo for Null but is Typesafe's real name for its yes or no probability |
| The clone, venv, pip and config commands | Correct. They match the playbook's QUICKSTART word for word |
| Official skill teaches the API, playbook supplies the router | Correct. Routers, shadow mode and decision logs appear only in the playbook, not in Typesafe's docs |
The safety instincts are also right. The prompt never asks you to paste the key into chat, forbids the agent from displaying or committing it, runs a dry run that makes no network calls before anything live, and starts in shadow mode, where Jev's recommendation is logged but the agent still acts on its own judgement. Irreversible actions stay behind human confirmation whatever Jev says, and typing bypass jev switches the whole thing off.
Best of all, it refuses to accept the usual forms of fake success. An SDK that imports is not an integration. An API call that returns 200 is not an integration. A line added to CLAUDE.md is not an integration. The only acceptable proof is a log showing that the agent consulted Jev during a real task. I wish more setup instructions were written this way.
How the router actually decides
Before costly work the agent builds a compact state: the goal in one line, the kind of task, whether a cached result exists, and the last error with its repeat count. It goes to Jev as a handful of parallel questions: an intent Choice, a reuse-the-cache Noul, a stop-retrying Noul and a complexity Score. The answer maps to one of eight actions, from chat_only and reuse_cache through research_capped and stop_retry to ask_human and proceed_full.
Confidence decides what happens next. At 0.80 or above the agent acts on the decision. Between 0.50 and 0.79 it treats it as a recommendation. Below 0.50 it asks you. If Jev is down or slow, the agent falls back to the normal path and carries on, so the classifier cannot become a single point of failure.
The repeated failure test shows the value best. Agents are bad at noticing their fourth identical attempt at a broken approach, and a calibrated "stop retrying" check costs a fraction of a cent.
Two things to know before you paste it
The router is a community project, three days old
The prompt separates the official links from muse-jev-playbook, but it does not tell you whose repository that is. It belongs to an individual GitHub account, not to Typesafe. It was created on 22 September 2026, has seventeen stars at the time of writing, and is MIT licensed. Its requirements.txt is just typesafe-sdk and pyyaml, both unpinned.
I read the skill and policy files and found nothing concerning; they are more candid about their limits than most vendor documentation. But step 5 asks your agent to adopt that repository's policy into its persistent instructions, which means a stranger's markdown file ends up shaping how your agent behaves in every future session. That is a supply chain decision, and it deserves the same scrutiny as adding a dependency.
Every decision sends a summary of your task off the machine
The compact state is designed to exclude secrets, and the policy is explicit about redaction. It still contains a one-line description of what you are doing and your most recent error message, and it goes to a third party's API every time the agent consults Jev. For personal projects that is fine. For client work under an NDA, or anything regulated, check that it is acceptable before you enable it, not after.
The limit the prompt is honest about
One line deserves more attention than it will get: do not claim that adding an instruction guarantees Jev will run. The playbook says the same: "this skill is a policy, not a hook." An instruction in CLAUDE.md is something the model reads and usually follows. It is not code that runs deterministically.
That produces a quiet irony. The frontier model still has to wake up, read your task and reason its way to the decision to ask Jev. Jev does not save that cost. What it can save is everything that happens afterwards: the ten page browsing session that was not needed, the subagent that duplicated work already in the cache, the fifth retry of a doomed approach. Whether those savings outweigh the extra step is exactly what shadow mode and the decision log are there to measure.
If you want the gate to fire every time, a Claude Code hook runs a script at a fixed point whether or not the model remembers. Take that step only once the shadow log shows the decisions are worth enforcing.
Verdict
The prompt is accurate. Every official link, command and type name checks out, and it is better engineered than most agent setup instructions: environment detection before installation, a dry run before live calls, shadow mode before enforcement, and evidence before any claim of success.
- Use it if your agent regularly burns time on research it did not need or retries it should have abandoned.
- Pin and read the playbook before letting it into your persistent instructions, because it is a young community project, not an official Typesafe component.
- Check your data obligations before running it on client code, because a summary of each task leaves the machine.
- Stay in shadow mode for your first twenty to fifty decisions, and only move to active when the log shows the high confidence decisions are right at least nine times in ten.
That last threshold comes from the playbook itself, and it is the right mindset for the whole exercise. Jev is a fast, cheap opinion. The log is how you find out whether it is worth listening to.
Building something like this?
I design and ship these systems for clients: retrieval over private data, agents that complete real tasks, and the Laravel platforms underneath them.