C_W
Contact

◄ NotesExperiments5 min read

JEV, tiny models and strange new interfaces

I gave a fast decision model a computer from 1999, the 1978 Oregon Trail and a Bitcoin order book. What it did, and what interfaces without chat look like.

Most of what we call AI today arrives as a conversation.

You type, it answers. The model produces text, and everything else, tools, agents, structured output, gets built on top of that text.

Jev is a different kind of thing, and playing with it is a good way to think about where models can sit inside software.

What Jev is

Jev is a model from TypeSafe. They describe it as a System One model: built for decisions inside software rather than for conversation.

You don’t send it a prompt and get prose back. You send it structured state and a question with a fixed set of options, and it returns a typed choice with probabilities for each option.

A decision looks roughly like this:

const result = await client.systemOne({
  state: { objective, computer, availableActions },
  questions: {
    action: choice("Choose the best available action.", criteria),
  },
});

It is also cheap and fast. TypeSafe prices it at $42 per billion input tokens, and their own demo shows a decision in about a tenth of a second.

When I say tiny in the title, that is what I mean: tiny per decision, in cost and in time. I don’t know how big the model actually is. What matters for the experiments is that you can afford to ask it something every half second, for hours.

That changes what you can build.

I gave Jev a computer from 1999

One experiment is JEV/98: a small simulated late-90s computer in which Jev chooses every action.

Every ~650 ms the loop runs:

  • the simulated computer changes state,
  • Jev sees that state and a finite list of legal actions,
  • Jev chooses exactly 1 of them,
  • the interface shows the full probability distribution,
  • ordinary deterministic code applies the consequence.

There are 3 missions. Get online and download a file without infecting the machine. Identify a suspicious sender and delete the attachment. Finish a download before Mom needs the dial-up phone line.

The important design choice is that Jev can’t do anything the code doesn’t allow. It is not a chatbot wearing a beige-computer skin. There is no way for it to invent a command, break the fourth wall or talk its way out of the simulation. The code defines the action space. The model only chooses within it.

Everything is recorded: the selected action, the top probabilities, whether the answer came from the live model or a local fallback, and the latency. A run can be shared as a replay link that plays back the recorded decisions without calling the model again.

If there is no API key, a simple heuristic plays instead, and the interface labels it DEMO POLICY. No fake model results.

I gave Jev dysentery

JEV/78 does the same thing with the 1978 Oregon Trail.

The original is a BASIC program, and JEV/78 is not a wrapper that sends keystrokes to it. The rules are rebuilt in the same shape as JEV/98: one function returns the available actions, another advances the state. Jev chooses every legal wagon action. The world is seeded, so a death can be replayed.

Some things didn’t fit. The famous TYPE BANG shooting minigame is about reaction time, not decisions, so Jev doesn’t play it: its rifle skill becomes a roll. Shop and fort amounts are bucketed so the set of choices stays finite.

That last constraint turns out to be the whole trick. Once the choices are finite and explicit, a model can operate a system safely and legibly.

I gave it money, on paper

Games are forgiving. Markets are not.

I also built a lab to test whether Jev had any short-horizon trading value on the Hyperliquid Bitcoin perpetual. Same pattern: normalised market state in, buy, sell or hold out, with probabilities, and deterministic code deciding whether anything actually happens.

The answer was no.

Across about 2,100 decisions at a 30-second horizon, its signal was indistinguishable from noise once the sample was large enough, and never within an order of magnitude of the cost of trading. Longer horizons, maker orders, regime classification and daily news briefs didn’t rescue it either.

Two details stayed with me.

First, in the early runs Jev’s own estimate that a trade would be profitable after costs never went above 0.51. It had no edge, and in a sense it knew.

Second, the wording of the question mattered enormously. Changing the phrasing moved its trade rate from 3% to 70% of decisions on identical market states. Within one test window, prose briefs beat JSON dumps. Verbose you are a risk manager instructions added nothing. I ended up writing a house style for questions, because otherwise experiments weren’t comparable with each other.

Jev is documented as weak on raw numbers, so none of this is a verdict on the model. It is a verdict on one use of it. Structured yes-or-no decisions look like a much better fit than predicting prices.

Strange new interfaces

The part I find most interesting isn’t the trading result. It’s what these experiments look like on screen.

There is no chat box. You don’t talk to the model. You watch it.

The interface is the state of the world, the list of things that can happen next, and a probability bar for each option. You can see the model hesitate between 2 choices. You can see it become confident. You can replay a run and see exactly where it went wrong.

That feels closer to how we might want software with a model inside to behave generally:

  • The action space is the interface. What the model may do is visible, not hidden in a prompt.
  • Uncertainty is shown, not hidden. Probabilities are more honest than a fluent paragraph.
  • Decisions are replayable. You can inspect a past choice with exactly the inputs it had.
  • The model is a component, not the product. Deterministic code owns the consequences.

Chat is a wonderful interface for open-ended questions. It is a strange interface for a system that should make 1 of 5 known choices 100 times a minute.

Open questions

I don’t know yet where the useful applications are.

Games and simulations make the pattern easy to see. The JEV/98 notes already list a virtual railway dispatched by the same decision API, and eventually physical hardware. Whether that is useful or just fun is part of the question.

The bigger question is where fast, cheap decisions inside software beat either hand-written rules or a large model reasoning in text. My guess is routing, gating, triage and control loops, anywhere the choices are known and the cost of asking needs to be close to zero. The trading lab is also a reminder that a one-line rule is sometimes just as good.

And I’m curious what happens when interfaces like these become normal. When the model is not something you talk to, but something you can watch deciding.

That seems like a strange new interface worth building more of.