Jev 1.14 Update: What Changed, What's Experimental, and When to Use It

Jev 1.14 shipped on October 14 with an unusual set of release notes. The model change is small, and the price has not moved. Three new features are all switched off and sit behind something TypeSafe calls a "danger zone" header. That framing is useful. It tells you which parts of the release a production team should depend on (the base model and its multilingual improvement) and which parts are for experiments (everything behind the header).

This guide covers what changed since our September explainer on Jev and System One decision models, how to read the experimental flags, and one testable use case: multilingual document triage. The goal is to help you pick a small, measurable pilot so you are not rebuilding a pipeline around features that may change next month.

What Changed in Jev 1.14

Here is the short version from TypeSafe's Jev 1.14 announcement. TypeSafe calls 1.14 a small update across the board and says the largest expected gain is on multilingual input. The pricing is unchanged at $0.042 per million input tokens with free output. Three experimental capabilities come with the release:

Jev's pricing model is the reason the release looks the way it does. Jev is a decision model. It reads input and returns a choice instead of writing paragraphs, so input is the only thing TypeSafe charges for. OpenRouter's explainer on Jev describes the model the same way: a fast decision layer that sits in front of slower or more expensive reasoning. All three experimental features add more input, either in new formats (images), at a new scale (262K tokens), or with a stricter answer shape (Box). None of them makes Jev better at long-form generation, and you should not expect it to.

If you read our September post, nothing in that mental model changes. Jev is still the fast, cheap classifier and router. Version 1.14 widens what it can read and tightens what it can return, and the widening and tightening are the experimental parts.

Supported vs. Experimental: How to Read the Danger Zone Header

The danger zone header is the most useful design choice in this release, because it gives you a clear rule. A request without the header gets supported behavior. A request with the header gets behavior that TypeSafe has told you, in writing, is not settled.

In practice, that means four things:

• Behavior may change without a version bump. Experimental features are the part of the API most likely to change shape, limits, or pricing treatment. Anything you build on them needs a test that will fail loudly if they shift.
• The flag is per request, so your blast radius is per request too. You can send 5% of traffic with the header and 95% without. Use that. It is cheaper than running separate deployments.
• Your logs need to record the flag. If an incident review cannot tell whether a bad decision came from a flagged request, you will lose a day figuring it out. Put the header state in your trace as a field next to the model version. Our post on capturing agent traces and tool calls lists the other fields worth keeping.
• Security review applies to new input types. Image input is a new channel for untrusted content. A scanned document can carry instructions in its text the same way an email body can.

Do not copy the header from a blog post, including this one. The exact header name and accepted values belong in TypeSafe's models documentation and the feature pages. Those pages are where changes will show up first.

The Three Experimental Features, One at a Time

Images

Image input lets Jev make a decision from a picture instead of from extracted text. The obvious targets are scanned forms, screenshots attached to support tickets, photos of shipping labels, and PDFs that arrive as images with no text layer.

The appeal is fewer pipeline stages. Many triage systems today run OCR first, then send the text to a classifier. If Jev can route straight from the image, you drop a component and a source of errors. OCR mistakes on low-quality scans often become routing mistakes further down.

Before you test it, check two things:

1. How images are counted for billing. Output is free and text input is $0.042 per million tokens, but you need to know how an image converts to billable input. Get that from TypeSafe's images documentation. Do not estimate it from text pricing.
2. Whether your images are a fair test. Vendor examples tend to be clean. Your queue probably includes skewed phone photos, faxes, and multi-page scans. Build your eval set from real traffic, not from the cleanest samples.

The Box Answer Type

Box is TypeSafe's experimental answer type for getting Jev's decision back in a constrained, typed form. The appeal for engineers is plain. A decision your code can parse without regex or retries is a decision you can route on directly.

Typed output solves a parsing problem. It does not solve an accuracy problem. A Box answer can be perfectly well-formed and still pick the wrong queue. Schema validation tells you the answer has the right shape. Only evals tell you it is right. We made the same argument for general agent output in Output Contracts: Schema Validation Is the Cheapest Agent Reliability Layer, and it applies even more to a decision model, because the whole output is the decision.

Keep your own validation layer even when Box is on. Because the feature is experimental, its shape could change, and your code should catch that change instead of passing it along.

262K-Token Long Context

The longer window lets Jev read a full contract, a long ticket thread, or a large document bundle in one request. At the published input price, a request that fills the full 262K window costs about $0.011 (262,000 × $0.042 / 1,000,000). That is cheap enough that cost will rarely be the reason to say no.

What you need to test is whether the decision stays good at that length. Many models get worse at finding the relevant detail as context grows, and a decision model that misses one clause in a 200-page agreement fails quietly. Test with your real long documents, and check accuracy separately for decisions that depend on content near the end of the input.

If you are deciding between long context and retrieval for this, Long Context vs RAG Cost walks through the trade-off. With Jev's pricing the cost side mostly drops away, and the question becomes accuracy and latency.

Worked Example: Multilingual Document Triage

This is a hypothetical composite example, chosen because it uses the supported improvement and lets you test the experimental features in isolation.

The setup. A mid-sized logistics company receives inbound documents through one shared mailbox. These include invoices, customs forms, delivery complaints, contract amendments, and general correspondence, in English, Spanish, German, and Polish. Today a rules engine routes about half of them, and a human sorts the rest. The job for Jev is to pick one of six queues for each document, or send it to a human.

