Jev for GTM: What It Does, Where It Fits, and What We Measured

Jev makes narrow decisions from supplied evidence. It cannot write your outreach, but it can choose a campaign, assess whether a source supports a claim, or score an account against a rubric. TypeSafe launched it on September 15, 2026, at $0.042 per million input tokens with free output. That makes repeated checks inexpensive enough to consider throughout a GTM workflow. (Launch, model specifications)

This guide separates documented capabilities from proposed uses and includes our lead-scoring test. Low cost and fast responses came with a consequential problem: missed candidates. The workflow starts with stacking evidence before scoring.

Key Takeaways

• Jev returns bounded decisions from text. Your code owns the resulting actions.
• Its strongest GTM opportunity is checking more evidence per account, including facts, claims, and routing choices.
• In our 83-contact test, Jev cost $0.0055, but recalled only 60% and 44% of the reference sends for two brands.
• Browser infrastructure, enrichment, and review can outweigh inference cost.
• Start with one workflow, labelled examples, and a held-out test before allowing automatic decisions.

What does Jev actually do?

You send Jev a state, meaning text or structured text, and narrowly defined questions. It returns choices, probabilities, or rubric scores. Questions within one request are independent. Dependencies need a subsequent call or code. (Introduction)

Three decision primitives

The Choice, Noul, and Score references define these outputs. A Score result is not automatically a probability of purchase. Choice and Score confidence describe the answer distribution; they do not certify correctness. (Confidence)

This illustrative request uses invented evidence:

{
  "model": "jev-1.13.0",
  "state": {"excerpt": "Connect our CRM to campaign tools."},
  "questions": {
    "explicit_need": {"type": "noul", "instructions": "Does the excerpt explicitly assign CRM integration work?"},
    "support": {"type": "score", "instructions": "Rate support for integration work.", "criteria": ["Absent", "Implied", "Explicit"]},
    "offer": {"type": "choice", "instructions": "Choose a supported offer without inferring buying intent.", "criteria": {"integration": "Integration audit", "content": "Content production", "none": "Neither is supported"}}
  }
}

The request shape follows the API reference. Question IDs are bookkeeping keys; put the meaning in the instructions and criteria.

Specifications that affect implementation

The model page, checked September 19, lists jev-1.13.0, text-only input, and no customer fine-tuning. State plus all questions must fit within 64,000 tokens; state plus the longest question must fit within 32,000. The 1,200 requests-per-minute limit may change. Evaluate non-English languages separately.

Pin the model version and keep evidence compact. The provider documents weaknesses in arithmetic, dates, irrelevant context, and adversarial text. Compute counts and dates in code; never let a downloaded page grant execution permissions. (Failure modes)

Jev can also select a value that a parser already found. For an email, URL, or evidence span, supply candidates and copy the selected value verbatim. This preserves its source, although selecting the wrong candidate remains possible. (Value extraction cookbook)

What did launch week actually show?

The useful launch-week evidence concerns implementation and measurement boundaries. The reviewed sources do not establish a lift in replies, qualified meetings, or pipeline. A demonstration is a starting point for testing.

The practical question is whether your options already exist. Campaign IDs, enrichment providers, parsed evidence spans, and observed browser controls are natural candidates. If each decision first needs a generative model to invent its options, include that work in the comparison. Repeated planning may erase the benefit.

Treat every cheap-task claim as an accounting question. Does it include preparation, helper models, browser startup, failed attempts, and checking the result? The browser example below illustrates the difference.

A selected category can be wrong while matching the schema. Confidence needs validation on your task; useful behavior on one distribution does not establish calibration elsewhere.

We tested the separate question of applying our sales rules.

We ran it on our own lead-scoring data

Jev achieved 77% agreement with our reference decision for a design-subscription brand and 76% for an AI marketing tool. Across all 83 contacts, inference cost $0.0055 and median latency was 0.95 seconds per request. Its send recall was 60% and 44%, respectively: it missed many reference sends. (Benchmark methods and aggregate results)

