Jev doesn't talk the way you'd expect an AI model to. Ask it to price a Polymarket contract, and it won't explain its reasoning, hedge its answer, or write you a paragraph justifying the number. It simply hands back a typed probability in about a tenth of a second, for a fraction of a cent. That's the entire pitch behind the Jev AI Polymarket bots that have started showing up in developer repos this fall, and it makes for a genuinely different kind of tool than the chat models most traders reach for first.
This piece walks through what Jev actually is, why it isn't a smaller version of ChatGPT, how a real Polymarket bot built around it actually runs day-to-day, and where it quietly falls apart if you end up trusting it more than you should.
What Is Jev AI?
Jev is TypeSafe AI's "System One" decision model, the first release in a product line built specifically to skip text generation entirely. You send it a typed state object along with a set of typed questions, and rather than writing anything back, it returns calibrated probabilities or a discrete decision like buy_yes, buy_no, or hold. There's no chain of thought to read and no prose to parse through afterwards.
TypeSafe trained it using a method they call Reinforcement Learning for Calibrated Decisions, or RLCD, and their own framing of the model is worth quoting directly: think of Jev as a frontier-intelligence function call, unstructured state in, typed probabilistic decisions out (Source: typesafe.ai). That's the one comparison worth carrying through the rest of this article, since it captures the whole design philosophy in a single image. It behaves like a function call rather than a conversation.
Access runs through OpenRouter's Decisions API, a separate alpha endpoint from the platform's usual chat completion route, currently listed under the model name typesafe/jev-1.13. Pricing sits at $0.042 per million input tokens with free output, inside a 32,000-token context window, and the model went live on OpenRouter on September 18, 2026, three days after TypeSafe's own public launch (Source: openrouter.ai/typesafe/jev-1.13). It's genuinely cheap to run, and fast enough that latency stops being the real constraint inside a trading loop, which is the same priority that pushes serious algorithmic traders on the Kalshi side toward a direct FIX 4.4 connection instead of a standard REST API.
Why Jev Isn't Like Asking ChatGPT or Claude to Price a Market
Here's the distinction that actually matters, and it's an easy one to miss if you're used to thinking of every AI model as some version of a chatbot. A generative model reasons out loud, in text, token by token, and you're meant to read that reasoning to decide whether you trust its conclusion. Jev skips that step entirely. It's optimized purely for structured output, and because it was never built to produce prose in the first place, TypeSafe's own description notes it simply can't hallucinate a paragraph the way a language model might.
That trade-off cuts in both directions at once. You lose all visibility into why Jev landed on 34% instead of 40%, since there's no reasoning trail to inspect. What you gain in exchange is speed and cost low enough to call the model dozens or even hundreds of times a minute, something a reasoning-heavy chat model simply can't do gracefully at that scale. If you're still weighing which model actually fits into a Polymarket trading pipeline, and Jev clearly isn't the right fit for every part of one, a broader comparison of AI models built specifically for Polymarket trading is worth reading before you commit to one architecture over another.
The other hard limit sits right alongside that first one: Jev has no web browsing and works from a fixed training cutoff. Ask it to price a market that hinges on this morning's headline and, on its own, it will correctly refuse, simply because it has no way of knowing what happened an hour ago.
How a Jev-Powered Polymarket Bot Actually Works
Every serious implementation ends up converging on roughly the same shape, largely because that browsing limitation forces it there. One real, public example, a bot called jevymarket, documents its own pipeline plainly as a sequence: scan, research, state, Jev, evaluate, execute, log (Source: github.com/markusbug/jevymarket). That overall shape is worth comparing against how developers build trading bots on the Kalshi side, since both platforms are ultimately solving the same problem: getting a model's judgment safely into an execution loop, even though the underlying infrastructure looks fairly different between the two.
- Scan. The bot pulls live order book and market data off Polymarket's Gamma API, the same interface that returns a market's outcome token IDs alongside its current pricing.
- Research. Because Jev can't browse on its own, a separate and cheaper generative model handles that job first, searching the web and writing a dated, sourced evidence brief directly into the state object. The jev market project defaults to DeepSeek for this step, though several other models have been tested as alternatives, and it falls back to OpenRouter's Exa search tool at roughly $0.007 per search whenever a model has no native browsing capability of its own.
- State. Everything gets assembled into one structured object, combining the evidence brief with the market's current data, before being handed off to Jev.
- Decide. Jev returns a calibrated probability, quickly, cheaply, and in the typed format the rest of the pipeline expects.
- Evaluate. Deterministic code, not the model itself, compares that probability against the live order book price, and the bot only considers trading once Jev's number beats the market by a configured edge threshold.
- Execute and log. Orders go out as resting limit orders, sized through something like a Kelly-based rule, with every decision written to a local database afterwards for review.
Cost stays genuinely small across the whole sequence. One documented run puts a single Jev decision, evidence included, at roughly $0.00006, the research brief itself at one to two cents, and a full twenty-market pass at somewhere between twenty and forty cents total before caching kicks in (Source: github.com/markusbug/jevymarket). For anyone who's already priced out running a full reasoning model across dozens of markets repeatedly, that gap in cost is really the whole reason this architecture exists at all.
Not every Jev-based project even places trades, either. A separate scanner called polymarket-jev uses the exact same underlying model purely to flag markets where a published fact has already satisfied a market's written resolution rules while the price hasn't caught up yet, and it ships explicitly alert-only, with no wallet, no signing code, and no order path anywhere in the repository (Source: github.com/swang666/polymarket-jev). It's worth keeping in mind that "built on Jev" doesn't automatically mean a project trades your money.
If you're assembling something like this yourself rather than starting from an existing repo, a working collection of free GitHub repos built for Polymarket trading is worth a look before you build the scan-and-execute loop from scratch.How much could your Polymarket position pay? Use the calculator to see your estimated payout, net profit, fees, and return percentage before putting money on the trade.Calculate your Polymarket payout for free →
The Real Limits Worth Knowing
The no-browsing constraint is the obvious limit, and it's the one every implementation already designs around. A less obvious one showed up directly during testing, and it's worth taking seriously rather than glossing over as a footnote.
That same resolution-lag scanner ran Jev against nineteen live markets and turned up something fairly specific: the model's probabilities came back less than half as spread out as the order book's own pricing, with every market in its largest category landing within 0.13 of that category's 0.35 base rate (Source: github.com/swang666/polymarket-jev). In plain terms, Jev's forecasts kept collapsing back toward an average value rather than committing to confident, differentiated answers, which means what looked like genuine "edge" against the market was often just the gap between that base rate and whatever the market happened to be pricing at the time, not real insight into the specific question being asked.
It gets stranger still on multi-outcome markets. Two mutually exclusive outcomes inside the same negative-risk event, which should sum to 1.00 on the order book, ended up losing 0.31 of probability mass once Jev scored them separately. In one run, a conjunction like "party wins Senate and House" actually scored higher than one of its own individual components, which is logically impossible on its face. TypeSafe's own documentation reportedly states plainly that logically related questions aren't guaranteed to cohere with one another, and that gap is really a structural reminder that Jev answers each question independently, with no built-in check ensuring the answers actually make sense side by side.
One more distinction worth holding onto, since some implementations preserve it carefully and others quietly blur it: Jev's typed output scores aren't the same thing as calibrated win rates you can trade directly against. A separate production integration keeps the final trading decision and every risk gate inside deterministic code rather than the model itself, treating Jev's number as one signal among several rather than as an instruction to execute (Source: github.com/Team-Win-and-Make-Monney/polymarket-arb-scanner). That separation between a signal and an actual decision is easy to flatten in a quick prototype, and it's exactly the kind of shortcut worth resisting.
This Is Experimental, Real-Money Software
Every repo covered here carries some version of the same warning, and none of it reads like boilerplate once you've seen how young this whole model is. This is software capable of placing real orders against real capital, built on top of a model that's only weeks old at the time of writing.
Several projects have defaulted to paper trading or simulation mode, requiring an explicit override flag before anything ever touches a live account, a guardrail worth keeping in place even after a strategy has already tested well. One production integration goes further still, running a capped "canary" live mode that requires a separate acknowledgement flag before it will place a single real order (Source: github.com/Team-Win-and-Make-Monney/polymarket-arb-scanner). If a project you're evaluating skips that kind of safeguard entirely, that's worth noticing before you look at anything else about it.
Jev's use extends well past Polymarket, too. A live BTC price-feed bot running on Monad's Kuru exchange, built by Monad's own lead AI engineer, posts resting limit orders roughly every 300 milliseconds based on Jev's buy or sell signal, which suggests this pattern is spreading into crypto trading more broadly rather than staying contained to prediction markets specifically. Separately, LangChain has documented using Jev as a risk-gating layer inside agent middleware, checking a tool call for risk before it's allowed to execute rather than pricing any market at all, a use case with nothing to do with trading whatsoever.
Bottom Line
Jev is fast, cheap, and genuinely useful as one component inside a larger pipeline, but it was never meant to function as a standalone oracle you point at a market and trust blindly. Pair it with a real research step for anything news-sensitive, keep the actual trading decision inside code you control, and treat its output as a calibrated opinion rather than ground truth, particularly on multi-outcome markets where its answers won't always add up to something logically coherent. If you're weighing this approach against building something manually instead, the trade-off between running an automated edge-detection loop and doing that comparison yourself through manual arbitrage is worth thinking through before you write a single line of code.
Frequently Asked Questions
What is Jev AI?
Jev is TypeSafe AI's structured decision model, the first release in their System One line, built to return fast, typed probabilities or discrete decisions instead of generated text. It's accessed through OpenRouter's Decisions API and is increasingly used as the pricing component inside Polymarket trading bots.
Is Jev AI a chat model like ChatGPT or Claude?
No. Jev never generates prose or reasoning text of any kind. It accepts a typed state along with typed questions and returns a typed probability or decision directly, which is a structural difference from a chat model rather than simply a stylistic one.
Can Jev AI access live news or current events on its own?
No. Jev has no web browsing and works from a fixed training cutoff, so on its own it correctly refuses to price markets that depend on breaking news. Working implementations get around this by pairing it with a separate research step, typically a generative model with web search, that feeds Jev a sourced evidence brief before it makes any probability call.
Is using Jev AI for Polymarket trading risky?
Yes, and every serious implementation treats it that way. This is experimental software capable of placing real orders with real capital, and testing has already turned up real issues, including probabilities that collapse toward a base rate and multi-outcome scores that don't logically add up. Most serious projects default to paper trading and require an explicit flag before live orders are ever enabled
