Question 1

Is the model actually making the decisions, or decorating a local policy that decides anyway?

Accepted Answer

The model picks, but from a short menu the code generated. The simulation owns geometry, physics and candidate generation; Jev answers a choice question over up to 14 option ids and the top probability becomes the player's intent. The README's own measurement is that Jev's pick matched the local policy's pick 44% of the time, and 30% of the time on the ball. Meeting a pass, keeper saves, first touch, restarts and offside avoidance never reach the model at all.

Question 2

What happens when the API is slow, rate-limited, or I have no key?

Accepted Answer

A late answer — 0.9 s, or 0.45 s for the ball carrier — a rate limit, or a failure drops that player to the built-in local policy, which scores the same candidates with utility plus softmax. With no key in .env all 22 players use the local policy and nothing is sent anywhere. The HUD labels every decision JEV, LOCAL or RULE so you can see which happened, and ?local=1 forces local mode even with a key configured.

Question 3

How much does a match cost, and does speeding the match up cost more?

Accepted Answer

The measured run was 70 calls for $0.0051 over 30 match-seconds, roughly $0.01 per match-minute, at about 1,700 billed input tokens per call with output free; the first version of the payload cost $0.042 per match-minute before the wording was compacted. Because decisions fall due in match time, a faster match means more calls per real second. The control strip shows the session total from the token usage Jev reports.

Question 4

Where does the API key live, and does the browser talk to TypeSafe directly?

Accepted Answer

No. The key sits in a gitignored .env and is read by the dev server middleware; the browser posts candidate tables to a local /api/decide endpoint which validates them, builds the Jev payload and keeps the key server-side. The README warns never to use a VITE_ variable for it. In hosted mode the key stays in the Worker, signing in only exists to spend Jev credit, and spending is tracked in a per-user ledger under a global daily cap.

Question 5

How often does each player decide, and how do you batch that?

Accepted Answer

Cadence is in match time: the ball carrier every 0.30 s, players within 15 m every 0.55 s, everyone else every 1.2 s, with a change of possession pulling everyone in on a small stagger. All due players go into a single POST /v1/systemone call, up to 10 questions per batch and at most 2 requests in flight, so a faster match clock means proportionally more requests per real second.

Question 6

Can I take over and drive a player myself?

Accepted Answer

J takes control of a player and hands it back, defaulting to the home striker or whichever player you have focused. W A S D or the arrows move relative to the camera, Shift sprints, Space passes, F or Enter shoots, Q switches to whoever is nearest the ball, C cycles the camera and P pauses. Click a player on the tactics board or a row in the Jev feed to focus them.

Question 7

Can I see exactly what the model was asked?

Accepted Answer

Yes. The { } button opens an under-the-hood panel with the exact Jev payload of the last batch, the response, every player's latest decision, the full match state and session telemetry, updating at 4 Hz with Freeze, Copy and Download. Outside that, K cycles decision arrows between all options, chosen only and off, and the Jev feed rail logs minute-stamped decisions with a JEV, LOCAL or RULE badge and the latency.

Jevball

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev guides

From the Jev community