We scored both brands for each contact, using three bands: send, maybe, and no. The reference labels came from three blind model-agent labellers, followed by adjudication, not human ground truth. The sample deliberately emphasized band boundaries. Each short-prompt arm received the same approximately 150-word brief, one call per contact and four concurrent calls. Generative arms used temperature zero with reasoning at provider defaults. Jev used its typed questions and probability-based band selection, as detailed in the appendix.

The table shows design-subscription results. Costs cover 83 rows. The six generative comparators are deepseek-v4-flash, deepseek-v4.1-flash, qwen3.8-flash, mercury-2.5, gpt-5.6-luna and glm-5.3-flash. These are the requested model identifiers retained in the run provenance; the saved provider receipts do not establish immutable backend revisions.

Band agreement means matching the reference send, maybe or no label. Send precision is the share of predicted sends that the reference also marked send; recall is the share of reference sends recovered. A send/no flip skips the middle band.

The named results show different trade-offs. Qwen3.8 Flash matched Jev’s 77% Brand A band agreement but recovered 80% of reference sends, with 92% send precision and no send/no flips. Jev recovered 60%, with 82% precision and six flips. DeepSeek V4.1 Flash reached 81% band agreement and 80% send recall, at a higher recorded cost and latency. These are observations on this sample, not evidence that either model will win on another task. The appendix also reports full-prompt arms and the separate GPT-5.6 Sol batch run.

Chart key: A — DeepSeek V4 Flash; B — DeepSeek V4.1 Flash; C — Qwen3.8 Flash; D — Mercury 2.5; E — GPT-5.6 Luna; F — GLM-5.3 Flash.

Cost and latency improved; agreement did not establish a winner. Jev cost roughly 2 to 33 times less than these short-prompt baselines. With 83 selected contacts, the observed agreement differences are too small to establish a reliable winner or equivalence. DeepSeek V4 Flash, despite listing the same input-token price, still cost twice as much here. Generative arms produced 51,000 to 294,000 billed output tokens, with reasoning left on by default.

Repeated decisions were steadier, but not identical. Jev's two-run band agreement was 98%, compared with 84% to 87% for the three repeated short-prompt arms: DeepSeek V4 Flash, Mercury 2.5 and GPT-5.6 Luna. Raw Jev scores still drifted by up to 0.24. Consistency does not establish correctness.

The mistakes were commercially awkward. Jev had six send-to-no or no-to-send flips and missed soft-rule exceptions, such as a divisional budget owner at a company above the size ceiling. Atomic checks looked more promising: the competitor-studio flag was correct in 5 of 5 relevant cases, and function plus budget-owner checks in 15 of 15 reference sends. Those tiny subsets are clues, not dependable accuracy estimates.

Combining atomic answers in our initial code rule produced only 66% band agreement. A post-hoc, in-sample gate retained 93% of reference sends while dropping 53% of rows. Another in-sample cut, confidence at least 0.6, gave 92% agreement on 48% of rows. Neither result validates a production threshold. They support testing a routing gate.

What does the cheap decision actually buy?

Lower inference cost buys room for more checks per account. It does not remove the cost of collecting evidence or deciding whether the final record is usable. Count state, instructions, and options on every call at the documented $0.042 per million input tokens.

These scenarios use the documented price. Our measured 83-row cost was $0.0055.

Browser costs depend on the route. At the published Browser Use rates, 10,000 one-minute browser runs would cost about $3.33 in browser time. Assuming 2 MB of traffic each, 20 GB would cost $100 through residential proxies or $4 through the direct-traffic option. Add four assumed reviewer hours at $25 per hour and review adds another $100.

The illustration totals about $205.01 with residential traffic and one 4,000-token account check. Actual traffic, retries, and review can change this substantially. Reducing browser visits may beat another inference discount.

Use cost per correctly completed, accepted record as the operating metric. Include failed attempts and review. Compare against a parser or the cheapest adequate model for the same task boundary, with the same evidence and acceptance rules.

Thirteen GTM workflows worth building

The useful candidates are frequent judgments where the evidence and options already exist. Our lead-scoring test informs the first workflow. Six community demos expand the list into marketing research, intake, sales support and editorial review. The examples below explain how each could work and what to test before relying on it.

Pilot sizes and targets are design choices, not measured performance.

1. Lead and account qualification as a gate

