Robotics Is Where Jev Belongs: The Decision Layer Between Motion and Planning

Hello, this is Ryuta Hamamoto from TIMEWELL.

Anyone who has put a robot into a real workcell has hit this wall. The motion is the easy part. What hurts is deciding which motion to run right now.

An arm in front of a shelf: grasp, reposition, or hold because someone walked in. A mobile robot at a corner: turn, or carry on and come around. Existing planners and controllers can produce any of those motions. It is choosing between them that turns into a thicket of branching logic nobody can safely touch. Bring in a large language model and the other failure mode appears: it spends seconds composing a sentence while the robot stands still.

Jev, announced by TypeSafe AI on September 15, 2026 (US time), is a part built for that exact slot¹². It writes no prose. It picks one option out of a set you defined and attaches a probability. That is all it does.

The short version:

• Robot control is layered: servos near 1000 Hz, VLA models at 5–50 Hz, task planning below 1 Hz. Jev lands in the 2–14 Hz band
• Jev cannot take images, so perception stays upstream and Jev receives only the state written out as text
• When the options are finite, the state can be written down, and you want dozens of judgments at once, the shape fits without forcing
• Output is free, so the cost of deciding effectively disappears — ten queries a second runs about $7 an hour
• But it must never carry a safety function. Answering in shape is not answering correctly

What Jev actually does

Start from the beginning, for readers coming to this cold.

A chat model answers a question with prose. Ask whether to grasp a part and you get "Yes, the object appears stable, so grasping is recommended." The program driving the robot does not want that sentence. It wants the choice grasp and a number saying how sure the model is. Prose has to be parsed back into something a branch can consume, and it arrives one token at a time, which costs seconds.

Jev removes that step. You send a block of text describing the situation and the questions you want answered. There are only three kinds³.

Choice picks one option from a list. Define grasp, reposition and wait, and one comes back with per-option probabilities and an overall confidence value.

Score places the input on a scale you define. Define "unstable", "marginal" and "stable", and you get a value like 1.3 that can sit between levels.

Noul returns the probability that a statement is true, from 0 to 1. Write "the object is inside the grasp envelope" and you get back 0.87. In practice this is the most useful of the three.

Two properties matter for robotics. First, you can mix dozens of questions of different kinds into a single call, and they are evaluated in parallel³ — adding questions barely moves the latency. Second, output is free. Input runs $0.042 per million tokens; output is not billed at all⁴, because there is no writing step to bill for.

TypeSafe calls this a System One model, after Kahneman's fast, intuitive System 1. The documentation is blunt: these models "do not write replies, produce code, or generate explanations of their reasoning"⁵.

One constraint before we go further. Jev accepts text only. The docs state plainly that "images, audio, and video are not supported (yet)"⁵. That reads like a weakness and turns out to make the architecture cleaner, which I will come back to.

We measured the model in Japanese ourselves. Asked as a binary across 1,852 of our own articles, it hit 96.4% precision and 87.9% recall at a 0.20 threshold. Asked to pick one of nine categories, it agreed with our labels only 36% of the time⁶. Lining up true-or-false questions beats reaching for a multi-way choice — a lesson that carries straight into designing robot decisions.

Robot control is stacked in layers

Here is the substance. People say "put AI in the robot" as if the robot were one thing. It is a stack of loops running at different rates, and each layer wants a different tool.

At the bottom, servo control: joint angles and currents, near 1000 Hz on industrial arms. Deterministic control law territory. Nothing probabilistic belongs here.

Above it, trajectory generation and motion planning: getting from pose to pose around obstacles, tens to hundreds of Hz.

Above that, the layer developing fastest right now: Vision-Language-Action models, which take camera images and a language instruction and emit robot actions directly. Open-source OpenVLA infers at 3–5 Hz and needs 0.33 seconds for a single timestep of action even on an A100⁷. OpenVLA-OFT+, using parallel decoding and action chunking, reaches 77.9 Hz, and Physical Intelligence's π0 runs at up to 50 Hz⁸⁹. This layer is in a frequency race.

