pi-jev vs pi-jev vs pi-typesafe: Three Takes on One Editor

The Pi coding agent has no built-in MCP client, so anyone who wants Jev inside it has to write a Pi-native extension instead. As of September 2026, three people have done exactly that, and the naming makes it easy to grab the wrong one. Two projects are both called pi-jev, from different authors, doing different jobs. A third, pi-typesafe, does a third job again. All three use TypeSafe's Jev System One model, which returns typed scores and choices rather than prose, but they point that model at three different problems: safety gating, tool discovery, and shared plumbing.

This is a good case study in how fast an ecosystem forms around a new primitive and how little coordination there is between the people building on it. If you use Pi and want Jev, read this before you git clone the first result that comes up. For the underlying idea, see what Jev is and why typed decisions beat free text.

Key Takeaways

• Same name, different jobs. y0usaf/pi-jev is a safety gate. TheoOliveira/pi-jev is a tool-and-skill router. Check the author, not just the repo name.
• y0usaf's is the most-starred of the three, at 140 stars as of September 2026, and the only one categorized as Security rather than Integrations.
• All three fail open or fail closed by design, not by accident — each README states explicitly what happens when Jev is unreachable.
• pi-typesafe is infrastructure, not a feature. It exists so other Pi extensions can share one API key and one usage budget instead of each prompting for credentials.
• None of these are official TypeSafe releases. They're community extensions built in the weeks after Jev's release, with correspondingly thin track records.

y0usaf/pi-jev: a safety gate that fails open

y0usaf/pi-jev (MIT, 140 stars as of September 2026, listed under Security) puts Jev in front of Pi's tool calls, not behind them. Before a tool executes, the extension asks Jev to score it across four dimensions: destructive potential (flagged above a 0.90 threshold), data-exfiltration risk (0.70), whether the action falls outside what the user asked for (0.85), and an overall impact severity on a 0–3 scale (flagged above 2.50). A separate output judge checks bash results for credential leaks at a 0.90 threshold and classifies failures as transient, environmental, a code bug, a permissions issue, or user error.

The default posture is shadow mode: risky calls are flagged with a notification and logged to a transcript, but nothing is blocked. Enforce mode requires explicit user confirmation before a flagged call runs. Headless sessions default to warnings unless gate.blockWithoutUI is set. The README is candid about failure behavior: "every error path fails open" — a missing API key, a timeout, or a malformed response produces no verdict, and the tool proceeds as if nothing had been asked. That is a defensible design for a gate that must not become a single point of failure, but it also means the gate provides no protection at all when Jev is unreachable, which the project does not pretend otherwise. Its own calibration is described as a six-run "smoke calibration," and file contents in write and edit operations leave the machine as part of the judged payload — worth knowing before you point it at anything sensitive. On aiskill.market: /skills/pi-jev-y0usaf.

TheoOliveira/pi-jev: routing tools and skills, not guarding them

TheoOliveira/pi-jev (MIT, 42 stars as of September 2026, listed under Integrations) is a different animal entirely, despite the identical repo name. It uses Jev for semantic tool routing: jev_find_tools looks at the user's prompt and activates only the relevant tools from an otherwise-inactive registry, instead of loading everything into context up front. jev_find_skill does the same for specialized agent skills and workflows. A third primitive, jev_evaluate, exposes raw Choice, Noul (probability) and Score judgments for general classification and triage work. There's also a Jev-driven compaction mode that selectively retains the tool-history entries judged most relevant to the user's intent when context gets trimmed — a lighter, Pi-specific cousin of the ideas covered in context GC and compaction.

Every automatic mode here is opt-in, requires a TYPESAFE_API_KEY, and is described as failing closed safely — the opposite failure posture from y0usaf's gate, and the right one for a feature that adds convenience rather than removes risk. The README states plainly: "a Jev failure leaves the turn untouched." On aiskill.market: /skills/pi-jev-theooliveira.

pi-typesafe: the shared plumbing underneath

DevMortimer/pi-typesafe (MIT, 42 stars as of September 2026, listed under Integrations) doesn't compete with either pi-jev — it's closer to a library other extensions could build on. It ships an agent tool, typesafe_evaluate, disabled by default until a user runs /typesafe enable after acknowledging that state gets sent to TypeSafe. That tool accepts up to 32 typed questions per request, each answered as Choice, Score or Noul. A terminal playground (/typesafe test, /typesafe playground, /typesafe status) lets a developer try requests and check usage without touching the model's context. The third piece is an extension API: other Pi extensions can import the library to share one authenticated client instead of each prompting for a key separately.

The shared client enforces its own limits — a 20-request session cap, daily token and USD budgets, a 64 KiB JSON ceiling per request — and is designed to "never throw," returning error codes for budget exhaustion or auth failure instead. Usage counters persist across restarts in ~/.pi/agent/pi-typesafe/usage.json. The README is direct about the tool's shape: it handles batch classification well and multi-step reasoning not at all, and ambiguous questions return middling probabilities rather than errors, which is a property worth testing against before you trust a threshold. On aiskill.market: /skills/pi-typesafe-devmortimer.

What to do next

1. Match the repo to the author, not just the name. If you're looking for a safety gate, you want y0usaf/pi-jev. For tool and skill routing, TheoOliveira/pi-jev. For shared credential plumbing other extensions can build on, DevMortimer/pi-typesafe.
2. Decide your failure posture up front. A gate that fails open (y0usaf's) needs a backup layer if Jev availability matters to you. A router that fails closed (TheoOliveira's) just degrades gracefully.
3. Start in shadow or opt-in mode. All three default to the safer, non-blocking configuration. Watch the logs before you flip anything to enforce.
4. Treat calibration claims as early. Six-run smoke calibrations and opt-in-only automatic modes are honest signals that these are days-old projects, not hardened infrastructure.
5. Browse the radar for more Pi extensions. The Awesome Jev projects list tracks new entrants; see how to evaluate Jev projects honestly before adopting any of them.