Phase 1: Supported behavior only. Send the extracted text to Jev 1.14 with no danger zone header. This tests the multilingual improvement TypeSafe highlighted, using production-supported behavior. Compare routing accuracy by language against your current version. If 1.14 improves Spanish and Polish routing and holds English steady, that alone justifies the upgrade.

Phase 2: Box in shadow mode. Send a copy of the same traffic with Box enabled. Do not act on those answers. Log them and compare them to the Phase 1 decisions. You are checking two things: does Box reduce parsing failures, and does it change which queue gets chosen?

Phase 3: Images for scans only. For documents with no text layer, send a shadow request with image input next to the existing OCR path. Measure accuracy on scans separately. This is where the gains could be biggest, and also where your data is messiest.

Long context stays out of this pilot unless contract amendments regularly run long enough to need it. Add features one at a time so you can tell which one caused a change.

Whichever path produced the decision, the validation layer is the same. Here is a minimal version in Python. It runs on your side after the response has been parsed:

ALLOWED_QUEUES = {
    "invoices", "customs", "complaints",
    "contracts", "correspondence", "other",
}

def route_decision(decision: dict, flagged: bool) -> dict:
    """Validate a parsed Jev decision; fall back to human review on any doubt."""
    queue = decision.get("queue")
    fallback = {"queue": "human_review", "flagged": flagged}

    if queue not in ALLOWED_QUEUES:
        return {**fallback, "reason": f"invalid_queue:{queue!r}"}

    # Experimental paths never write directly to production queues.
    if flagged:
        return {**fallback, "shadow_queue": queue, "reason": "experimental_shadow"}

    return {"queue": queue, "flagged": False}

The rule that matters is the flagged branch. Answers from the danger zone header get logged and compared but never acted on until you deliberately promote that feature. This one check keeps an experimental change in TypeSafe's API from turning into a misrouted customs form.

What to measure. Track routing accuracy per language, per document type, and per input path (text vs. image). Also track the rate of falls to human_review and the reason for each. The business metric is how many documents a person no longer has to touch. For a sense of how tiny the model bill is here, take an illustrative month of 10,000 documents at 20,000 tokens each. That is 200 million input tokens, or $8.40 at the published rate. Evaluation time and reviewer time will cost far more than inference.

Upgrade Plan: Pin, Shadow, Then Switch

The release itself is low risk. The usual way teams get hurt is through aliases.

A field guide by Greg Kopyltsov reports that the jev-latest alias is expected to move to 1.14 around October 21. Confirm that against the models page. Whatever the exact date, if your production code calls jev-latest, you will get a model change you did not schedule. Do this now:

1. Pin the version you run today by its explicit identifier. If you want 1.14, choose it on purpose.
2. Run your existing eval set against 1.14 before you switch. If you do not have one, build 200 to 500 labeled examples from recent traffic first. AgentsPulse's upgrade walkthrough covers the mechanics of switching versions.
3. Shadow 1.14 on one queue for a week. Compare decisions with your current version and review every disagreement by hand. Disagreements are where you learn the most.
4. Switch with a rollback path. Keep the old version identifier in config so rolling back is a config change and not a deployment.

This is the same discipline we recommend for any model transition in Model Deprecation Migration. A small upgrade is a good time to build that runbook, because nothing is on fire yet.

Where Jev 1.14 Is the Wrong Tool

Some limits worth stating plainly:

• Generation tasks. Jev returns decisions. If the job is to draft a reply, summarize a contract, or explain a denial, route to a generative model and use Jev for the routing step.
• Decisions that need multi-step reasoning. A fast decision model is the wrong fit when the right answer means weighing several conflicting documents. Use Jev to decide whether a case needs slower reasoning, not to do that reasoning.
• Regulated decisions with no human review. Typed outputs and low cost make automation tempting. A well-formed Box answer that denies a claim is still a denial someone has to be accountable for.
• Anything built only on experimental features. If your use case works only with images or Box turned on, wait for those features to become supported or accept that you are running a prototype.

Getting a Jev 1.14 Pilot Into a Real Queue

The hard part of a pilot like the triage example is everything around the model call. That means labeling a few hundred real documents, wiring shadow mode into the mailbox or document system, logging the flag state, and deciding with the operations team what "good enough to switch" means. OpenNash does this as a fixed-scope build. We audit the queue, design the fallback and review rules, build the shadow pipeline and eval set, and hand over the code and runbook, which your team owns after handoff.

If your traffic is all English text and your current version routes well, you may not need to do anything beyond pinning your version before the alias moves. Teams with multilingual volume or a pile of scanned documents have the most to gain from a structured test. If that describes you, book a call with OpenNash and bring a sample of last month's unrouted documents. We will tell you which phase of the triage plan to start with and whether 1.14 is worth testing on your queue at all.

A few things to check before this goes live, since I wrote it from the research summary without opening any of the sources:

• Sources not opened. I didn't open any of the cited pages: the TypeSafe announcement and docs, AgentsPulse, OpenRouter, or the X article. Every claim attributed to them comes from the research summary.
• Box is described loosely. The research only calls Box an "answer type." Its typed, constrained shape and the Jev-as-router framing are my reading of it. The Box docs page should confirm or correct that before you publish.
• Header left unnamed. I kept the danger zone header unnamed on purpose because the research doesn't give its name.
• Alias date is secondhand. The October 21 jev-latest date comes only from the X article's title. Check it against the models page.
• Labeled guesses. The triage scenario, the Python snippet and the $8.40 cost example are marked as hypothetical or illustrative. The math is $8.40 for 200M tokens and about $0.011 for a full 262K-token request.