At the top, task planning: "take the part from the shelf, put it on the inspection bench, red bin if it fails." Below 1 Hz. This is where large language models have been arriving.

Jev lands between the VLA layer and task planning. Responses come in 70–500 ms¹, so 2–14 Hz. Too slow to synthesise continuous motion, too fast to be reasoning about the whole sequence. And in between sits the layer where branching logic actually piles up.

Put into words, that layer does two things. Given the current situation, decide which of the prepared behaviours to start. And decide whether to proceed, call a person, or stop. Choice and Noul, exactly.

Why the fit is so clean

Four reasons.

One: robot actions are already discrete. Generative models earn their keep where there is unbounded freedom in what to produce. What a robot does next is almost always a finite list — grasp, release, approach, retreat, wait, escalate. "One out of a finite set" is literally what Choice is. No detour through an unbounded model and a parser.

Two: robot state is already numbers and symbols. Joint angles, force readings, the detected object list with coordinates, battery level, how many times the last attempt failed. All of it writes out as text. The no-images constraint barely bites — and it forces you to decide explicitly where image-to-text happens, which makes the architecture more honest.

Implementations published after launch show this well. Milind S built desktop automation that never sends a screenshot anywhere: a small local vision model crops the on-screen elements, on-device OCR reads their labels, and only those strings go to Jev. Probabilities per element come back, the highest gets clicked, detection runs again. He reports about 90 ms per decision¹⁰. The robot version is structurally identical — perception turns sensors into an object list, and the list is what you send.

Three: dozens of parallel questions cost you nothing in latency. This is where robotics benefits most. Every decision has a pile of things you would like to confirm. Is the object inside the envelope? Is a person entering the cell? Are we repeating the same failure? Is the grasp pose stable? Will the battery finish this move? Are we past the cycle time?

Ask those in stages and each stage costs you. Jev takes them in one call with almost no change in response time. Stop designing "check urgency first, then ask more" and just ask everything, combining the answers in code. TypeSafe's own guidance says the same from the other side: "Code handles deterministic work and owns the control flow. The model appears only where the system needs programmable common sense or needs to interpret unstructured data"¹¹. To anyone who has written robot control, that is not a new idea — it is the house rule.

Four: probabilities and confidence give you somewhere to stop. This may be the biggest one. Robots break things and hurt people when they get it wrong, so "stop when unsure" sits at the centre of the design. Jev returns per-option probabilities and a confidence value, and the official guidance is a three-band rule: act automatically on high confidence, proceed carefully on medium, and on low "do not act — route to a human, request clarification, or fall back to a different system"¹².

Those bands map onto robot operation directly. High: run at normal speed. Medium: run reduced and log it. Low: stop and call someone. A tool that automates judgment is exactly the tool that needs its stopping line drawn first. Reading "sounds unsure" out of free prose is far worse than getting a number.

What the post-launch builds tell us

Four implementations from the days after launch that translate into robotics. All figures are reported by their authors under their own conditions.

Ten decisions a second holds up. TypeSafe's own launch demo sends Doom's game state as structured text and gets the next action back. The official post says roughly ten calls per second at about $7 an hour, notes that the input is structured data rather than images, and adds that "a conventional Doom bot can play better"¹³. I trust a vendor that puts the caveat on its own marketing demo. Ten per second is plenty for action selection on a mobile robot.

A 330 ms cadence stays unbroken. The atomic.chat team had it pick a safe tile every 330 ms while rockets fell, surviving 25 of 26 runs¹⁴. Each individual decision is trivial; sustaining three a second without a gap is the actual test. That is the shape of monitor-then-avoid.

Split reflex from planning. Wuyang Zhou paired Jev with OpenAI's GPT-6 Astra to play Minecraft, with Jev reacting instantly to events and Astra planning toward larger goals¹⁵. I think this is the real target shape for robotics. Task planning on the large model, action selection on Jev, motion on a VLA or a conventional controller. Different tool per layer.

