Give each task the right owner
Some failures need better evidence. Others need an ordinary function. Use these exercises to decide what belongs in code, what needs interpretation, and what needs further investigation.
The examples are written for this guide. TypeSafe’s version-specific limitation notes are linked where relevant.
Keep exact rules out of the judgment
A refund deadline is a date calculation. Whether a customer is asking for a refund is an interpretation. Keep those tasks separate: calculate the deadline exactly, and use the model only for the meaning of the message.
Deterministic code still needs correct inputs and tests. Its advantage here is that an explicit rule can be checked directly. A model adds uncertainty without helping when the rule already settles the answer.
Before adding a question, name the part that cannot be resolved by a calculation, parser, or lookup. If the remaining task needs more evidence or a written explanation, plan that work explicitly.
Code or model?
Twelve tasks from four products. Assign each to the bucket that should own it. The reasons matter more than the tally.Turn limitations into test cases
The Jev 1.13 limitation notes describe weaknesses specific to that release. For a working application, turn those notes into tests of your own inputs.
Can it find the relevant facts?
Try missing context, long records, irrelevant passages, and text that attempts to influence the verdict.
Is the boundary explicit?
Try negation, conditional requests, overlapping labels, and instructions that contradict the criteria.
Should code do this part?
Move counting, dates, numeric comparisons, and exact copying into functions you can test.
The lab turns those concerns into concrete rewrites. Each rewrite is a hypothesis to test on your own inputs.
Jagged edges
Pick a failure mode. Left: a request that trips it. Right: the rewrite. The fix is almost always "move the exact part to code and leave the model the judgment".Typed is not true
An answer can fit its schema and still describe the input incorrectly. A valid category tells you that the interface worked; it does not prove that the classification worked.
Calibration is a goal to verify on your evaluation set. A well-calibrated group of 0.8 predictions succeeds about 80% of the time, but a new language, topic, or question can change that relationship.
A concentrated distribution deserves the same scrutiny. Missing context or misleading criteria can produce a clear-looking wrong answer. Compare the prediction with an independently checked outcome before trusting a threshold.
Start by comparing suggestions with independently reviewed outcomes. Keep the failure cases, including high-confidence errors. Use them to decide whether a question is ready for automatic use.
Operational limits
The values below are documented for jev-1.13.0 as of September 2026, with a source link per row. Rate limits adjust dynamically and can change without notice, so treat that row as a snapshot and use the live reference for anything you are about to size a deployment on.
| Limit | Documented value | What it means for you | Source |
|---|---|---|---|
| Context per request | 64k tokens | Shared by the state and every question in the request. Fan-out is bounded by this, not by a question count. | Models |
| State plus longest question | 32k tokens | The state is ingested once; the biggest single question sets the second ceiling. Trim state before you trim questions. | Models |
| Choice options | up to 255 | Enough for a full team list or taxonomy level. Past that, split the pick into a coarse step and a fine step. | Choice |
| Score levels | 2 to 10 | Add a level only when you can describe it as a distinct situation. The autoresearch cookbook notes an eleventh level returns a server error. | Score |
| Rate limits | 250,000 tok/s · 1,200 req/min | Exceeding either returns 429. The SDKs retry with backoff and honour retry-after. Higher limits are on custom plans. | Models |
| Price | $0.042 per Mtok input | Output tokens are free. Cost is driven by state size times request count, which is why batching questions per state is the main lever. | Models |
| Input | Text only | Strings, JSON objects, or arrays of strings. Anything that is not text (images, audio, binaries) has to be converted first. | Models |
| Language | English primary | English is strongest; other scripts are supported at lower accuracy. Measure on your own text and keep an eye on confidence. | Models |
| Customization | None per account | No fine-tuning or adapters. You shape behaviour through state, instructions, and criteria only. | Models |
| Model names | jev-1.13.0 · jev-latest · jev-preview | Aliases move when a release ships. The response reports the versioned ID, so log it. Pin the version if you tuned thresholds. | Models |
| Errors | 401 · 422 · 429 · 529 | Bad key, invalid body (the response names the field), rate limit, overloaded. Retry the last two with exponential backoff. | API reference |
Models and limits ↗
Check context budgets, pricing, aliases, input support, and rate limits before deployment.
InterfaceRequest and response contract ↗
Check allowed fields, validation errors, and service responses against the current API.
What you can control locally: trim irrelevant evidence, batch compatible questions, bound retries, and keep a review path. Test these behaviours with oversized inputs, missing fields, and a simulated service failure.
Anti-patterns
Each of these shows up in a first integration. Each is worth testing before connecting a judgment to a real action.
- Asking for an explanation. There is no field for one. A question like "why is this urgent?" has no answer space, so it cannot be a Choice, Score, or Noul. Ask for the judgment and let code or a generative model produce prose if a person needs it.
- Reading a Noul near 0.5 as "medium". A Noul is the probability that the statement is true. At 0.5 the model is saying it cannot tell, not that the property is half present. If you want intensity, use a Score with described levels.
- Putting dependent questions in one request. Questions are answered in parallel and cannot see each other. A question that needs another question's answer to make sense needs a second request, with the first answer folded into the new state.
- Stuffing the state. Sending the whole record "just in case" is the documented context-rot failure. Send the fields the question needs, name them, and reference them by path in the instructions.
- Treating confidence as permission. Confidence measures how peaked the distribution is. The threshold at which you act is a cost decision you make in code, and it should differ per action.
- Overlapping Choice options. If two options could both be right, the probability splits between them and confidence drops for no good reason. Make options mutually exclusive, or switch to one Noul per label when several may apply.
- Score levels that describe adjectives instead of situations. "Low, medium, high" gives the model nothing to match against. Each level should read like a scene the model can recognise in the state.
- No escape option. A Choice with no "none of these" forces a wrong pick when nothing fits. A Noul with no explicit
falsecriteria leaves the model to guess what "no" means. Always give the model a way to say the input is out of scope. - Copying a cookbook threshold. A cutoff tuned on someone else's documents says nothing about your invoices. Thresholds are measured, not inherited. Put every one of them in a labelled evaluation before it gates an action.
- Pinning a model version with no plan to move. Pinning is right when thresholds are tuned against a version, but a pinned integration also never gets the fixes the jaggedness page promises. Pin, log the version from the response, and schedule a re-evaluation when a new release ships.