Who it's for: operators applying a nuanced ideal customer profile across many accounts. Supply the company description, relevant responsibility text, size evidence, and explicit exclusions.

Jev asks: Does the company sell the relevant service? Does the contact own the function? Is there evidence of budget responsibility? How closely does the record fit the stated rubric?

Code decides: enforce genuine hard exclusions, then route ambiguous combinations to review or a reasoning model. A soft size preference should not silently override evidence of a divisional buyer. Keep unknown separate from no. Our post-hoc gate suggests this architecture is worth testing, not that its particular threshold is ready to reuse.

Output: accept, review, gather evidence, or reject, with the supporting spans and rule version attached.

Pilot: label 200 new records, preserving difficult exceptions. Tune on a development subset, freeze the rule, and measure send precision, send recall, review coverage, and severe flips on the holdout. Review proposed rejections during the pilot; otherwise missed buyers may remain invisible.

2. Verify every personalization claim before send

Who it's for: teams generating outreach from research. Inputs are a draft and the exact source excerpts behind its claims. Split “you hired three engineers to expand into Germany” into separate hiring, count, geography, and purpose claims.

Jev asks: Is this claim supported, contradicted, or insufficiently evidenced? Does the excerpt refer to the correct company? Does it explicitly support the stated purpose? Which supplied span supports it?

Code decides: check that the chosen span exists, compare dates and counts, and block unsupported material claims. An attractive paraphrase must not introduce buying intent that the source never stated. A stale fact may have been true but still be unsuitable for a present-tense opening line.

Output: a claim-by-claim pass, revise, or research queue.

Pilot: evaluate 200 drafts containing planted company mix-ups, stale facts, and exaggerations. Set zero critical false passes as the initial acceptance target. Passing a finite test does not prove the future error rate is zero.

3. Turn hiring signals into supported sales opportunities

Who it's for: sellers using vacancies as research triggers. Supply the job description, employer evidence, posting date, and a finite menu of offers, including “none.”

Jev asks: Is integration work explicitly assigned? Is the role responsible for building a new process or maintaining one? Does the description identify a relevant system? Which offer, if any, addresses the stated requirement?

Code decides: verify the direct employer, resolve reposts, compare timestamps, and apply account eligibility. A requirement for CRM expertise demonstrates work to be done; it does not demonstrate willingness to outsource that work. Preserve that distinction in the sales brief.

Output: an account, a supported requirement, exact evidence, a possible offer, and the unanswered buying question.

Pilot: review 200 jobs, including staffing firms, reposts, and tool mentions without ownership. Measure requirement-detection precision and useful account yield separately. A later reviewed campaign can test whether the proposed opportunity actually leads to conversations.

4. Route replies by next action

Who it's for: teams whose replies contain mixed intent. Supply the reply, enough prior context to resolve references, and a short list of allowed routes.

Jev asks: Is there an opt-out? Is another person being referred? Is there an explicit timing request? Does the sender ask about pricing or proof? Ask these independently because a single reply can contain several answers.

Code decides: suppression takes priority over a positive tone. Resolve dates and time zones outside the model. Preserve the original wording when a referral is uncertain, and require the relevant permission before any follow-up action.

Output: one operational route plus separate intent tags. “Not now, contact my colleague, and remove me” needs more than a positive label. See why positive outbound replies get lost.

Pilot: replay 500 historical replies, deliberately oversampling mixed messages and indirect opt-outs. Measure missed suppressions, incorrect routes, and review time. Inspect disagreement by intent rather than hiding a dangerous rare class inside overall accuracy.

5. Choose the next enrichment by missing evidence

Who it's for: teams paying for the same fixed enrichment sequence regardless of what a record lacks. Inputs are known fields, the qualification rubric, missing evidence, and available source types.

Jev asks: What uncertainty blocks the decision? Is a title, company category, or current role insufficiently established? Which approved source could address it? Is “stop” the appropriate choice?

Code decides: own the budget, source permissions, retry limits, and measured source-success table. A model should not invent a provider's expected yield or spend more because it remains uncertain. Stop when the next purchase cannot change the disposition under the existing policy.

