7 Jev use cases that remove real work from software

Someone asked our website how many integrations we have. It answered with advice about how many fields belong in a signup form.

The answer arrived quickly. It was useless.

Both questions contained “how many.” Our search code gave an accepted FAQ match a minimum score of 0.86, making a weak match look convincing. Speed hid the wrong decision.

That is the kind of failure worth thinking about when you look at Ship with Jev. On September 26, 2026, the directory listed 551 community builds. Games sit beside search components, browser agents, research tools, and routing experiments. The directory attributes performance numbers to their authors; it is a discovery tool, not an independent benchmark.

The interesting question is which of those patterns removes work from a real product.

For teams building integrations and business software, these are the seven I would evaluate first. The order is an editorial judgment about usefulness and testability. The workflow examples below are proposed designs unless a linked implementation is named.

What Jev contributes to an application

TypeSafe describes Jev as a model for typed judgments. Give it relevant state and a question; receive a choice, a probability, or a score that code can consume. Its use-case map includes routing, retrieval, verification, and extraction.

That distinction has a useful precursor in our ingested YouTube material. In Diogo Almeida’s AI Engineer talk, the TypeSafe cofounder argues for software whose building blocks can express more intelligence. He contrasts that ambition with attaching an assistant to existing software. This is his argument about the direction of AI, not a benchmark of Jev’s current performance.

Consider a railway junction. The useful output is which available track the train should take. A paragraph describing the tracks adds nothing to the switch.

The objection is reasonable: “An ordinary LLM can already return JSON.” Yes. The case for a different component rests on measured quality, cost, and latency for that decision. A typed response alone does not establish any of them.

The CLM challenge deserves to come first

On September 23, Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré, and Azalia Mirhoseini published Contrastive Language Models. Their work challenges the assumption that Jev is the only practical route to fast semantic decisions.

The authors report comparable zero-shot results to Jev on computer-use, gaming, and tool-calling tasks, with up to 9× lower latency. They separately report 81.6% on 38 held-out DeepSWE tasks and 87.6% on 30 Terminal-Bench 2.1 tasks. Those coding results use fine-tuned CLM verifiers selecting among solutions generated by other models. They also report Jev below their random-selection baseline on that verifier setup. Latency was measured on an H100. These are the authors’ findings, which we have not independently reproduced. Original evaluation and methodology.

That comparison changes what we should test. Selecting a support queue, choosing a search passage, and evaluating a long coding trajectory are different tasks. A good result on one cannot settle the others.

CLM encodes states and candidate actions separately, allowing reusable action embeddings to be cached. Its repository documents a TypeSafe-compatible interface and a default 2,048-token state limit, with longer states truncated unless configured otherwise. Compatibility at the API boundary does not establish equivalent decisions.

The released model card specifies Qwen3-8B embeddings and warns that the strong verifier results require fine-tuned heads. It also makes clear that CLM scores supplied candidates and produces no generated solution. Open weights create an evaluation option; hardware, serving, and maintenance still have costs.

For Alto, the useful lessons are concrete: compare decision models on the same cases, record cold and warm latency separately, and test plausible wrong candidates. Pin the model and any encoder or projection head. Reject unsupported provider configurations instead of silently selecting another provider. Recheck calibration when the model or candidate set changes.

The seven workflows below remain useful candidates for evaluation. Their value does not depend on Jev winning every comparison.

1. Search that checks whether the result answers the question

This is my first choice because the failure is visible and the outcome is easy to label. Did the returned passage answer what the visitor asked?

Retrieve a small candidate set with keyword search, embeddings, or both. Then ask Jev whether each passage supplies the requested fact. TypeSafe’s reranking cookbook demonstrates this two-stage structure. It also exposes the limit: a reranker cannot select a document that retrieval omitted.

For our integration-count example, the shortest path is even simpler. Count entries in the authoritative catalog. State what the count means. A documented connector and a connection configured by a customer are different things.

Reserve semantic judgment for questions whose meaning needs interpretation, such as “Can this move only customers who changed since yesterday?” Retrieve the relevant sync documentation, then check that it addresses incremental updates.

Kyle McLaren’s jevsearch implementation makes the sequence tangible: keyword results arrive first, followed by a Jev ranking. Its published benchmark uses its own documentation corpus and labeled queries. That is useful evidence about that test, not a promise for another website or language.

Measure correct answers, unsupported answers, unanswered questions, and total latency. Include misspellings and translated queries. Faster irrelevant results are still irrelevant.

2. Routing requests to the right page, queue, or agent

A user writes: “The contacts stopped arriving after I changed the account.” Your application needs to distinguish connection troubleshooting from billing, field mapping, and a request to create a new sync.

Supply the current screen, recent conversation, and the destinations available to that user. Ask for the best destination, with an explicit no-match option. Keep the destination identifiers under application control.

Several judgments may be useful together: intent, destination, urgency, and whether the message contains an actionable request. TypeSafe’s fan-out pattern lets independent questions share one request. Code consumes the relevant answers afterward.

A harmless navigation suggestion and permission to execute work remain separate decisions. Finding the right billing page does not authorize a refund. Finding the right agent does not grant that agent credentials.

The practical benefit is fewer handoffs and fewer clarification loops. Measure how often the user reaches the correct destination on the first attempt. Keep a replay set containing follow-ups such as “yes,” “new task,” and “are those finished?” They only make sense with context.

3. Mapping messy data into a dependable integration

