# I gave Jev a paddle. Can you beat it?

I gave Jev, TypeSafe's decision-making AI model, a paddle and placed it on one side of a Pong court. Its opponent is you. The rules are simple: keep the ball in play and be the first to score seven points. But Jev is not following a traditional game script. As the ball crosses the court, it must repeatedly decide whether to move up, move down, or hold its position. When it reaches the ball, it has more choices to make: return safely, add speed, aim high or low, or save its boost for the next rally. Those small decisions repeat throughout every match. Together, they determine whether Jev keeps up or whether you beat it. You control one paddle. Jev controls the other. While you are trying to read the ball and anticipate the next shot, Jev is doing the same thing through a continuous stream of structured decisions. ![](https://blog.postman.com/wp-content/uploads/2026/09/jevPong.gif) JevPong lets you play against Jev while inspecting the decisions behind its movement and returns.

## Meet your opponent

 Jev is TypeSafe's first System One model. Unlike a general-purpose language model, it is not designed to generate paragraphs, write code, or explain a long chain of reasoning. It is designed to make fast, focused decisions that software can use directly. You give Jev the current state, define a bounded question and its possible answers, and get back a typed decision with probabilities and confidence. That makes it a good fit for a game like Pong. The game does not need Jev to describe where the paddle should move. It needs Jev to choose one of three actions: - Move up
- Move down
- Hold position
 
 The larger behavior emerges by combining many small decisions in code. Jev exposes three question types: - Choice selects one option from a defined set.
- Score evaluates the state against an ordered rubric.
- Noul returns the probability that the answer to a yes-or-no question is true.
 
 Several questions can be evaluated independently against the same state in one request. That becomes useful once Jev needs to do more than follow the ball. ## How Jev plays

 At the beginning of a match, you choose Easy, Medium, or Hard. Then you move your paddle, return the ball, and try to reach seven points before Jev does. Jev receives a snapshot containing the information it needs to play: the ball's position and velocity, both paddle positions, the score, its current strategy, boost availability, movement limits for the selected difficulty, the engine's predicted interception point, and measured latency. From that state, Jev answers four questions together: 1. Where should the paddle move: up, down, or hold?
2. What return style fits the moment: safe, angled, or fast?
3. Where should the next shot go: upper, center, or lower?
4. Should it use a boost?
 
 The game engine takes those answers and applies them within the rules of the match. On Medium and Hard, shot placement becomes part of Jev's strategy, so reaching the ball is only half the problem. It must also decide what to do with it. Beside the court, the Decision Monitor shows the action Jev selected, the probability assigned to every option, its confidence, request latency, and any fallback the game used. The point is not only to play against the agent, but to watch its behavior emerge one decision at a time. ## Inside the decision loop

 The TypeSafe API is deliberately small. `POST /v1/systemone` evaluates a state against one or more questions, while `GET /v1/models` lists the available model names. A simplified movement request from the game looks like this: ```
{
  "state": {
    "ball": { "x": 320, "y": 145, "vx": 6, "vy": -3 },
    "paddles": { "self": 160, "opponent": 210 },
    "score": { "self": 3, "opponent": 4 },
    "difficulty": "medium",
    "boostAvailable": true,
    "predictedIntercept": 138,
    "latencyMs": 42
  },
  "questions": [
    { "id": "move", "type": "choice", "options": ["up", "down", "hold"] }
  ]
}

```

 Jev returns the selected option, a probability for each available action, and its confidence in the decision: ```
{
  "answer": "up",
  "probabilities": { "up": 0.82, "down": 0.11, "hold": 0.07 },
  "confidence": 0.82
}

```

 The complete response also includes the resolved model version and token usage. The game does not pause while it waits for that response. Physics continues running in the browser while a separate decision loop sends snapshots to Jev. The latest accepted action controls the paddle for a short window. If a decision arrives too late, has low confidence (below 5 percent), or no longer matches the state of the rally, the engine can discard it and use a visible fallback. This separation keeps the match responsive while still making Jev responsible for the meaningful choices. It also makes latency part of the game. A good decision that arrives too late may no longer be useful. ## From a game experiment to a shared service

 Once JevPong worked, the next question was operational: should every experiment that uses Jev manage its own provider credentials, routing, access, and telemetry? For this game, the answer was no. Instead of calling the TypeSafe API directly, the game backend sends its requests through **Postman Fabric Gateway**. Fabric routes the request to Jev and keeps the upstream provider credentials behind the gateway. The request path is straightforward: ![](https://blog.postman.com/wp-content/uploads/2026/09/mermaid-diagram.png) Fabric gives us a shared place to manage the route and observe how it is being used. We can inspect activity through analytics, audit logs, health information, and traces without building a separate operational layer into every experiment. ![](https://blog.postman.com/wp-content/uploads/2026/09/image-20260922-212341-scaled.png) Jev is exposed to the game through a managed Fabric route rather than a provider credential embedded in the application. ![](https://blog.postman.com/wp-content/uploads/2026/09/image-20260922-212907-scaled.png) *Fabric provides a common view of request volume, latency, errors, and usage across the route.* This is a small game, but the architectural pattern is useful beyond it. Another application can reuse the same governed route without creating a separate provider integration or distributing another set of credentials. The application gets a consistent endpoint, and the team gets a consistent place to route, govern, and observe the traffic. ## Can you beat Jev?

 Reading about the game is one thing. Beating Jev is another. Choose Easy, Medium, or Hard and race to seven points. If you win, your completion time is added to the global leaderboard for that difficulty. Easy is the place to learn the rhythm. Medium gives Jev more influence over its returns. Hard is where the leaderboard gets serious. How quickly can you read the ball, adapt to Jev's returns, and close out the match? [Play JevPong](https://jevpong-production.up.railway.app/) Beat Jev, claim your place on the leaderboard, and then try the next difficulty. If you want to explore the infrastructure behind the game, you can also [try Postman Fabric Gateway](https://app.fabricgateway.ai?utm_source=jev_blog). ## Resources

- [Play JevPong](https://jevpong-production.up.railway.app/)
- [Check it out on GitHub](https://github.com/Postman-Devrel/JevPong)
- [Get Started with TypeSafe's Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev)
- [Try Postman Fabric Gateway](https://app.fabricgateway.ai?utm_source=jev_blog).