Jev on Atari Pong

Most models are built to talk to people. Jev, TypeSafe’s first System One model, is built to answer software.

You send a state plus typed questions. Jev returns values your code can branch on—choices, scores, yes/no probabilities—with calibrated confidence. No prose to parse. Three primitives can mix in one call and evaluate in parallel: Choice, Score, and Noul.

That shape fits places where an LLM is the wrong tool in the middle of a loop: smart if-statements, intent routing, confidence-gated handoff, LLM guardrails, RAG filtering, and real-time control. Doom and Wikiracing are the same idea—narrow questions over state; code keeps the policy.

I’m trying the same idea on Atari Pong as a policy-shaped controller: the “policy” is not weights inside Jev—it is the question definition (instructions + closed criteria) that turns observation into the next action. Gameplay is the environment; when the paddle misses, the interesting update is not “prompt harder,” but revise the question so the next episode behaves better.

Here is the Choice that finally stopped missing the ball. One rewrite of this structured question went from failing to hit to scoring 1 and losing 0 in a 33-second run:

{
  "next_action": {
    "type": "choice",
    "instructions": {
      "question": "Which action should vertically align the player paddle with the ball now? Read the objects with id player and ball in `observation.objects`. A bbox is [x, y, width, height]; its vertical center is y plus half its height. Larger y means LOWER on the screen. If the ball center is more than four pixels BELOW the player center, choose LEFT, which moves the paddle DOWN. If the ball center is more than four pixels ABOVE the player center, choose RIGHT, which moves the paddle UP. If the centers are within four pixels, choose NOOP to avoid moving past alignment. If the ball or player is absent, choose NOOP. The player being on the RIGHT side of the screen is not a reason to choose RIGHT. Likewise, a ball moving horizontally right does not imply that the paddle should move up. Judge the vertical gap, not the horizontal direction. Prefer the non-FIRE option when a FIRE alias would produce the same vertical movement. Act for only the next requested duration, then reconsider using the next observation.",
      "read": "`observation.objects`, `observation.history` and `observation.candidate_actions`",
      "coordinates": "x increases right; y increases down. Follow the action effect descriptions, not the direction implied by joystick names."
    },
    "criteria": {
      "NOOP": "hold movement of the RIGHT paddle for 4 raw frames (action 0).",
      "FIRE": "hold movement of the RIGHT paddle for 4 raw frames (action 1).",
      "RIGHT": "up movement of the RIGHT paddle for 4 raw frames (action 2).",
      "LEFT": "down movement of the RIGHT paddle for 4 raw frames (action 3).",
      "RIGHTFIRE": "up movement of the RIGHT paddle for 4 raw frames (action 4).",
      "LEFTFIRE": "down movement of the RIGHT paddle for 4 raw frames (action 5)."
    }
  }
}

Next loop: treat this as reinforcement learning over question text. A teacher model (I’m using Astra) reads the episode—misses, near-misses, score events—and proposes edits to the question and criteria. Jev keeps answering in the real-time loop; Astra only rewrites the policy surface between runs. If System One rewards atomic questions, the product experiment is whether a stronger reasoner can improve those questions from play.

Docs: TypeSafe introduction. Launch note: System One & Jev. Watch the run on X →