Jev for SEO, GEO and Google Ads: What TypeSafe's System One Model Is Good For, and What Code Still Decides

What jev-seo learned about its own inputs

When the developer of jev-seo, an open source audit tool built on TypeSafe's new Jev model, first asked it whether each page "opens with the point", Jev and a blind second judge agreed on 15 of 30 pages. The fix had nothing to do with the model: the page text being sent began with breadcrumbs and navigation, so "the first sentences" were never the page's real opening. Once code passed only the text after the H1, agreement rose to 28 of 30, and Jev was decisive on 23 pages instead of 6, according to the project's evaluation notes dated 22 September.

That small fix is a fair summary of what Jev is for. TypeSafe AI announced Jev on 15 September as a model that returns decisions instead of text: you define the possible answers, it picks one and says how sure it is, quickly and very cheaply. For SEO, AI search visibility and Google Ads work, that makes it a triage layer for the jobs that today mean a person skimming a spreadsheet.

The argument here is that its usefulness depends almost entirely on the code around it. Code decides what Jev reads, asks it only the questions code cannot answer, and handles everything with a right answer: counting, dates, spend thresholds, what a negative keyword blocks. TypeSafe's own documentation says most of this.

What TypeSafe shipped

TypeSafe, whose announcement is signed by founder Diogo Almeida, calls Jev the first "System One" model, borrowing Kahneman's split between fast, intuitive thinking and slow, deliberate reasoning. A chat model writes an answer token by token. Jev takes what its docs call state (text, a JSON object or an array of text values) plus questions whose possible answers are fixed in advance, and returns what the company describes as "typed probabilistic decisions".

The documentation defines three primitives. A Choice picks one option from a list. A Score rates the state on a rubric of ordered levels. A Noul gives the probability that a statement is true. Choice and Score answers come with the full probability distribution and a single confidence value between 0 and 1.

TypeSafe prices input at $0.042 per million tokens and calls output "too cheap to meter". Its models page lists the current version as jev-1.13.0, with 64,000 tokens per request, 32,000 of them for the state plus the longest question, and rate limits of 250,000 tokens per second and 1,200 requests per minute. Input is text only; there is no image, audio or video input. English gets the best accuracy, and other languages "are handled but not equally well", which matters for anyone running multilingual accounts. Choices top out at 255 options; above that, TypeSafe scores candidates separately and then chooses. At launch the company was bringing developers off a waitlist into early access, and its homepage still describes Jev as early access.

The launch post says Jev "never makes type errors" and "can't hallucinate". Read those narrowly. Because the answers are fixed in advance, Jev cannot return a label outside your schema or invent a field. It can still pick the wrong label. The post concedes that its 0% figure is "not empirical": it follows from schema matching being guaranteed, not from counting wrong answers.

What TypeSafe means by calibrated

In statistics, a calibrated model is right 80% of the time when it says 80%. TypeSafe's claim is more modest. The launch post defines it as: "Calibrated: higher confidence means higher accuracy." That is a promise about ordering, that confident answers are more often right than unsure ones, and not a promise that 0.8 means 80%.

The confidence documentation explains why. The confidence value summarizes the shape of the probability distribution: "All of it on one option gives 1.0; the more evenly it spreads, the lower the confidence." It measures how concentrated the model's answer is. How that maps to accuracy on your search terms is something you find out. TypeSafe suggests starting bands (above 0.9 act automatically, 0.5 to 0.9 verify, below 0.5 send to a person) and says plainly that "the correct threshold values depend on your domain and the performance of the model for your use case." It also says destructive actions should need higher confidence than read-only ones in the same system.

One of TypeSafe's own cookbooks shows the pattern worth copying. Classifying 60 company filings by industry, it split answers at 0.9 confidence: "The confident half is right 90% of the time; the other half, 40%. Reported one level up, that 40% becomes 70%." The unsure answers were not thrown away. They were reported at a coarser level of the taxonomy. The search version is obvious. When Jev is unsure whether a query is transactional or commercial, report it as commercial intent and move on, instead of forcing a fine label nobody should act on.

What Jev's documentation says not to ask it

TypeSafe publishes a page of known weaknesses for jev-1.13, which is more than most model vendors do. Nearly every item on it is a job that search teams are tempted to hand to a model, and each one belongs in code.

"Jev is not a calculator." The page says it "recognizes the shape of an answer rather than tallying", and that the error grows with the size of what is being counted. Its advice is to count in code and ask one question per candidate. So never ask Jev whether a search term has spent more than $50, whether a page mentions a phrase three times, or which of two pages has more clicks. A script answers those exactly.

It "reads dates as text, not as ordered quantities." Whether a page was updated in the last year, or whether a conversion fell inside a test window, is a date comparison. Do it in code and pass Jev the result, if it needs it at all.

"Accuracy falls as the state grows with content unrelated to the decision." Sending raw HTML, with navigation, footers and cookie banners, is the jev-seo breadcrumb problem in general form. Extract the part of the page the question is about.

Content "written to adversarially steer the model" can move the answer. In search that is not an edge case. Landing pages, competitor pages and the AI answers you sample are all written to persuade, and some are written to be classified a particular way. A "trustworthy" score on a page whose copy insists it is trustworthy deserves a person's look.

And it does not write. No titles, meta descriptions, content or ad copy. A route that needs a sentence goes to a language model.

