September 20 update: Beam CLI now has a separate optional Jev action-judging integration using TypeSafe's API directly. It starts disabled and uses observation by default when enabled. This article's discovery-only discussion concerns third-party Jev CLIs.
Jev is TypeSafe AI's "System One Model" — a non-generative model that answers classification-shaped questions instead of writing text. It launched 2026-09-15, and within two days, third-party projects like jev-guard and jev-axi started using it as a decision layer inside coding-agent hooks: risk-scoring a proposed tool call and returning allow, deny, or ask before the call runs. That puts a brand-new, largely unverified model in the exact spot Beam's own pre-action hooks live.
TL;DR
| Question | Answer |
|---|---|
| What is Jev? | TypeSafe AI's non-generative judgment model, launched 2026-09-15 |
| Why does it matter for hooks? | Third-party CLIs (jev-guard, jev-axi) risk-score tool calls before a coding agent's hook runtime executes them |
| One official hook contract? | No — fragmented across at least half a dozen independent CLIs shipped within 48 hours |
| Does Beam install a Jev hook? | No — discovery only (config/artifact presence), not an installable merge target |
| Accuracy proven for security gating? | Not independently — TypeSafe discloses a real accuracy gap against a full LLM |
| Jev itself attacked in published research? | Not as of this writing — a research gap, not a clearance |
What Jev actually is, and why it ended up in hooks
Jev doesn't generate text — it takes a typed question and a small set of possible answers and returns a calibrated judgment, the shape of decision a classifier makes. TypeSafe claims it's 20-200x faster and 40-400x cheaper than an LLM for that kind of structured decision, though explainx.ai's fact-check found the claim is TypeSafe's own self-benchmark — measured against agreement with other frontier models, not verified ground truth — with a real disclosed accuracy gap underneath (67.8% for Jev versus 74.1% for the best comparator LLM).
A pre-tool-execution hook — the mechanism Beam installs for Claude Code, Codex, Cursor, and Gemini CLI — answers exactly that shape of question on every tool call: is this risky, allow or deny or ask. explainx.ai's coverage of Jev's security positioning documents TypeSafe's own contains_prompt_injection primitive for this, a fast filter meant to sit in front of a main model. What's moved since is where the filtering sits: jev-guard and jev-axi risk-score a coding agent's tool calls — shell commands, file writes, MCP invocations — not just prompts, and return a deny/ask decision the hook runtime is expected to respect. A wrong prompt filter lets bad text through to a model; a wrong tool-call gate blocks real work or lets a risky action through unflagged.
There's no one Jev hook to trust
TypeSafe doesn't publish a single documented hook payload contract the way Anthropic, Cursor, and GitHub do for their own agents. At least half a dozen independent, unaffiliated projects shipped their own Jev-wrapping CLI within 48 hours of launch — a pace explainx.ai catalogued — each with its own config layout, credential storage, and idea of what payload to accept and what response to emit.
That fragmentation is why Beam treats Jev differently from the agents it already supports. Every agent Beam installs a hook for has a single, vendor-documented config file and payload shape Beam verified before shipping — Jev has neither, so there's no way to tell, without reading a specific project's source, what a "Jev said deny" in your hooks.json actually checked. beam agent list reflects that plainly:
│ jev │ Jev (TypeSafe AI) │ config wiring not built yet │ payload best-effort │
Beam checks for the config and artifact paths seen across the current ecosystem (~/.config/jev, ~/.config/jev-axi, ~/.jev), the same discovery pass it runs for every agent, so Jev shows up in inventory if it's present. It does not write or merge a hook config for it — there's no single contract to merge into, so there's nothing safe to install. If you're already running a Jev-based hook, Beam won't touch its config, and won't call the integration verified until a canonical contract exists to check against.
Why the accuracy gap matters more here
A prompt filter and a tool-call gate tolerate errors differently. TypeSafe's own disclosed accuracy gap is tolerable for a fast filter sitting in front of a slower, more accurate model that can still catch what it misses; it's a harder tradeoff for a tool-call gate with no second check behind it, where a false "allow" on a destructive command is immediate and irreversible. That doesn't make a Jev-based hook unsafe by default — the real question is what a specific build does on the roughly 6-point slice of decisions where Jev disagrees with a stronger model: fail open, or fail closed. That detail lives in each project's own source, not in anything TypeSafe publishes about Jev itself.
Honest limitations
- No independent security audit of any Jev-wrapping hook CLI exists yet — this describes the mechanism and ecosystem structure, not a benchmarked failure rate.
- No published adversarial research on attacking or poisoning Jev itself was found, a gap explainx.ai noted directly — treat "unattacked so far" as a research gap, not a clearance.
- Discovery of third-party Jev CLIs remains separate from direct API judging. Beam does not install those wrappers' hooks. See the optional direct integration guide for the newer workflow and its limits.
- This isn't a claim that Jev-based tool-call gating is unsafe — only that, absent a verified contract, it deserves the scrutiny any new dependency in a security-relevant path earns.
What this means for builders
If your hook chain already includes a Jev-based gate, know which project it is, know what it does on a low-confidence judgment, and don't treat it as your only defense against a risky tool call. That's the gap Beam fills regardless of what's making the allow/deny call upstream: it records what an agent actually did, so a bad call from any gate leaves evidence you can inspect, not just a decision you have to trust.
Related reading
- Introducing Beam: local-first AI agent security
- MCP security: a practical guide to tool poisoning and rug pulls
- What is AI agent monitoring?
- explainx.ai on Jev: speed/cost claims fact-checked · prompt-injection detector use case · six clones in two days · launch coverage
This post reflects Jev's ecosystem and Beam's own agent support as of 2026-09-19, four days after Jev's launch. Both are moving quickly — verify current hook-installation status with beam agent list and check TypeSafe's own documentation before trusting any third-party Jev-based hook in a production pipeline.