Output: one next-source request with a reason, or a stopped record explaining the unresolved question.

Pilot: replay 300 partially enriched records against the existing fixed waterfall. Compare accepted-record yield, provider spend, and unresolved cases. Charge failed lookups to both approaches.

6. Match entities and personas without silent merges

Who it's for: operators deduplicating companies or mapping contacts to buyer roles. First block candidates using deterministic domain, name, or location rules. Jev receives plausible pairs, not the entire database.

Jev asks: Do these records describe the same entity, different entities, or insufficient evidence? Do their domains and descriptions align? Does the responsibility text match the intended persona? Is a title too ambiguous to decide?

Code decides: retain canonical identifiers, enforce merge constraints, and preserve conflicting evidence. Similar names do not authorize a merge. “Director” does not establish which function the person owns, and a matching company domain does not settle personal identity.

Output: proposed matches and persona assignments with evidence, plus a review queue for ambiguous pairs.

Pilot: label 300 pairs containing hard negatives, subsidiaries, rebrands, and people with common names. Measure false merges separately; combining unrelated records can corrupt their histories.

7. Discover partners from directories

Who it's for: teams finding training providers, consultants, implementation partners, or other firms inside directories. Inputs are directory text, observed links, known filters, and category definitions.

Jev asks: Which observed link leads to a relevant company profile? Does the firm provide the required service? Is it a consultant, competitor, directory, individual, or unclear? Which excerpt establishes the classification?

Code decides: apply known filters, bind selected links to actual observed URLs, deduplicate domains, and preserve “insufficient evidence.” A directory description is a discovery lead; decisive qualification should use the firm's own evidence when the directory cannot establish it. Re-observe after navigation before executing another action.

Output: a deduplicated candidate queue with source URLs, category evidence, and unresolved questions.

Pilot: review 150 candidates across three structurally different directories. Separate extraction completeness, classification precision, and acquisition failures.

8. Find conversations worth reviewing

AIsa's Worth Replying demo describes finding X discussions about problems a company's product addresses. The proposed GTM extension is a reviewed conversation queue; we have not tested it.

Who it's for: operators monitoring public discussions. Supply retrieved posts, surrounding context, the product's problem definition, and relevance criteria.

Jev asks: Is the problem explicit? Does the post concern the target use case? Is the author seeking help or discussing something else? Is there enough context to judge?

Code decides: enforce freshness, deduplication, exclusions, and review requirements. A relevant discussion does not establish purchase intent or permission to message. Another component retrieves posts and drafts any proposed response.

Output: a ranked review queue with excerpts and reasons.

Pilot: independently label 200 retrieved posts, including sarcasm and indirect mentions. Measure precision among surfaced conversations, missed relevant discussions, and review time before evaluating any outreach outcome.

9. Classify competitor ads into a research brief

Maxfusion's competitor-ad research demo describes classifying an ad library by customer-journey stage and ad style. The proposed extension is a traceable creative-research brief, not an inferred performance ranking.

Who it's for: marketers reviewing recurring competitor messages. Inputs are ad text, landing-page excerpts, and transcripts or visual descriptions produced by an appropriate extraction system. Jev itself is text-only.

Jev asks: Which supplied offer category fits? What problem is explicit? Which funnel stage does the rubric suggest? Is the evidence insufficient to classify?

Code decides: deduplicate variants, retain source dates, count categories, and separate observed content from interpretation. An active ad is not evidence of profitable spend, conversions, or a winning creative.

Output: a categorized library with supporting excerpts and gaps for investigation.

Pilot: label 150 ads across several advertisers. Check category agreement and errors introduced by transcription or visual descriptions separately. Evaluate any proposed creative in its own experiment.

10. Choose the next useful inbound question

Tamir Spiritt's JevForm demo describes a form that branches and chooses its next question. The proposed GTM application is adaptive intake from an approved question bank.

Who it's for: teams collecting enough context to route an inbound request. Supply previous answers, unresolved qualification fields, and allowed questions, including a finish or review option.

Jev asks: Which required fact is missing? Which approved question would clarify it? Has the visitor already answered it? Does this request need a person?

