ViralMojo
Jev × marketing

We mapped Jev against a real marketing workflow. Here's what we found.

By Denzel Geng · Updated September 2026

Most of the discussion around Jev is how fast and how cheap it is. That's the wrong frame. Jev isn't competing with GPT or Claude on general intelligence — it's built for the judgment calls an expert makes in seconds but that need to happen thousands of times. We mapped it against three workflows in our own product, found one place it exposes a real methodological conflict, and learned why "193.6x faster" isn't a number you should repeat.

Jev is TypeSafe AI's decision model, launched September 15, 2026: instead of generating text token by token like GPT or Claude, it takes a state (text, JSON, an array) plus predefined typed questions and returns schema-constrained probabilistic judgments in a single forward pass. It's built for high-volume closed judgments — screening, classification, scoring — not for retrieval, tool use, or open-ended reasoning.

See what an agent does with your nicheSee what an agent does with your niche
The frame

This isn't another faster model

Jev is designed for a different kind of work than a general language model: the judgment calls that experts make in a few seconds, but that need to happen thousands of times. Is this hook the same concept we already tested, just dressed differently? Is this customer comment a meaningful signal or a passing mention? Does the source actually support the claim in this brief? Is this ad worth iterating on?

Today you generally have two options for those judgments: review everything manually, which doesn't scale, or ask a full language model to make every small call, which is expensive and capped by context budgets. Jev is designed to sit between those extremes.

For a marketing workflow, that could change three things: research could screen more of the available evidence instead of being capped by what one reasoning pass can examine; grounding checks could run on every revision instead of being saved for the final draft; and performance analysis could evaluate every ad in an account before a more expensive model explains what matters. The real question isn't whether Jev is fast — it's whether you can identify the judgments that don't need a full model, and move them to a cheaper layer without giving up accuracy or decision authority.

The mechanics

What Jev actually is

TypeSafe AI launched Jev on September 15, 2026. Founder Diogo Almeida is a former OpenAI researcher who worked on InstructGPT and RLHF; the company spent two years in stealth and launched with a $40M seed led by DCVC. The name references Jevons' paradox — efficiency increasing total consumption — which tells you the goal: not fewer judgments, but making many more of them practical. You provide a state and predefined questions of three types:

Question typeWhat it doesWhat you get back
NoulA yes/no questionThe probability the answer is yes
ChoiceSelects one option from a defined set (up to 255)The selected option, probabilities across options, and a confidence value
ScorePlaces something on an ordered 2–10 level scaleA value that can fall between levels, with probabilities and confidence

Output is schema-constrained — TypeSafe claims zero type errors. But note their own documentation's qualification: calibration doesn't mean correctness. A highly confident answer can still be wrong. That distinction matters throughout this page.

The numbers

The official numbers don't hold up on their own

TypeSafe's homepage says 193.6x faster, 444.6x cheaper — from the company's own benchmark, whose footnote admits it's likely the high end. One analysis noted the same page shows a separate latency comparison of 0.114s vs 8.566s (~75x) without clarifying whether it measures the same workload. Independent tests paint a more moderate — and more useful — picture:

TesterReported resultAccuracy / key finding
Near Here~5x faster, ~8.6x cheaperJev 96% vs Mistral Small 4 at 84%, Gemini 3.5 Flash-Lite at 86%
Good Start Labs~1.6x cost advantage91.5% agreement with Claude Fable 5.1
Every25x–580x cost advantage depending on comparisonMissed 1 of 12 planted defects that Fable 5.1 caught — the one requiring cross-document inference

The conclusion isn't that Jev is useless. The gains appear real in some workloads — but not necessarily near the headline numbers, and accuracy depends heavily on how the judgment is formulated. Which makes question design the real work.

The craft

Designing the questions is the actual work

A cheap judgment is only useful if the question is structured correctly. Four principles from published tests and our own design work:

    Try the free baseline first

    If a regex, exact match, or embedding-similarity check solves the problem, don't use Jev. One published test showed a character-level baseline matching a carefully designed Jev setup on a weak-signal task. Not every judgment needs a model.

    Don't overload the options

    A Choice with too many options can hurt accuracy — one test found a 12-option Choice dropped to 40%, interpreted as a format problem rather than a comprehension problem. Keep option counts tight and include an "other / none of the above" escape hatch.

    Only decompose genuinely independent questions

    Splitting one judgment into several questions helps only when they're actually independent. "Does the text mention a technique?" and "is the person using that technique?" overlap — splitting them can amplify false positives. One test found a 25x difference between related formulations. Decomposition must reflect the structure of the judgment.

    Keep retrieval and judgment separate

    Jev can't search a workspace or make tool calls across turns. The retrieve-then-judge pattern is the boundary: a tool-using model finds the evidence; the judgment layer decides what the evidence means.

The mapping

Three places a decision layer could change a marketing product

We mapped Jev against three of ViralMojo's own workflows. The most interesting finding wasn't a cost saving — it was a conflict between our research methodology and our retrieval pipeline that the exercise exposed.

1 · Customer research: from sampling to screening

Our Reddit research funnel produces hundreds of candidate posts, but a hard context cap keeps only 30 index rows — selected substantially by upvotes — of which the agent opens 2–3. The conflict: our methodology says evidence type beats quantity (a first-person switching story beats a viral bare mention), but the cap fires before those rules can be applied. Popularity gates evidence before quality is ever judged. A cheap triage layer — six independent Noul questions per post (promotional? first-person? quantified? comparative?) plus a specificity Score — would let quality-ranked candidates compete for the same 30 slots. Same context budget, different survivors.

2 · Grounding checks: from a final gate to an anytime check