Four path decisions a second. A browser driving simulator laid out lane boundaries, surrounding vehicles and signals as a table and had Jev pick among candidate paths, up to four times a second at corners and in traffic. Emergency braking was handled by a separate mechanism¹⁶. Not a real vehicle, and not a safety claim. But keeping the emergency stop out of the model is the correct instinct.

What sits in that layer today

To place Jev properly, look at what teams currently put in that slot. Three options, broadly.

Write every branch by hand. The most common. Fast, fully predictable, testable. The problems are that it does nothing in situations nobody anticipated, and that it accretes until no one will touch it. Three years of plant changes later you have the block of if statements that nobody wrote and nobody dares delete.

Drop in a large language model. Since 2024 this has genuinely arrived at the task-planning layer. It is flexible, but two things hurt at the action-selection layer: it is slow because it writes, and it returns free text, so somebody has to build and maintain the parser that turns "you should probably grasp it" into grasp.

Replace the layer with learning. The VLA direction. Powerful when it works, but changing only the action-selection behaviour still costs you a training cycle, so "from today, wait when a person approaches" is not a same-day change.

Jev sits between those three. As fast as branching, as flexible as a language model, and changeable by editing a question rather than retraining. In exchange it produces no motion and sees no images. Narrow capability, unambiguous place.

Check the cost, in the units that matter

Robots run continuously, so per-call pricing tells you nothing. Per day does.

The official Doom demo is roughly ten calls a second at about $7 an hour¹³, and that sends the whole game state each time. Industrial action selection rarely needs ten a second. At twice a second for an eight-hour shift you get 57,600 calls; at a few hundred characters of state each, the published price list puts that around $0.3⁴. Cents per robot per day.

What that buys you is not speed. It is that you stop skipping checks to save money. No more "checking everything every cycle is too slow and too expensive, let's do it every third cycle." Combine that with questions being free in latency terms, and confirming everything you want to confirm, every cycle becomes a realistic design. For safety and quality, that is not a small shift.

Only the judgment gets cheap, of course. Cameras, detection, OCR and point-cloud work all still cost. Look at the total.

Wiring it into a robot

Concretely, four layers.

Perception. Cameras, depth, force, encoders. Outside Jev's remit. Detection, pose estimation, OCR, point clouds. The output is structured text:

target: bolt M6 / pos (x=0.42, y=-0.11, z=0.08) / tilt 12deg
grasp envelope: inside
humans: 1 at 1.8m, approaching
last attempts: 2 failures (slip)
battery: 41%
cycle: 38s over plan

That string is what Jev receives. No image, and none needed.

Decision. Jev. Send the questions as a bundle:

action   : Choice  "which action to run next"
           grasp / reposition / wait_for_human / call_operator / abort
stable   : Noul    "the object's pose is stable enough to grasp"
human    : Noul    "a person is entering the work envelope"
repeat   : Noul    "we are repeating the same failure cause"
urgency  : Score   "how time-critical this situation is", 3 levels

Back come the choice, the probabilities and the confidence. What the robot finally does is decided in code, not by Jev. For instance: if human exceeds 0.6, wait regardless of action; if repeat exceeds 0.7, switch grasp strategy. Hold the thresholds as constants in one place and make changes go through code review — the same shape TypeSafe's cookbook recommends¹¹.

Execution. Start the existing planner and controller for the chosen behaviour. Unchanged; Jev does not touch it.

Safety. Next section, and independent of the three above.

The property I like most here is that the system still works without Jev. Replace the decision layer with fixed rules and you are back to a conventional state machine. It makes things better when present and breaks nothing when absent. For a new component, I would treat that as a requirement.

Four ways this bites

No images. Text only⁵. Expecting "it watches the camera and decides" will wreck the design. Perception goes upstream, always. Conversely, if your perception output cannot be written as text, Jev is not your tool.