Here is a proposed integration workflow. A source export contains customer_email, billing_email, and account_owner_email. The destination expects the contact’s email address.

String similarity leaves a real ambiguity. Field descriptions, sample values, and the business purpose help resolve it. Jev can choose among actual source fields while code checks types, required values, and destination constraints.

The related pre-parsed extraction cookbook uses an especially useful design: code finds candidate values, the model selects a candidate, and code copies the original value. That avoids generating a replacement address or amount.

For a CRM and email integration, preserve the source field and the mapping decision together. Show a preview of affected records. Keep uncertain mappings unresolved until reviewed.

There is an economic advantage here: an approved schema mapping can be reused. You do not need a model call for every row when the field meaning has stayed the same.

Measure rejected records and incorrect mappings against a reviewed sample. A successful API request proves that the payload was accepted; it does not prove that the correct email reached the correct contact.

4. Choosing the smallest model that completes the task

Model routing is compelling when an application sends everything to its most expensive model. A label change, a search judgment, and a difficult architecture investigation have different requirements.

First define the models that are configured and allowed to receive the task’s data. Record their supported tools and observed performance. Then a narrow judgment can recommend a suitable option from that set. TypeSafe includes this pattern in its model-routing examples.

OpenRouter’s Jev Router exposes this pattern as the model ID typesafe/jev-router through its chat API. The listing describes selection of both the model and reasoning effort as a conversation changes. Evaluate its allowed downstream models, actual charges, data handling, and behavior during tool calls before adopting it. We verified the listing; we have not benchmarked this router.

Our suggested policy starts with ordinary code for exact rules and facts. Use a decision model for bounded semantic questions, a suitable generative model for writing or implementation, and escalation when evidence warrants it.

The router itself costs time and money. For obvious repeatable tasks, a fixed rule can be better. For ambiguous tasks, compare routing against a fixed-model baseline on completed work.

Track cost per accepted result, retries, escalation rate, and failures discovered later. A cheaper first call can become an expensive workflow if someone has to repair its output.

5. Checking claims before they become customer-facing answers

A citation can exist and still fail to support the sentence beside it. A source may describe a planned feature while an answer calls it available today.

TypeSafe’s citation-checking cookbook separates two checks. Ordinary string matching detects a missing quotation. A semantic judgment evaluates whether the surrounding source supports the claim.

Apply the same design to a support reply, a generated integration guide, or an agent’s proposed completion report. Keep the claim, source passage, and verdict available for review.

Completion still needs direct evidence. Tests establish tested behavior. A deployment record establishes a deployment. A semantic judgment can flag a mismatch between a report and its evidence; it cannot create the missing evidence.

This use case is attractive because it can sit before an existing publishing step. Measure unsupported claims that escape, supported claims that are unnecessarily blocked, and the review work created. Begin with explicit errors you already know your system makes.

6. Turning transcripts and customer feedback into useful shortlists

A transcript archive becomes useful when someone can find the passage that matters. “Contains the word integration” is a weak filter for “explains why a customer abandoned setup.”

One approach is to retrieve likely passages, then judge a few specific properties: does this describe a setup obstacle, contain a concrete example, or stand alone without missing context?

Keep the source URL and timestamp attached to every selected passage. The timestamp comes from the transcript. The model judges relevance.

For a video editor, those signals can produce a shortlist of clips to review. For a product team, they can organize recurring objections. For a marketer, they can separate customer evidence from unsupported campaign claims.

TypeSafe’s composite-scoring pattern keeps dimensions separate so code can change their weights. A clip suitable for a tutorial may differ from one suitable for a short product demonstration. Reuse the judgments when the underlying evidence and criteria remain unchanged.

JevQL offers a related community implementation: semantic predicates over PostgreSQL rows, evaluated outside the database. Its documentation makes ordinary filters relevant to the bill. Reduce the eligible rows before requesting semantic judgments.

Measure reviewer acceptance and time saved finding usable material. A score for hook strength is not a forecast of views.

7. Interfaces that select the next useful action

A settings screen might receive “Stop this sync until tomorrow.” A browser agent might need to choose among the controls visible on the current page.

In our proposed interface design, the application supplies permitted actions and current state. Jev selects among them. The interface presents the relevant control or a reviewable proposal.

Ship with Jev includes Gregor Zunic’s browser flight-search demo. Its reported runtime and cost belong to that demonstration. The transferable idea is choosing from the actions available at each step; another browser flow needs its own verification.

State freshness matters. If the selected account or page changes while a judgment is running, discard the stale result. Bind actions to the account and state that were reviewed.

This can also make a typed UI catalog useful. A model selects a known view and its bounded data; ordinary rendering code produces the interface. Measure successful task completion and mistaken actions, with special attention to whether the controls remain understandable.

Where I would start

Choose the repeated decision that already creates visible waste. Use its actual failures to build the evaluation set.

Do not copy a demo’s confidence threshold. TypeSafe’s confidence documentation explains that Choice and Score confidence summarize a distribution. They are not proof that the inputs were complete or the selected action is authorized.

Include cases where none of the candidates fits. Include an unavailable service. Include each language you intend to support. Keep the model revision and question definitions with the results so a later change can be compared fairly.

For an integration product, I would start with search relevance and field mapping. Both shorten the path to a working sync. Both let you inspect the mistake before it grows into a customer problem.

Pick one wrong answer your software gives today. Make it reliably take the right next step.