Jev works with OpenCode two different ways that solve two different problems. TypeSafe's own official skill teaches OpenCode to write correct Jev API calls when you ask it to build something. A separate, community-built project gates OpenCode's own actions using Jev's judgment before they run, and that project actually splits into two more paths with two different sets of environment variables. This guide covers all of it, the exact `opencode.json` configuration, and the one setting (signup access) that changes without warning.
Before anything else: Jev is not a replacement coding LLM, and it does not power OpenCode. TypeSafe states this directly, naming OpenCode specifically: "Jev is not a drop-in replacement for the LLM behind Claude Code, Cursor, opencode, Copilot, Muse Spark, Grok Bot, or similar tools" (docs.typesafe.ai/introduction/coding-agents). OpenCode's own model still writes every line of code. Jev only answers narrow, typed questions that code calls it for.
Key Takeaways- There are two separate Jev-plus-OpenCode paths: the official TypeSafe skill (teaches OpenCode to write Jev integrations) and the community `jev-computer-use` project (gates OpenCode's actions using Jev).- That community project itself splits in two: an MCP server (`jev-mcp`, configured in `opencode.json`) and a direct code path (`gate.mjs`), with two different sets of environment variables. Treating them as one thing is the easiest way to get a silent failure.- `jev-mcp`, the MCP server, reads `TYPESAFE_API_KEY` (aliased as `JEV_API_KEY` or `JEV_KEY`) and `JEV_BASE_URL`. It has no documented fail-open behavior or safety threshold; it's a thin wrapper around five typed Jev questions.- `gate.mjs`, the direct code path, is a separate interface with its own variables (`JEV_API_KEY`, `JEV_ENDPOINT`, `JEV_SAFE_THRESHOLD`) and is where the project's documented fail-open behavior actually lives.- Insight: The riskiest failure mode here isn't a wrong Jev answer. It's a correctly-working gate that happens to error at the exact moment a destructive action is proposed, and fails open silently. Read the fail-open behavior before you wire this into anything that touches production.- Jev's direct signup has been paused since September 22, 2026, days after opening to everyone; check current access before you plan around it.- `jevtypesafeai.com` is not TypeSafe. It's an unaffiliated site selling hosted-gateway access that requires prepaid credit, under the same key namespace one community tool defaults to. An official key from `console.typesafe.ai` goes straight to TypeSafe's own `api.typesafe.ai`.
Key Takeaways
- There are two separate Jev-plus-OpenCode paths: the official TypeSafe skill (teaches OpenCode to write Jev integrations) and the community `jev-computer-use` project (gates OpenCode's actions using Jev).
- That community project itself splits in two: an MCP server (`jev-mcp`, configured in `opencode.json`) and a direct code path (`gate.mjs`), with two different sets of environment variables. Treating them as one thing is the easiest way to get a silent failure.
- `jev-mcp`, the MCP server, reads `TYPESAFE_API_KEY` (aliased as `JEV_API_KEY` or `JEV_KEY`) and `JEV_BASE_URL`. It has no documented fail-open behavior or safety threshold; it's a thin wrapper around five typed Jev questions.
- `gate.mjs`, the direct code path, is a separate interface with its own variables (`JEV_API_KEY`, `JEV_ENDPOINT`, `JEV_SAFE_THRESHOLD`) and is where the project's documented fail-open behavior actually lives.
- Insight: The riskiest failure mode here isn't a wrong Jev answer. It's a correctly-working gate that happens to error at the exact moment a destructive action is proposed, and fails open silently. Read the fail-open behavior before you wire this into anything that touches production.
- Jev's direct signup has been paused since September 22, 2026, days after opening to everyone; check current access before you plan around it.
- `jevtypesafeai.com` is not TypeSafe. It's an unaffiliated site selling hosted-gateway access that requires prepaid credit, under the same key namespace one community tool defaults to. An official key from `console.typesafe.ai` goes straight to TypeSafe's own `api.typesafe.ai`.
The official path writes code; the community path gates actions. TypeSafe's own cross-agent installer, `npx skills add typesafe-ai/skills --skill typesafe-ai`, drops in a skill that gives any supported agent, OpenCode included, full context on the Jev API. That's what lets it generate correct integrations for you when you ask it to build a feature. It doesn't gate or judge anything by itself. We covered this exact skill and a full working example, a Jev-powered ticket router, in how to use Jev with Claude Code; the skill itself works the same way in OpenCode.
The second path is a community project, `jev-computer-use` (github.com/codaaiteam/jev-computer-use, MIT licensed), built specifically to gate an agent's actions. Before a shell command runs or a file gets edited, it asks Jev whether the action looks safe and returns a probability and a category. Its own README states plainly that it isn't affiliated with TypeSafe AI, and that Jev is TypeSafe's model, not this project's. It supports Claude Code, Codex, OpenCode, and computer-use agents by name, and it ships two ways to wire it into OpenCode: an MCP server and a direct code path, covered in detail below.
Run the same cross-agent installer TypeSafe documents for any agent: `npx skills add typesafe-ai/skills --skill typesafe-ai`. It prompts you for which agent to install into, OpenCode among them, and installs project-local by default; add `-g` to install globally instead (docs.typesafe.ai/introduction/quickstart). Set `TYPESAFE_API_KEY` as an environment variable once you have a key from console.typesafe.ai. Restart OpenCode, or explicitly ask it to "use the TypeSafe skill" if it doesn't pick it up automatically; TypeSafe's own troubleshooting page names this exact fix (docs.typesafe.ai/agent-skill).
Two genuinely different routes, with two different sets of environment variables. Treating them as interchangeable is where a setup breaks silently.
As an MCP server, since OpenCode reads MCP servers directly from `opencode.json`. The official schema, confirmed against opencode.ai/docs/mcp-servers, puts server entries under a top-level `mcp` key, with a local server needing `type: "local"`, `command` as an array, `enabled: true`, and an `environment` object. A working, commit-pinned configuration for this exact server:
Export `TYPESAFE_API_KEY` before launching, then restart OpenCode; tools are discovered on next launch, and there's no source-confirmed hot-reload, so restarting is the reliable step, not an optional one. Pinning the commit, rather than trusting whatever `main` resolves to when `npx` runs, is what keeps this reproducible later. OpenCode prefixes MCP tools with the server's configured name, so registered as `jev`, this server's five tools appear as `jev_jev_classify`, `jev_jev_score`, `jev_jev_check`, `jev_jev_gate`, and `jev_jev_decide`, the doubled prefix coming from the server name plus each tool's own `jev_` name.
The MCP server itself reads `TYPESAFE_API_KEY` as its primary variable, with `JEV_API_KEY` and `JEV_KEY` accepted as aliases, plus `JEV_BASE_URL` (not `JEV_ENDPOINT`, a different name that belongs to a different tool below) and `JEV_MODEL` (defaulting to `jev-latest`). Its own source doesn't document a fail-open or fail-closed behavior and doesn't expose a safety threshold; it's a thin wrapper around five typed Jev questions, not a policy engine.
As a direct code path, using `gate.mjs` from the broader `jev-computer-use` project (github.com/codaaiteam/jev-computer-use) that this MCP server ships alongside. Since OpenCode supports custom loops, you can call its `gate({action, context})` function directly, bypassing MCP entirely. This is a separate interface with its own variables: `JEV_API_KEY` (a `jv_live_...` key), `JEV_ENDPOINT` (override to call TypeSafe directly instead of the tool's hosted gateway), and `JEV_SAFE_THRESHOLD` (defaults to `0.8`). Don't assume these three apply to the MCP server above; the two paths don't share a configuration surface, even though they live in the same project.
One more distinction worth being exact about: a `jv_live_...` key from the hosted gateway at `jevtypesafeai.com` requires prepaid credit and routes through that unaffiliated third party, not TypeSafe. That site is run by an unaffiliated company (CODEFASHION TECH LTD; its own footer states it is "not affiliated with or endorsed by TypeSafe AI"). An official key from `console.typesafe.ai` goes straight to TypeSafe's own `api.typesafe.ai`. For the MCP server configuration above, use your real TypeSafe key: the server's `JEV_BASE_URL` handling selects the right backend depending on which kind of key you give it, which is one less thing to route manually yourself.
Fail-open means that if the safety check itself breaks, the action it was supposed to evaluate goes through anyway. This is documented specifically for `jev-computer-use`'s `gate.mjs`, not for the plain MCP server. Its README states directly that it "fails open by default (an error in the gate lets the action through so it can't wedge your agent)." That's a reasonable default for keeping an agent from freezing on a network hiccup. It's also a real risk if you don't know it's there: a gate that's supposed to block a destructive command will not block it during exactly the moments it's least available, for example during a timeout, a rate limit, or an outage. The README notes the code can be modified to fail closed instead. If the actions your OpenCode setup can take have real consequences, read that part of the source before you rely on the default, and remember this specific behavior applies to `gate.mjs`, not to the MCP server's own tool calls.
This is the pitfall most likely to cost you a silent failure. Four different configurations exist across paths that all touch Jev. Using the wrong variable for your integration doesn't throw a clear error. It just doesn't work.
If a tutorial or a piece of sample code mixes these up, you'll get a silent failure. The same is true if you copy a snippet written for one path into a project using another; it looks like a missing key rather than a wrong name. Check which exact path you're using before debugging further.
Jev reads text only, no images, audio, or video. The combined state and your longest single question are capped at roughly 32,000 tokens, about 150,000 characters of English (apimaster.ai, 2026-09-21). The default alias `jev-latest` currently resolves to the stable `jev-1.13.0`; pin the exact version in any code you write, since an alias can move out from under you between one session and the next. A `jev-preview` alias also exists for early builds; don't use it for anything you depend on.
Check before you build around it; this changes. TypeSafe opened Jev to everyone on September 20, 2026, then paused new signups on September 22, citing demand, while existing accounts kept working (flaviocopes.com, 2026-09-24). As of this writing that pause is still in effect, with TypeSafe stating it wants to reopen access. This is exactly the kind of detail that goes stale fast: verify current access at console.typesafe.ai before you plan a rollout around it.
Two narrower community tools, beyond the safety gate, also name OpenCode directly. "Oko" is a local MCP code-search tool for Codex, Claude Code, and OpenCode that reranks search results using Jev's Noul judgments. "Foreman" supervises Codex and OpenCode progress checks, but its own listing calls its judgment accuracy "unproven" (both via the awesome-jev list, github.com/AbdelStark/awesome-typesafe-jev, reviewed 2026-09-23); don't treat Foreman as validated just because it exists.
A repeatable test setup for each of the three paths, since "it's configured" and "it actually works" are different claims. For the official skill: ask OpenCode to build something small that uses a Jev typed question, then check the generated code calls the real endpoint (`https://api.typesafe.ai/v1/systemone`) with a `state` and a `questions` object, not a hand-rolled prompt string. If OpenCode invents request or response fields that don't match the real API, TypeSafe's own troubleshooting guidance says that's usually a stale skill; reinstall it.
For the MCP server: run `opencode mcp list` (short form `opencode mcp ls`) to confirm OpenCode actually sees the server and check its connection status, per opencode.ai/docs/cli. If it's missing or shows disconnected, restart OpenCode rather than waiting; there's no source-confirmed hot-reload for a newly added server. Then ask OpenCode to use one of the `jev_jev_*` tools directly and confirm you get a typed answer back, not an error about an unrecognized tool.
For the direct-code gate: trigger a deliberately risky test action (in a sandbox, not production) and confirm you get a probability and category back, then check that a low-safety score actually blocks or confirms rather than silently passing. Test the fail-open path too, on purpose, by pointing `JEV_ENDPOINT` somewhere that will error, so you know what actually happens to an in-flight action when the gate itself breaks.
No. TypeSafe states this directly, naming OpenCode by name: Jev is not a drop-in replacement for the LLM behind it. OpenCode's model still writes every line of code; Jev only answers the specific typed questions your code sends it.
The TypeSafe skill teaches OpenCode to write correct Jev integrations when you ask it to build a feature. It's official, stable, and doesn't gate or judge anything on its own. `jev-mcp` is a separate project, configured as an MCP server in `opencode.json`, that exposes Jev's typed questions as tools OpenCode can call directly. A third option, `jev-computer-use`'s `gate.mjs`, gates OpenCode's own actions outside MCP entirely. All three solve different problems and can be used independently or together.
Check which of the four configurations your setup actually uses. The standard TypeSafe SDK reads `TYPESAFE_API_KEY`; the Vercel AI SDK's `experimental_evaluate` path reads `TYPESAFE_AI_API_KEY` instead; `jev-mcp` reads `TYPESAFE_API_KEY` or the aliases `JEV_API_KEY` and `JEV_KEY`, plus `JEV_BASE_URL`; `jev-computer-use`'s `gate.mjs` reads a differently-formatted `JEV_API_KEY` (`jv_live_...`) plus `JEV_ENDPOINT`. A key issued for one will not work under another's variable name, even when the names look similar.
No. It's an unaffiliated commercial site that sells access to its own hosted gateway, requiring prepaid credit, and its own footer says it isn't affiliated with or endorsed by TypeSafe. The open-source `jev-computer-use` tool that defaults to it is legitimate; the site is a third-party reseller, not TypeSafe. Use `console.typesafe.ai` for an official key, which goes straight to TypeSafe's own `api.typesafe.ai` instead.
Maybe. TypeSafe paused new signups on September 22, 2026, after briefly opening to everyone two days earlier. Existing accounts keep working. Check console.typesafe.ai directly for current status before you commit to a rollout timeline.
For the full walkthrough of the official TypeSafe skill, including building a real feature with it, see how to use Jev with Claude Code. If you're specifically weighing Jev-based versus native approaches to a Claude Code problem rather than an OpenCode one, see do you need fast-jev-compaction, or is /compact enough. That covers the same kind of official-versus-community comparison, applied to context management instead of safety gating.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.