Bad at arithmetic and counting. The vendor publishes the weak spots: literal interpretation, poor arithmetic and counting, unreliable date comparison, degraded accuracy as irrelevant material accumulates¹⁷. Distances, counts and time deltas get computed in code and passed in as numbers. Never ask it to count to ten.

Well-formed is not correct. The site says the model does not hallucinate, meaning it will not emit a value outside the schema. Both Hacker News and The Register have pointed out that a valid-but-wrong value remains possible¹⁸. Honouring the option list says nothing about picking the right option. That is what the probabilities are for.

Japanese is weaker than English. The docs say English "is the primary training language and where accuracy is currently best," with other languages "handled but not equally well; test on your own content"⁴. If your robot state is written in Japanese, measure your thresholds on your own data first. In our measurement a binary question reached 96% precision in Japanese, but the default 0.5 threshold lost a lot — recall only recovered to 88% at 0.2⁶. You cannot guess this.

Keep safety on its own system

This part I will state flatly. Do not put Jev in a safety function.

Emergency stop, speed and force limiting, human proximity monitoring, guard and light-curtain interlocks. These live outside any probabilistic model, on an independent safety system. TypeSafe's own cookbook says of its classification step that "nothing here is a security boundary"¹¹.

ISO 10218, the industrial robot safety standard, had both parts revised in January 2025 — the first major overhaul since 2011. It absorbs the previously separate ISO/TS 15066 on collaborative applications, clarifies functional safety requirements, and adds cybersecurity requirements insofar as they bear on robot safety. Part 1 grew from 50 pages to 95¹⁹.

What that direction means is that even on an AI-equipped robot, the safety floor is built deterministically. Jev operates only inside the envelope the safety system guarantees. Let Jev decide to slow down, but hold the speed ceiling outside Jev. Let Jev decide to stop when someone approaches, but let the safety system be what actually stops it. Draw that line at the start, because you cannot redraw it later.

Why this matters on a Japanese shop floor

The reason this lands in Japan is that understaffed lines still carry an enormous amount of branching judgment.

Processes that resist full automation almost always contain decisions that are "slightly different every time." The part is not oriented consistently. Variation from the previous process carried through. More people on the floor today. Try to write all of that as branching logic and you get unmaintainable code; leave a person standing there and you have given back most of the benefit of automating.

A component that fills those slightly-different judgments cheaply, quickly, and with a place to stop is what this launch actually delivers. Read as a benchmark story it looks small — no prose, no vision, no arithmetic. But as physical AI reaches the floor, what is missing is often neither perception nor motion. It is the judgment in between.

I wrote separately about how Japanese manufacturing might come back through physical AI in Japan's physical AI comeback, and collected twenty implementations in first-pass triage for $0.12. Reading those alongside this should place it.

How much branching judgment is left in your own processes, and how far you hand it over before a person takes back control, is a question about operations rather than technology. If you want to see where your organisation currently draws that line, try our AI literacy assessment.

Summary

Robot control is layered, and each layer wants a different tool. Deterministic control law at the servo. A VLA or a conventional planner for motion. A large language model for sequencing. And in between, the layer that only picks the next action — which until now had no part built for it.

Jev fits there. Finite options, state that writes out as text, judgments you want in parallel, a confidence value to stop on: robotics satisfies all four. With output free, the cost of deciding effectively disappears.

But you cannot send images, you must not ask it to compute, and it must never hold a safety function. Keep those three and it is a component you can try this week.

TIMEWELL runs WARP for AI adoption and capability building, and we are developing that practice toward AI robotics training. Putting robots on the floor and deciding how much judgment to hand to a machine are no longer separable questions. If you want help mapping which layer of your process gets which tool, talk to us about WARP.

References

Footnotes

1. Introducing System One Models and Jev (TypeSafe AI, Diogo Almeida). The System One definition, 70–500 ms latency, $0.042/MTok input with free output, and the Doom demo (about ten calls per second, roughly $7/hour, structured data rather than images as input, and the note that a conventional bot can play better) come from this post ↩ ↩²

