Analyzed and improved game API usage limits
Analyzed and improved game API usage limits
Agent
Codex
Model
GPT 6 Astra
Started
Oct 8, 3:44 AM
Messages368
Downloads0
Workspace
Traced data sent to Jev each turn.
UnderstandRecommended improvements to API limits.
PlanDoubled API request limits and updated messaging.
EditConfirmed changes with tests and live gameplay.
Verifywhat are the unit economics of this game? Like are we just sending the state of the whole board and each snake every sincle move to jec?
I’ll trace what gets sent to JEC each turn and check how that affects the cost per game.
Yes—every snake move makes a separate Jev API call. But we send a small decision summary, not the whole board or all snakes.
Here’s the current flow:
That’s in buildQuestion(). Each request is independent; we resend the instructions and summary every time. Moving the apple itself doesn’t trigger a call.
I tested one real starting-position request: 591 input tokens, about 1.1 KB of JSON, 232 ms round-trip. Jev currently charges $0.042 per million input tokens; output is free. Official pricing
Using that measured token count:
| Usage | Estimated model cost |
|---|---|
| One snake decision | $0.0000248 |
| One 60-second round | $0.0165 |
| One 10-minute round | $0.208 |
| 1,000 rounds lasting 60 seconds each | $16.55 |
These estimates assume the fastest configured pace: one decision every 210 ms per snake, with snake two spawning at 15 seconds and snake three at 25 seconds. Three snakes generate up to 14.3 requests/second. Slower responses reduce that rate; actual tokens vary. Hosting is additional.
A few details matter:
So the current model cost is roughly 1.7 cents per minute-long round. The clearest cost reduction would be letting local code handle forced moves and asking Jev less frequently for pursuit decisions.
seems quite efficient how do u recommend we improve ?
seems quite inefficient.. how do u recommend we improve?
Yes—the inefficiency is asking Jev to make a tiny decision every 210 ms when our code has already calculated the best routes.
I’d change it in this order:
Let code execute movement; let Jev choose tactics. Every 1–2 seconds, ask Jev whether each snake should chase directly, intercept the apple, or approach from another direction. Local pathfinding executes that tactic between calls. That gives the model a more meaningful job.
Get all three snakes’ tactics in one request. Share the apple’s position/history once and request a tactic for each snake. This also lets them coordinate instead of independently chasing the same target.
Reconsider tactics when something meaningful changes. A blocked route or sustained change in the apple’s direction can trigger an earlier decision, with a cooldown. Ordinary movement doesn’t need another request.
Handle forced moves locally. If only one direction is legal, there’s no decision for Jev to make. Skip that call immediately.
At three snakes, that changes up to 14.3 requests/second into roughly 0.5–1 request/second, plus occasional replanning. That’s 93–96% fewer requests before those extra calls. Token savings would be smaller because each request covers more information; we’d measure them rather than assume the same percentage.
I’d also move cost accounting onto the server so aborted browser requests still get counted, and track cost per active player-minute.
My recommendation: coordinated Jev tactics once per second, smooth local movement between decisions. It should make the snakes feel faster and more deliberate while reducing cost. We’d update the game’s description to “Jev directs the snakes,” since individual steps would then be executed locally.
i dont get it.. pls explain
Right now, we’re doing this for every step of every snake:
Our code: “Going right is the shortest route to the apple. Up and down are longer. Which way?” Jev: “Right.”
Then we pay to ask almost the same question again 210 milliseconds later.
I’m suggesting we ask Jev for a plan that lasts several steps:
Jev: “Snake 1, chase the apple. Snake 2, move ahead of where the apple is heading. Snake 3, approach from above.”
Our code would move the snakes toward those targets. About once a second, Jev would see what changed and update the plan.
Think of Jev as a coach: give instructions, let the players act, then adjust. Currently, the coach has to approve every footstep.
That means fewer paid requests, smoother movement without waiting for the internet each step, and potentially better teamwork between snakes. The tradeoff is that Jev would choose their strategy rather than every individual move.
awesome, yes implement this
I’ll have Jev choose coordinated targets once a second, with local pathfinding moving the snakes between updates. I’ll also update the inspector to show those plans and track usage on the server.
Jev will choose one complete team plan: direct pursuit, interception, or approaching from opposite sides. That keeps the snakes coordinated in a single request. Local code will keep their steps legal and adjust their targets as the apple moves.
The planning and movement loops are now separate, and the inspector shows each snake’s assigned tactic. I’m testing pause/resume, newly spawned snakes, and slow responses to make sure they don’t cause stale plans or extra requests.
Live Jev requests are working with the new format. A sampled three-snake plan used 1,019 input tokens; at one plan per second, that projects to about 88% less model spend than the old maximum pace.
Server tests also confirm that completed API responses are counted even when the browser cancels its request. I’m finishing the browser checks now.
The browser check confirmed one team request per second through the third snake’s arrival, with local movement between plans. Pause/resume also stopped and restarted planning correctly. I’m checking the remaining failure cases and the mobile layout before restarting the local game.
Implemented—refresh the game.
At three snakes, that’s roughly 93% fewer requests and 88% lower estimated model cost, based on sampled token usage.
All 20 tests passed, plus browser checks for three snakes, pause/resume, slow responses, restart, errors, and mobile layout.
the game does not seem smart.. like the snakes just seem to be following the exact moves im making but delayed right?
I’ll check how the snakes track the apple between plans to see why they feel like delayed followers.
Yes, that’s largely what you’re feeling. I checked the code: they chase your current position every 210 ms, which can look like following your moves with a delay.
The “smarter” behaviors are quite shallow:
I reduced the cost, but overstated how much smarter the snakes would become.
The useful next improvement is planning around your escape routes: one snake pressures you, another heads toward somewhere it can reach before you, and the third blocks another exit. They should commit to those positions briefly instead of shifting their targets with every apple movement.
We can calculate arrival times and possible escapes locally, then let Jev choose between those stronger plans at the same once-per-second rate.
do u think thats a good idea?
Yes—better local planning is the right next step, especially for three snakes.
I’d start with two concrete changes:
That should make their decisions feel more deliberate without increasing API calls. We should test whether you actually see snakes cutting you off, rather than just making the game harder through speed.
Jev’s value is still something to prove. Local code can handle much of this strategy itself; we should compare its automatic choice against Jev’s choice. If Jev doesn’t make the game more interesting, keeping it in every planning cycle wouldn’t be justified.
ok go ahead and implement
I’ll add interception based on arrival times and give the snakes distinct roles that they hold briefly. I’ll keep Jev’s planning rate at once per second and test whether the new behavior actually cuts off escape routes.
The current “intercept” target is just an offset from the apple. I’m replacing it with reachable cutoff squares, using your recent movement speed to estimate whether a snake can arrive first. Those targets will stay fixed for a short time, so turning won’t immediately drag every snake behind you.
The new planner now checks several possible escape routes and assigns different ones to the supporting snakes. A snake that arrives early can wait at its cutoff square. If it can’t reach a cutoff in time, it keeps chasing rather than taking an unhelpful detour.
A targeted test now shows the difference: a snake to the side of a running apple cuts across and catches it, while the old chase behavior falls behind. The tests also confirm that cutoff targets stay fixed through a turn and that supporting snakes cover different routes.
I compared Jev’s choices with a local selector in five short scenarios. Both used the new interception successfully; that small test doesn’t yet establish an advantage for Jev.
All 33 tests passed, along with the browser checks for three snakes, request timing, pause/resume, slow responses, and restart. The snakes’ speed is unchanged; the improvement comes from choosing and holding better positions. I’m restarting the local game with the update now.
Implemented—refresh the game.
Speed and API frequency are unchanged.
All 33 tests and browser checks passed. A targeted scenario confirmed interception catches a running apple that ordinary chasing misses.
nah this is not good because now some snake/s randomly stop... any idea why?
Yes—that’s caused by the ambush behavior I added. When a snake reaches its cutoff square early, the code tells it to wait there until the plan changes or expires. Without a visible explanation, that looks like it randomly froze.
That was a poor fit for this game. Snakes should keep moving. I’d remove waiting and make cutoff squares waypoints: reach one, then immediately turn toward you or continue cutting across your escape route. We can keep interception and coordinated roles without the stops.
yeah do that
I’ll remove the ambush stops so a snake keeps pursuing after reaching its cutoff square, then check that interception and coordination still work.
Snakes now continue toward you as soon as they reach a cutoff, and remember that the waypoint is complete so they don’t circle back. I also removed the initial pause while a new snake waits for its first plan. All 33 tests pass; I’m checking the movement in the browser now.
Done—refresh the game.
Snakes now keep moving after reaching cutoff points and while waiting for their first plan. Interception and coordinated roles remain.
All 33 tests passed, plus browser checks confirming continuous movement.
the strategy with highest probability seems to be "intercept" always
I’ll check whether the strategy options give Jev meaningfully different choices, or whether the prompt is steering it toward “intercept.”
I found a problem with how I built the choices: different strategy names can produce exactly the same behavior.
In a three-snake test, Contain, Intercept, and Left/right all assigned the same targets to the same snakes. Only Top/bottom differed. The prompt also encourages cutting off escape routes, which may favor the “Intercept” label.
So those probabilities aren’t a reliable sign that Jev is choosing between distinct strategies. They show its preference among the options we supplied—not measured chances of catching you.
The fix is to give it genuinely different plans, remove duplicate options, and make the instructions neutral. That would make both the choices and the probability display more meaningful.
cool do that
I’ll make the strategies produce distinct plans, remove duplicates before asking Jev, and make the prompt neutral. I’ll also update the probability display to show only the options Jev actually received.
The options are now distinct: Pursuit tracks the apple directly, Intercept chooses reachable cutoff points, and the two directional plans cover only their named directions. Any plans that still produce identical assignments are removed.
Jev receives anonymous option IDs, and if only one plan remains, the game runs it locally without showing an invented probability.
Live checks returned both Pursuit and Intercept choices with the new options. The browser also correctly hides removed options and shows no probability bars when a plan runs locally.
All 38 tests passed. I’m restarting the local game so you can try it.
Done—refresh the game.
Live checks selected both Pursuit and Intercept. All 38 tests and browser checks passed.
so how are we using jev?
Jev chooses the team’s plan; our code executes it.
About once per second:
If only one distinct plan is possible, we skip Jev.
So Jev’s current role is fairly narrow: selecting among strategies we designed—not inventing strategies or controlling every move. Most of the game intelligence is now local code. We haven’t established that Jev’s selections outperform the local selector.
u have cloudflare wrangler access.. could u deploy this app? I just got a new domain notsnake.com that u should see in cloudflare
I’ll check your Cloudflare account and the new domain, then adapt the app for Workers and deploy it to notsnake.com. I’m using the Cloudflare, Wrangler, and Workers best-practices skills for the deployment.
notsnake.com is active in your Cloudflare account, and there’s no existing Worker attached to it. I’ll serve the game through Workers, store the Jev key as a secret, and add request limits for the public API. I’m also using the Durable Objects skill to preserve the game’s shared usage counters across server instances.
The domain is ready. I’m finishing the Workers setup with a server-side Jev secret, persistent usage totals, and request limits, then I’ll test the game on the live URL.