Our draft grounding review runs two independent reviewer subagents — up to 12 model calls per full review, each reloading prompts, workspace anchor, draft, and claims. The economics push teams to run it once, near the end. But once a passage has been retrieved, the judgment is closed: does this passage support the claim? Contradict it? Two Nouls plus a small Choice for the failure reason (numbers don't match / misattributed / exaggerated / not found). Retrieval stays with the full model; the repeated verification becomes cheap enough to run while you write instead of after.

3 · Ad performance: from sampled highlights to full-account visibility

Analyzing 118 live ads means six paged tool calls, ~120 rows held in context, and a 25-turn / 16k-token budget shared with the final explanation — so agents sample. The bottleneck is context, not billing. Each ad can instead be judged outside the conversation: convert raw metrics to account-specific historical percentiles in code, then a four-option Choice (kill / iterate / keep / scale) plus an independent fatigue Score — fatigue is a trajectory judgment, not a snapshot. The expensive model then spends its context on diagnosis, patterns, and what deserves the marketer's attention.

The pattern

The same constraint, three different disguises

In each case the temptation is to blame the model — it doesn't find enough evidence, checks grounding too late, analyzes only a subset. The underlying pattern is more specific: one full reasoning process is being asked to retrieve, load context, filter, make repeated small judgments, and explain — all at once. That makes the expensive model the bottleneck at every stage.

WorkflowCurrent constraintWhat's actually limited
Customer researchA hard 30-candidate context capHow many candidates ever enter the model's attention
Grounding reviewFull review cost per revisionHow often verification can run during writing
Ad performancePaged reads + turn/token budgetsHow much account-wide data fits one conversation

A decision layer separates the stages: structured judgments at scale underneath, the full model's limited attention reserved for retrieval, interpretation, and explanation.

Honesty

None of this is in production yet

All three designs are on paper. We don't have API access and haven't run comparisons against production data; the numbers above come from other teams' published evaluations on workloads that aren't ours. We also haven't validated that our proposed questions hold the accuracy our workflows require — and a cheap incorrect filter can be worse than an expensive incomplete one. A false negative in research triage deletes a first-person story before the main model ever sees it; a bad support judgment lets a misleading claim through; a bad classification distorts which ads get attention. Baselines, test sets, and error analysis come before any of this becomes product behavior.

The point of the exercise wasn't to prove Jev solves these problems. It was to find out where the problems actually come from.

The boundary

Where the judgment layer ends and yours begins

Jev cannot retrieve information on its own — no memory between calls, no tool loop — so the retrieval half of retrieve-then-judge still needs a model that can search, read, and navigate. And it's not a replacement for contextual reasoning: the one defect it missed in Every's test required inference across documents, and TypeSafe's own docs concede calibration doesn't mean correctness.

The useful boundary is narrower: when the evidence is already beside the question and the question is closed — is this post promotional? does this passage support this claim? which of four categories fits this ad? — a structured judgment layer may be enough. Those judgments don't need the same model that does the retrieving, interpreting, and explaining.

That's the layer we want to explore at ViralMojo. Not taking research, checking, or diagnosis away from marketers, and not letting a system decide silently — making the filter underneath the expensive reasoning cheap enough that the same budget buys more complete evidence, more frequent verification, and a fuller view of the account. The machine does the digging. You bring the judgment.

FAQ

Common questions.

Jev is a decision model from TypeSafe AI, launched September 15, 2026 by former OpenAI researcher Diogo Almeida with a $40M seed round led by DCVC. Unlike GPT or Claude, it doesn't generate text — it takes a state plus predefined typed questions (yes/no, multiple choice, or scored scale) and returns schema-constrained probabilistic judgments in a single forward pass. It's built for high-volume closed judgments like screening, classification, and scoring.

Those are TypeSafe's own benchmark numbers, and their footnote concedes they're likely the high end. Independent tests report more moderate gains: roughly 5x faster and 8.6x cheaper in one evaluation, a ~1.6x cost advantage in another, and 25x–580x depending on the comparison in a third. Speed and cost gains appear real in some workloads — just not reliably near the headline, and accuracy depends heavily on question design.

No — it's a complement, not a replacement. Jev has no memory between calls and no tool use, so anything involving retrieval, navigation, multi-step reasoning, or explanation still needs a full language model. The pattern that works is retrieve-then-judge: the language model finds and reads the evidence; Jev makes the high-volume closed judgments on it. One independent test also showed it missing a defect that required inference across documents — contextual reasoning stays with the bigger model.

Closed, high-volume judgments where the evidence is already in hand: triaging customer posts (promotional? first-person? specific?), checking whether a retrieved passage supports a claim in a brief, classifying every ad in an account as kill/iterate/keep/scale against the account's own baselines, and scoring evidence specificity or fatigue trajectories. Tasks that involve finding the evidence, weighing tradeoffs, or explaining a decision don't fit.

No. Try the free baseline first — if a regex, exact match, or embedding similarity solves it, a model call is waste; one published test showed a character-level baseline matching a tuned Jev setup. And question design carries the accuracy: overloaded option lists degraded to 40% in one test, and badly decomposed questions amplified false positives by up to 25x between formulations. A cheap wrong filter is worse than an expensive incomplete one.

The machine does the digging. You bring the judgment.

The interesting question isn't which model is fastest. It's which judgments your research pipeline is silently skipping.

ViralMojo runs the whole loop — customer voice, competitors' live ads, organic winners — decoded into angles and briefs. The machine does the digging; you bring the judgment.

  • Customer-voice evidence ranked by quality and independence, not upvotes
  • Competitors' surviving ads decoded — hook, mechanism, proof, persona
  • Research → angle → brief in one continuous context, cold from your URL
  • No ad-account connection or spend history required
Put an agent on your nichePut an agent on your niche

Plans from $79/mo, flat — see ViralMojo pricing.