2. Diogo Almeida's announcement post (September 15, 2026, US time) and the TypeSafe AI account's post the same day. Press coverage: The Register, September 16, 2026 ↩

3. Introduction (TypeSafe AI Docs). The three primitives, their return values, mixing question types in one call, and parallel evaluation ↩ ↩²

4. Models (TypeSafe AI Docs, retrieved September 19, 2026). jev-1.13.0, $0.042 per million input tokens with free output, 64k context, text only, "English is the primary training language and where accuracy is currently best," other languages "handled but not equally well; test on your own content before relying on Jev for a non-English workload" ↩ ↩² ↩³

5. System One (TypeSafe AI Docs). "System One models do not write replies, produce code, or generate explanations of their reasoning." and "Jev currently accepts text input only. It evaluates strings, JSON objects, and arrays of text. Images, audio, and video are not supported (yet)." ↩ ↩² ↩³

6. Our own measurement, September 19–20, 2026. For each of 1,852 Japanese articles under content/columns we sent the title, description and first 1,600 characters of body, asking jev-latest three questions at once. 49 seconds at concurrency 10; the $0.12 figure is estimated from input token count against the price list in note 5, not read from an invoice. Ground truth is the category in each article's front matter. Binary precision 96.4% and recall 87.9% at a 0.20 threshold, 36% agreement on the nine-way choice, 75.4% recall at the default 0.5 threshold ↩ ↩²

7. OpenVLA (GitHub) and Fine-Tuning Vision-Language-Action Models: Optimizing Speed and Success (arXiv 2502.19645). OpenVLA inference at 3–5 Hz, 0.33 seconds per single-timestep action on an NVIDIA A100, recommended control frequency 5–10 Hz ↩

8. π0: A Vision-Language-Action Flow Model for General Robot Control (Physical Intelligence) and arXiv 2410.24164. Action chunks up to 50 Hz, executing at 50 Hz at inference ↩

9. OpenVLA-OFT (project page). 77.9 Hz throughput via parallel decoding and action chunking, 26x faster action generation and 3x lower latency ↩

10. Milind S's post (September 18). On-device vision model plus OCR turning the screen into text, about 90 ms per decision, as reported by the author ↩

11. How to build with TypeSafe (TypeSafe AI Docs) and Classifying RAG passages (TypeSafe AI Cookbooks). "Code handles deterministic work and owns the control flow…", thresholds held as constants in one place, and "Nothing here is a security boundary." ↩ ↩² ↩³

12. Confidence (TypeSafe AI Docs). High means act, medium means proceed carefully, low means "Do not act. Route to a human, request clarification, or fall back to a different system." ↩

13. Same as note 1 (Doom demo). The post is Diogo Almeida's (September 16) ↩ ↩²

14. atomic.chat's post (September 18). The 330 ms cadence, 25 of 26 runs survived and sub-cent cost are the author's reported figures ↩

15. Wuyang Zhou's post (September 18) ↩

16. Justin Schroeder's post (September 17) and the repository. Up to four decisions per second in a browser driving simulator, with emergency braking handled separately, per the repository description. Not a real vehicle and not a safety claim ↩

17. Jev 1.13 jaggedness (TypeSafe AI Docs). Literal interpretation, weakness at arithmetic, counting and date comparison, degradation with irrelevant context ↩

18. Introducing System One Models and Jev (Hacker News, September 2026); the valid-but-wrong point is raised in that thread and in The Register (September 16, 2026) ↩

19. ISO 10218-1:2025 (ISO), ISO 10218-2:2025 (ISO), Updated ISO 10218 FAQ (Association for Advancing Automation). Both parts published January 2025, the first major revision since 2011, absorbing ISO/TS 15066, clarifying functional safety and adding cybersecurity requirements; Part 1 grew from 50 to 95 pages ↩