Code decides: enforce mandatory disclosures, required fields, question limits, and permitted routes. Jev must not invent eligibility rules or silently skip required consent. Deterministic branching remains a useful baseline for simple forms.

Output: the next approved question and, eventually, a structured request with unresolved details preserved.

Pilot: replay 100 labelled intake scenarios before a limited user test. Measure repeated questions, missed required fields, routing agreement, and abandonment separately; shorter forms do not automatically produce better leads.

11. Suggest an approved slide during a sales call

Zain Hoda's live-slide demo shows slide selection while the speaker talks. Using that pattern to assist a sales call is our proposed extension; no sales outcome was measured here.

Who it's for: sellers using an approved deck. Inputs would be permitted transcript excerpts, the current slide, and a catalog of slides with their claims, topics, and intended audience.

Jev asks: Which topic is being discussed? Has a specific objection appeared? Which supplied slide addresses it? Should the current slide remain?

Code decides: keep transcription separate, restrict selection to approved material, and require seller confirmation before changing the shared screen. Add a cooldown so shifting phrases do not cause distracting jumps. Do not infer buyer commitment from conversational tone.

Output: a private slide suggestion with the transcript evidence behind it.

Pilot: replay 20 permitted recordings with labelled suggestion points. Measure usefulness, irrelevant interruptions, and end-to-end delay, including transcription. A live pilot should preserve manual control.

12. Review LinkedIn drafts against a defined rubric

@robvjourney's LinkedIn post-scoring demo describes analyzing previous posts and scoring new ones. The author calls it a viral meter; the post does not establish that its scores predict reach or engagement.

Who it's for: writers seeking consistent editorial feedback. The proposed workflow supplies a draft, audience definition, and rubric for clarity, specificity, evidence, and relevance. Prior posts can provide examples without becoming a claim of predictive validation.

Jev asks: Is the main point clear? Is a claim supported? Does the example address the intended reader? Which rubric level best describes each dimension?

Code decides: preserve dimension scores and rubric versions. Keep performance outcomes separate from editorial ratings. A generative model or writer handles revisions; a high rubric score does not certify virality.

Output: a review checklist with criteria needing attention.

Pilot: compare scores with independent editorial labels. Any performance-prediction claim needs later held-out posts, defined outcomes, and controls for audience size, topic, timing, and distribution.

13. Check lead-message fit before a campaign

Gojiberry's lead-message matching demo reports assessing 700 leads and personalized messages in 40 seconds for $0.09, including confidence scores and mismatch detection. Those are the author's figures, not our measurements. Its performance predictions are not observed campaign outcomes.

Who it's for: teams assigning approved message variants to prospects. Supply prospect evidence, each variant's audience and offer, and a no-match option.

Jev asks: Does the offer address an evidenced need? Does the message assume an unsupported responsibility? Which approved variant fits best? Is none appropriate?

Code decides: enforce eligibility, suppression, and approval rules. This checks the relationship between prospect and message; a separate claim checker tests factual support. Confidence must not become an assumed reply probability.

Output: a proposed variant or no-match decision with evidence and mismatch flags.

Pilot: label 200 lead-message pairs, including deliberately mismatched offers. Test agreement on held-out pairs. Claims about replies or meetings require separate held-out campaign outcomes and a defined comparison.

Other bounded uses, and tasks to keep elsewhere

Five adjacent proposed uses follow the same division of work: classify meaningful account-page changes; match signals to known offers; triage campaign anomalies read-only; classify publisher-audit text after a visual tool inspects the page; and tag replies or calls for later analysis.

Keep writing with a generative model. Keep arithmetic, dates, and significance tests in code. Keep image interpretation with a visual system. Our lead-scoring errors also argue for retaining review around soft qualification rules until a larger independent evaluation supports automation.

What about browser automation?

Choose the smallest browser stack that can observe and verify the task. Jev selects decisions; it does not supply browser observation, execution, or independent completion checks.

The Jev Ultrafast implementation offers inspectable code for the bounded-action approach. Its recorded flight-search example used 17 Jev calls and two text-helper calls, with 178 ms median Jev latency. The reported 7.073-second clock excludes browser setup, initial navigation, and fresh independent verification. It displayed flight options; it did not purchase a ticket. (Pinned performance report)