One more limit, which is not in TypeSafe's list because it is not about the model: Jev cannot measure AI visibility. Whether assistants name a brand is measured by asking the assistants the same questions many times and counting, with a margin of error. Jev can judge each sampled answer. The sampling and the rate are separate work; see how to measure AI search visibility.

Search and Ads jobs that fit

The jobs that suit Jev share a shape: the answer is one of a known set, there are hundreds or thousands of rows, and code has already done the part with a right answer. TypeSafe's own use-case map lists classification, detection and verification, including "citation support", among its intended uses. In search work the code step comes first.

Take the first row in a sample account, say the hypothetical Toronto employment law firm Harbour & Finch. The search terms export has 4,000 rows. Code removes the totals, computes cost and conversions per term, and keeps the 600 terms that spent enough to judge. Jev labels those 600. The terms it calls job seeker searches with high confidence ("employment lawyer jobs toronto") become proposed negatives. Code then tests each proposal against every term in the export, including the ones that converted, because Google's Ads Help documentation is specific about how negatives match: they do not match close variants, a negative broad match blocks searches containing all its words in any order, and a negative phrase match blocks them in that order. A person reviews the list and uploads it. Jev made one decision per row, and made none of the others.

How jev-seo splits the work

jev-seo is the most complete public example of Jev in search so far, and its documentation is unusually frank. From a homepage URL it crawls the site, runs 52 rules tied to Google Search Central, measures Core Web Vitals through the PageSpeed Insights API, and asks Jev 13 questions per page and 5 per site. It writes a PDF, an Excel action tracker and a Markdown report, and runs as a Claude Code skill or from the command line. It is MIT licensed.

Its judgment registry reads like a set of rules for keeping a model in its lane. "Code never asks what it can see": a page with no meta description gets no question about whether its meta description fits. Every Choice includes an "other" or "unclear" option, so Jev is never forced to pick a wrong label. Page text is capped at 6,000 characters and the truncation is flagged. A Choice counts as decisive at confidence 0.80 or above; anything below is marked "to verify". For cannibalization, code shortlists page pairs whose title and H1 words overlap, and only then asks Jev whether a searcher would treat the two as substitutes. And after Jev twice suggested removing substantial posts, code now blocks any removal verdict on pages of 600 words or more. That rule is the author's guardrail, not a claim about rankings, and it leaves the final say with code.

The costs are as small as TypeSafe's pricing implies. The registry records one observed run of 14 requests and 47,181 input tokens costing $0.0020, or about 3,400 input tokens per page. The README estimates about a cent per site in standard mode and about $0.30 more with the optional DataForSEO data, with hard budget caps (by default $0.25 for Jev and $1.00 for DataForSEO) checked before every request. Large sites are sampled at 60 pages by default.

The evaluation file is the part to read before relying on any of it. Run twice on the same 59 pages, Jev gave the same page type 58 times and the same intent 59 times. Against a blind second judge on 30 pages and 40 keywords, it agreed on 29 of 30 helpfulness calls, and page type agreement rose from 20 of 30 to 27 of 30 after a wording change. But the second judge was another model instance, and the file says so: "This is agreement with a second judge, not accuracy: there is no human-labelled answer key yet." The README adds that Jev thresholds "are not yet tuned against human labels", and that rules marked heuristic "are editorial conventions, not search engine requirements." The author recommends labeling about 100 items per judgment family before treating Jev findings as more than prioritized signals for review. Treat the tool's "citable" score, a rubric for self-contained quotable facts, the same way. It is a reasonable editorial check, and nobody has shown that it predicts which pages AI assistants cite.

Test the confidence on your own rows

Whether Jev works on your accounts takes an afternoon to find out.

1. Take 200 to 300 real rows from one client: search terms, pages or queries.
2. Label them yourself. If two people label, keep the rows they agree on, and note the ones they don't: rows humans disagree about should never be routed automatically.
3. Run Jev on the same rows with the same answer set, including an "unclear" option.
4. Group its answers by confidence: below 0.5, 0.5 to 0.8, 0.8 to 0.9, above 0.9.
5. In each group, count how often Jev matched your label.

If the top group matches you 95% of the time, route it automatically for reversible actions, such as tagging a page for review, and keep a higher bar for irreversible ones like adding a negative keyword. If it matches 80% of the time, the scores run optimistic on your data and the threshold moves up. Watch the group sizes. With 50 rows in a group, the 95% margin of error on its accuracy is about 8 points either way if the true rate is 90%, and about 11 points if it is 80%. Small groups give you a direction, not a verdict.

The model calls for this test cost almost nothing. At roughly 500 tokens of state and question per row, 200 rows is about 100,000 input tokens, well under a cent at TypeSafe's list price. The labels are the expensive part, and they are the only part that tells you what 0.9 means for your client.

Where it sits in a stack

Put together, code parses the Search Console and Ads exports, computes every figure, and builds the state each question needs. Jev labels each row and says how sure it is. A language model such as Claude Opus 5.5 drafts the fix or the explanation for the rows that matter. A person reviews and applies. Afterwards, the change is measured against a control group of pages that were left alone.

AIO Copilot is built on the same split: code does the arithmetic and shows its working, and nothing reaches a client account until someone presses apply. The free Ads leak check covers the negative keyword step on a search terms export without touching the account. The app runs the whole method every week; get started and we email pricing and the setup steps.

If you try Jev this month, start where jev-seo's author ended up: label 100 rows of one judgment by hand before trusting the rest. At these prices the model will never be the costly part of the pipeline. The costly part is a confident wrong label that nobody checked, sent straight into a client's account.

Frequently Asked Questions