The reported 90,558 Jev input tokens imply approximately $0.00380 at the published rate. Adding the reported helper charge gives approximately $0.00387 in calculated model cost, before browser charges. That is neither a billed receipt nor an end-to-end task price.

At the inspected revision, the MVP excludes frames, shadow DOM, canvas, uploads, and new tabs. Its execution loop logs confidence without a minimum-confidence gate before acting. Selecting DONE does not independently verify success. (Repository, execution loop)

For an adaptation, validate the operation and target separately, reject stale observations, and check the actual result externally. Also account for action discovery: natural-language observation can itself call a model. Stagehand's observe documentation describes that layer; the cheapest loop may collect ordinary DOM state deterministically.

How do you pilot this in 14 days?

Pick one workflow, label a sample, and freeze its policy before evaluating the holdout. The fortnight is a planning allowance, not a readiness promise.

Give each component one job

Keep a reproducible record: account_id, source_url, observed_at, content_hash, evidence_span_ids, question_schema_version, model_version, answers, decision, review_status, and cost_components. Store snapshots separately; trace changed labels to evidence, questions, or policy.

A workable schedule

Measure precision and recall for each class, coverage at each confidence threshold, repeatability, and cost per accepted completion. Evaluate calibration separately with a reliability table or Brier score where appropriate. Training-set thresholds do not establish calibration.

Separate cold and warm browser starts and report failures. Assess commercial impact through conversations or meetings in a later controlled campaign; label agreement does not validate the sales hypothesis.

For the orchestration layer around these decisions, see the workflow alternatives guide for GTM teams.

Limits of this guide

This is a launch-week assessment written September 19, 2026. Search indexing is incomplete, demonstrations were not reproduced, and browser code was inspected without executing its demo. Prices and model specifications need another check before publication or implementation.

Our benchmark covers one English-language task and 83 contacts selected toward difficult boundaries. Its reference labels are adjudicated model consensus. They may share model errors. The sample cannot establish production accuracy, universal equivalence, or calibrated confidence. Generative reasoning stayed at provider defaults, and there was no reasoning-off comparison. The full-prompt arms in the appendix were tuned on this same sample and are not clean holdout comparisons.

The other twelve workflows were not tested in this benchmark. Claim verification, reply triage, and partner classification each need their own labels and acceptance rules.

Frequently asked questions

What is Jev?

Jev is a text-based decision model from TypeSafe. It evaluates a supplied state using Choice, Noul, and Score questions. It returns structured decisions rather than free-form prose; another component must execute actions and check their results. (Documentation)

Can Jev write or personalize outreach?

It cannot generate outreach text. Use a generative model for writing and test Jev as a checker for individual claims against supplied evidence. Selecting a supported detail and composing a persuasive message are separate tasks.

Is Jev accurate enough to qualify leads on its own?

Our test does not support that conclusion. Jev's send recall was 60% for one brand and 44% for the other. A routing gate is worth evaluating, but our promising gate result was post-hoc and in-sample. It still needs a fresh held-out test.

How much does scoring 100,000 leads cost?

At an assumed 4,000 billed input tokens per lead, Jev inference would cost $16.80, using the documented $0.042-per-million rate. This excludes acquisition, enrichment, retries, infrastructure, and review. Different question sets or repeated calls change the token count. (Pricing specification)

Does Jev work for browser automation?

Public code demonstrates integration with a browser executor and observed action candidates. That establishes an implementation path, not general reliability. Start with ordinary HTML, bounded actions, and an independent outcome checker; escalate unsupported pages.

Start with one decision you can audit

Jev is worth testing where a cheap, bounded judgment can replace repeated interpretation of known evidence. The opportunity is more checks per account: what the source says, which option fits, and what still needs review.

Our benchmark makes the boundary tangible. Fast, inexpensive, repeatable decisions still missed reference sends. Treat the model as a candidate gate or checker, with policy and exceptions tested separately.

Choose one workflow, assemble labelled edge cases, and compare it with your current method on untouched examples. The useful asset is the resulting evidence, error taxonomy, and tested policy. Explore related evaluation work in Systems Lab.