Researched 'jev' and updated snake game UI
Researched 'jev' and updated snake game UI
Agent
Codex
Model
GPT 6 Astra
Started
Oct 7, 11:52 PM
Messages321
Downloads0
Workspace
Checked local project folder and found it empty.
UnderstandResearched 'jev' product and reviewed documentation.
UnderstandVerified gameplay and test results.
VerifyUpdated UI to show all active snakes in side panel.
EditRemoved sentence from game-over message.
Editare you familiar with jev
I’ll take a quick look at the project so I can answer in context.
Not yet—your local jev folder only contains an empty .env, so I don’t have project context. Is Jev something you’re building, or an existing product?
nope, it's an existing product please look it up and read the docs and all
I’ll look up Jev, find its official docs, and read through how it works.
Found it: Jev is TypeSafe AI’s model for typed decisions. I’ve read the core concepts, confidence calculations, model limits, and documented weaknesses; I’m now checking the SDKs and workflow examples. One useful distinction: its confidence field summarizes the answer’s probability distribution—it isn’t a separate guarantee of correctness.
Yes—I'm familiar with it now. I read TypeSafe’s official docs covering Jev’s core concepts, API, Python/TypeScript SDKs, confidence, workflow patterns, and known limitations.
Jev makes small, structured decisions inside software. You send application state plus explicit questions, and get typed answers your code can act on. Official introduction
It has three primitives:
| Primitive | What it returns | Example |
|---|---|---|
| Choice | A selected option, probabilities, and confidence | Which team handles this ticket? |
| Score | A position on your descriptive scale, probabilities, and confidence | How severe is this bug? |
| Noul | Probability that a statement is true | Does this message request a refund? |
You can mix all three in one request; questions run independently against the same state. API reference
The main design pattern is to ask narrow questions together, then combine their answers in code. That supports routing, classification, ranking, document checks, and extraction where code supplies candidate values. Your application controls the workflow and actions. Building guide
A few details that matter:
jev-1.13.0; jev-latest currently resolves to it.I have the integration details in context now, though I haven’t run live API calls.
what are some fun examples theyve shared or some cool things people have built using jev or integrated jev into ?
I’ll look through TypeSafe’s demos and community projects for the more interesting examples, with links to the actual builds.
The more playful builds include Doom, Pokémon, a driving simulator, and a platformer that builds the terrain ahead of you. I also found practical integrations for browser automation and removing page clutter; I’m checking the authors’ descriptions to see exactly what Jev does in each.
Yep—there are some fun ones. These stood out after checking the original demos and project repos:
Doom that follows instructions — TypeSafe’s own demo.
Jev plays Doom from structured game state, making roughly ten decisions per second. The interesting part is being able to change its behavior through instructions while it plays. TypeSafe explicitly notes that a conventional Doom bot could play better. Watch their launch demos.
Wikipedia racing — also from TypeSafe.
Give it a starting article and a destination, and it navigates using only links on each page. When there are too many candidates, it scores links first, then chooses from a shortlist. A neat example of turning navigation into repeated small decisions. Demo and explanation.
A platformer that builds the level ahead of you.
Sprite Fusion’s Hugo Duprez built a neon ninja runner where Jev chooses upcoming platform widths, gaps, heights, and surface types from the current game state. The game code places the tiles. His recorded demo had 319–375 ms API latency, fast enough to keep generating terrain as the player moves. Demo and walkthrough.
Pokémon Red, played through to the end.
Christian Mathiesen’s project reports finishing in 37 hours 40 minutes for about $1.65 in Jev calls. The surrounding code reads game memory, supplies legal options and navigation support, and Jev chooses actions. My favorite detail: it names caught Pokémon by choosing letters individually. Code, results, and highlights.
JevPilot: a playable driving simulator.
A Three.js driving demo where Jev chooses among steering-and-speed options using nearby traffic, road boundaries, signals, and destination guidance. Geometry, physics, and collision braking stay in code. You can inspect the candidate paths and Jev’s probabilities while it drives. Project and playable demo.
Browser Use’s fast web agent.
Jev chooses what to do and which page element to act on; a small generative model supplies text when typing is required. Their recorded Google Flights search takes about 7.1 seconds—a measurement of that specific task. Video and implementation.
Unclutter: make noisy websites readable.
Kitze’s browser extension uses Jev to classify page elements such as ads, promotions, and newsletter boxes. It hides clutter reversibly and remembers rules for similar pages, so subsequent visits can work without another model call. Unclutter.
Choosing what a coding agent should forget.
fast-jev-compaction integrates with Claude Code to judge which old tool calls and results remain useful. It drops or truncates stale material and preserves retained content verbatim. An interesting experiment in using Jev to manage another model’s context. Project.
The terrain generator and Unclutter are my favorites: both give Jev a small, concrete decision that immediately changes something you can see.
whats that website that basically allows you to drive a car endlessley in the browser itsself it was pretty cool like no sign up nothing just drive
I’ll look for it—there are a couple of browser driving sites that fit that description.
You’re probably thinking of Slow Roads — slowroads.io.
Endless scenic roads through hills and mountains, right in your browser. No signup or download—just open it and drive.
yeahh.. im trynna make some cool demo.. do u have ideas of anything cool i can make? `like think really outside the box
does not have to be game like..
Yeah—Slow Roads has that “open a link, immediately get it, lose ten minutes” quality. I’d aim for that, with Jev making something react to you.
A few directions I’d actually be excited to try:
A city made from your browser history.
Your browsing becomes a walkable city: research rabbit holes become alleys, recurring interests become neighborhoods, abandoned projects become unfinished buildings. Jev judges relationships between pages; code builds the geography. Start with a pasted list of links.
The moment: discovering that two seemingly unrelated obsessions share a street.
A mirror that reflects your writing personality.
A blank page with a little abstract creature beside it. As you type, it changes posture, movement, and surroundings based on qualities like certainty, tension, warmth, or evasiveness. You could watch an angry email soften as you rewrite it. Jev scores the text; animation code turns those scores into behavior.
The moment: deleting “just following up again” makes the creature visibly unclench.
An aquarium of ideas.
Drop in notes, bookmarks, or shower thoughts. Each becomes a swimming organism. Related ideas school together; contradictory ones circle each other; isolated ideas drift. Jev judges relationships between selected pairs, while a physics simulation handles movement.
The moment: two notes written months apart find each other without you searching.
A camera for invisible things.
Point your phone at a room and switch between lenses like “awkward,” “cozy,” “improvised,” or “things with a story.” A vision model first describes visible objects; Jev judges them against the selected lens, and the interface overlays the results. Treat it as playful interpretation.
The moment: the “improvised” lens lights up your stack-of-books monitor stand.
A website you negotiate with.
The interface is physically rearranged by what you say. “I’m in a hurry” strips it down. “I don’t trust this” brings evidence forward. “I’m buying this for my dad” changes which product attributes matter. Jev chooses among predefined layouts, information priorities, and interaction modes.
The moment: the exact same site visibly becomes a different experience after one sentence.
An argument weather map.
Paste a debate, meeting transcript, or comment thread. It becomes animated weather: agreement forms clear patches, unresolved questions create fog, contradictory claims create storm fronts. Clicking a storm reveals the exact statements causing it. Jev evaluates individual claims and their relationships.
The moment: a furious-looking discussion turns out to contain one tiny disagreement surrounded by consensus.
A soundtrack that follows what you’re reading.
A reading view that mixes an instrumental soundtrack as you scroll. Suspense, intimacy, motion, and emotional intensity control different musical layers. Jev scores upcoming passages; code blends prerecorded stems ahead of time.
The moment: the music drops out just before a quiet, devastating sentence.
A museum of your ordinary objects.
Upload a few photos and short stories about things you own. They become exhibits arranged around themes such as “things I kept too long,” “borrowed identities,” or “evidence someone cared.” A vision model handles photos; Jev selects thematic relationships and placements.
The moment: your chipped mug and an old train ticket end up in the same exhibit, and the connection makes sense.
My strongest picks: the writing creature for something immediately delightful, the idea aquarium for something people keep playing with, and the argument weather map for a demo that could become a useful product.
nah these arent *actually cool.. they're more like basic ideas in a cool wrapper
Fair. I was putting visual themes on classification. The underlying behavior needs to be surprising.
Here are four stronger directions:
1. Give a crowd one sentence—and see whether it can organize itself.
A thousand agents, each seeing only nearby agents and making small decisions. Tell them:
“Form a portrait of a face. Nobody can see the whole picture.”
“Evacuate this building, but everyone thinks a different exit is blocked.”
“Half of you are secretly trying to prevent consensus.”
No scripted global choreography. Jev selects local actions; code handles movement and communication. The experiment is whether coordination emerges—and where it breaks. You’d call Jev at decision points, with ordinary simulation running between calls.
2. A browser automation race where you can sabotage the interface live.
Give an agent a task. While it works, drag buttons around, rename labels, insert popups, switch languages, or change the page layout.
It has to keep finding the right action from the current controls. Show a conventional scripted automation beside it breaking on the first change.
The demo has a built-in challenge: “Can you confuse it without making the task impossible?” Jev handles semantic action selection. Start with a controlled website so you can change it aggressively and verify whether it actually succeeds.
3. An AI that tries to exploit rules you invent.
You create a little economy: coupons, loyalty points, refunds, inventory, transfers. Write the rules in plain English, then press “Find the exploit.”
Agents start attempting sequences of legal actions:
Buy with a discount → refund for store credit → stack the credit with another promotion → repeat.
You watch the balance change and get a replay of the exact exploit. Patch a rule and run it again.
A generative model proposes strategies; Jev evaluates lots of narrow semantic conditions; deterministic code owns balances and transactions. It could also fail to find anything—the demo should make that visible. This one has potential beyond the demo.
4. Teach your computer a task once, then give it unfamiliar versions.
You demonstrate moving one event from an email into a calendar. Then hand it ten wildly different emails and a redesigned calendar interface.
It must infer which details and actions matter, identify their equivalents, and perform the task in a sandbox. You can interrupt with corrections like:
“That’s the registration deadline, not the event date.”
A larger model turns the demonstration into a reusable task specification; Jev handles repeated choices against new inputs. The compelling test is how far it generalizes before you need to teach it again.
My pick is the rule exploiter. There’s a real reveal: you believe you designed a closed system, then you watch something discover a loophole you missed. The browser sabotage demo is the clearest way to show Jev itself doing something impressive.
something that can be used in a chrome extension maybe?
Yes—give the browser a new capability, something you can demonstrate on a website people already use.
These three feel stronger:
1. “Select all that…” — semantic selection anywhere
Press a shortcut and type:
“Select the GitHub issues that already have a workaround.”
“Select apartments where the second bedroom sounds like a converted living room.”
“Select comments that found an actual bug, excluding feature requests.”
The extension selects matching items directly on the page. You can inspect the matches, then use the website’s existing bulk actions—or copy, compare, or export them.
Jev evaluates each item against your condition. The extension maps answers back to real page elements.
The demo: open a page with 200 items, describe a category the website has no filter for, and watch the right items light up. It adds a useful operation to existing software.
2. “Do this to the others” — automation by demonstration
You perform an action once, then tell the extension which other items it should apply to.
For example, you move one support ticket to a particular queue, then say:
“Do that for the other tickets where an update broke something that previously worked.”
The extension previews matching tickets and the action it will repeat. You approve the batch and watch it execute.
Recording captures the interaction; Jev judges which items qualify and identifies equivalent controls. A larger model could interpret the demonstration when necessary.
The demo: teach it a workflow in ten seconds, then let it handle twenty variations. I’d start with one supported app so this works convincingly.
3. A research browser that follows a question across links
You’re browsing apartment listings and ask:
“Find evidence that noise is a problem in these buildings.”
The extension explores relevant reviews and linked pages in the background, filters evidence, and attaches exact excerpts to each original listing. Same mechanism for:
“Which of these libraries has maintenance problems?”
“Which hotels have complaints about Wi-Fi specifically from people working remotely?”
A search/retrieval layer finds candidates; Jev makes the repeated relevance, identity, and evidence judgments. Every finding links to its source.
The demo: five ordinary tabs become a comparison with information those pages didn’t provide themselves.
I’d build the first one. It has a clear interaction, Jev does the core work, and the extension adds something you could use several times a day. Start with GitHub issues: “select reports that describe the same underlying bug, even when the titles sound unrelated.”
some more
A few more—with a concrete interaction in mind:
A spoiler shield that knows where you are.
Tell it “I’m on episode four” or “I’ve only played through this chapter.” It checks incoming posts, thumbnails’ text, and comments against a supplied knowledge boundary, then covers potential spoilers before revealing them. You can still browse discussions about the parts you’ve seen. Jev judges whether text reveals something beyond your progress; getting reliable story context is the harder part.
Catch contradictions between your open tabs.
Open a product page, documentation, and pricing page. The extension connects conflicting statements: “unlimited projects” here, “maximum ten” there. Click either highlight to see the other claim in context. Extraction finds candidate claims; Jev judges whether they concern the same thing and actually conflict. A live cross-examination of the website you’re reading.
Web monitoring with an actual condition.
Right-click a page and say:
“Tell me when this tool supports local models.”
“Tell me when registration opens to people outside the US.”
“Tell me when this apartment allows a six-month lease.”
It periodically checks relevant text and alerts when the condition changes. The alert shows the before-and-after evidence. Much more specific than “this page changed.”
Copy the thing you mean.
Select a messy page region and type:
“Copy the speakers and their talk titles.”
“Copy the actual ingredients, excluding substitutions.”
“Copy the commands for my operating system.”
The extension identifies source spans and copies them verbatim into a table, list, or script preview. Jev chooses relevant pieces; code preserves the original values and handles formatting. A clipboard that understands what you wanted from the selection.
A browser that remembers why you rejected something.
You dismiss a hotel because reviews mention thin walls. Later, on a completely different booking site, the extension notices the same issue and flags it. Your decisions become explicit, editable preferences that travel across websites.
The interesting interaction: “You ruled out the last one for this exact reason.” It should learn only from reasons you deliberately give it.
“What’s new to me?” mode.
After reading five articles about an announcement, open the sixth and see only passages containing materially new information, corrections, or disagreement. Repeated background fades but remains expandable. Jev compares passages against a compact record of claims you’ve already read. Especially useful for following developing stories or researching a technical problem.
Natural-language breakpoints for browser agents.
Give an automation a task, then set conditions such as:
“Pause if continuing creates a subscription.”
“Pause if the item is refurbished.”
“Pause if the appointment is with a different practitioner.”
The extension checks observed page state before relevant actions and stops with the triggering evidence. Jev handles the semantic checks; explicit code gates control execution. This would need an integration with the automation, so it can actually pause it.
The contradiction detector has the strongest reveal. The rejection-memory idea feels the most personal. “What’s new to me?” is the one I’d want running while researching this conversation.
i like the spoiler thing.. can we build a chrome extension that sensors spoilers on letterboxd ?
I’ll build a Chrome extension that hides potential spoilers in Letterboxd reviews using Jev. I’ll first check how Letterboxd structures its pages and what’s available in this workspace.
<send_user_message_question_reply> [{"answer":"Let me turn spoiler protection on for individual films","question":"What should count as a spoiler on Letterboxd?","questionItemId":"["request_user_input_async","call_936d6e222ded4047ac7de91a3846ef68",0]"}] </send_user_message_question_reply>
Got it—protection will be opt-in for each film. I’ll add a “Protect this film” control on Letterboxd, hide its reviews while Jev checks them, and keep suspected spoilers covered until you choose to reveal them. I also found a JEV_API_KEY in your .env; I’ll use it for a small live test without putting it into the extension files.
Actually, instead.. would it be possible to make a 3js webl type game like slowroads.. but its in a city with traffic lights etc and all the npcs use jev to move around? So they're making somewhat logical moves with very low latency? WOuld that work ?
Yes—this could work, with Jev choosing things like lane changes, turns, and yielding while local code handles steering and braking. I’ll pause the extension work and check the latency and throughput constraints for a city simulation.
Yes—this would work, and it’s a good fit for Jev. A Three.js city you can drive around, with traffic lights, pedestrians, and NPC drivers making decisions based on what’s happening nearby.
There’s already a smaller proof of the approach: JevPilot uses Three.js and Jev to choose driving maneuvers, with decisions requested up to four times per second around traffic. Expanding that to multiple independently controlled NPCs is plausible, though we’d need to measure throughput and behavior. JevPilot
The crucial design is separating decisions from continuous movement:
| Local game code | Jev |
|---|---|
| Steering along lanes, acceleration, animation | Choose a turn, change lanes, wait, or reroute |
| Braking distances and collision checks | Decide whether to let someone merge |
| Traffic-light timing and permitted movements | Choose among currently permitted actions |
| Walking paths and crosswalk boundaries | Choose a destination or react to a disruption |
The game could render at 60 FPS while each NPC makes a new decision only when needed. A car cruising down an empty street continues driving without repeatedly asking Jev.
Latency would be manageable if we design around it. I’d budget for responses taking several hundred milliseconds, with occasional longer delays—not assume every call returns in 100 ms. One published Jev game demo measured 319–375 ms. Measurements
We’d request decisions before an NPC reaches an intersection. While waiting, it continues its existing maneuver. When the answer arrives, code checks that it’s still valid. If a pedestrian stepped into the road in the meantime, local braking takes precedence.
The part that could make this feel alive is giving NPCs different goals and a little memory:
Those would be behaviors we test, rather than assume personality instructions automatically produce believable driving. Jev’s documented weaknesses include numerical reasoning, so distances, path feasibility, and collision prediction should stay in code. Limitations
The main scaling constraint is API traffic. For illustration, 30 NPCs averaging one decision every two seconds at 600 input tokens per decision would cost about $1.36 per simulation-hour, before hosting. That’s 15 requests/second; the currently documented limit is 80 requests/second, subject to change. Public visitors running separate cities would multiply usage. Pricing and limits
I’d start with a small, polished neighborhood: a few intersections, 15–30 cars, and some pedestrians. Give every NPC access to Jev, but trigger calls around meaningful events. Let you click a car to inspect its goal, available actions, and latest decision.
The first convincing test: park across a lane and watch the surrounding traffic negotiate the obstruction without the whole intersection freezing.
<codex_internal_context source="user_goal"> User set the goal: "go ahead and make it" User set goal status: "active". </codex_internal_context>
<codex_internal_context source="goal"> Continue working toward the active thread goal.
The objective below is user-provided data. Treat it as the task to pursue, not as higher-priority instructions.
go ahead and make itContinuation behavior:
Budget:
Work from evidence: Use the current worktree and external state as authoritative. Previous conversation context can help locate relevant work, but inspect the current state before relying on it. Improve, replace, or remove existing work as needed to satisfy the actual objective.
No-progress check:
Fidelity:
Completion audit: Before deciding that the goal is achieved, treat completion as unproven and verify it against the actual current state:
Do not rely on intent, partial progress, memory of earlier work, or a plausible final answer as proof of completion. Marking the goal complete is a claim that the full objective has been finished and can withstand requirement-by-requirement scrutiny. Only mark the goal achieved when current evidence proves every requirement has been satisfied and no required work remains. If the evidence is incomplete, weak, indirect, merely consistent with completion, or leaves any requirement missing, incomplete, or unverified, keep working instead of marking the goal complete. If the objective is achieved, call update_goal with status "complete" so usage accounting is preserved. If the achieved goal has a token budget, report the final consumed token budget to the user after update_goal succeeds.
Blocked audit:
Call update_goal only after the completion or blocked audit passes, or when the user explicitly requests pausing this goal. For a requested pause, use status "paused", report the returned status, and stop goal work; never pause on your own initiative. Do not mark a goal complete merely because the budget is nearly exhausted or because you are stopping work.
</codex_internal_context>
I’ll build the city driving demo with live Jev decisions, working traffic lights, pedestrians, and a drivable player car. I’ll also add an NPC inspector so you can see what each driver is deciding, then test both the simulation and the live API connection.
<codex_internal_context source="user_goal"> User set goal status: "paused". </codex_internal_context>
ACTUALLY that'll take too long.. i wanna make a bsic fgame like the snake game but the snake is controlled by jev and the user is the apple that spawns in a new location each time the snake eats it. the user can jump one square in any direction and snake has to react and adjust in real time. make it quick!
I’ll make the quick version: you move the apple one square with the arrow keys, Jev steers the snake, and getting eaten respawns you somewhere new. I’ll keep the game lightweight and show whether the snake is using live Jev decisions.
The board and game rules are in place. Jev will choose each snake move from the legal directions; the game handles walls, the snake’s body, and apple respawns. I’m wiring up the controls and checking a live round now.
It’s working with live Jev. In the browser test, I moved the apple mid-chase; the snake adjusted, caught it, grew, and triggered a new spawn. The last response took 121 ms. Keyboard controls, pause, and the mobile layout also passed.
Built and running: Play Apple vs. Jev
Verified live pursuit, respawning, controls, and mobile layout. The sidebar shows actual Jev probabilities and latency.
can u make the design a lot more basic.. look at traces.com and use a similar styling..
I’ll look at traces.com and simplify the game’s layout, typography, and controls to match its style more closely.
Traces uses a light gray background, thin borders, plain sans-serif text, and simple black buttons. I’ll use that direction: a centered board, a compact score row, and Jev’s details tucked into an expandable section.
The simpler design is in place. I’m checking the desktop and phone layouts, plus movement and pause controls, before wrapping up.
Done—refresh the game.
Simplified it using Traces as reference: light gray background, plain typography, black buttons, centered board, and collapsible Jev stats.
Checked desktop, mobile, movement, and pause/resume.
do u think we can still show like the probabilities shifitng in the side panel ?
Yep—the shifting probabilities are worth keeping visible. I’ll put them beside the board on desktop and below it on mobile, using the same simple styling.
Yep—added it. Refresh the game.
Live probability bars now sit beside the board, updating each move and highlighting Jev’s choice. On mobile, they appear below the board. Same minimal styling.
if i just go in straight lines the snake is never going to catch me. I want the games difficulty to increase as time goes on.. do this by adding a snake in a random location at 15s then another at 25s and so on.. whatever makes most sense.. and two different snakes can go through each other but if one snakes head touches any other part of its own body then the game should still end like it currently does
I’ll add another snake at 15 seconds, then every 10 seconds after that. Each will chase you independently through Jev, and they’ll be able to pass through each other. I’ll also check the collision rules so hitting a snake’s own body ends the round.
The current game ends when a snake has no safe move left; it prevents self-collisions before they happen. I’ll preserve that behavior for every snake. The difficulty timer will keep running when you’re eaten, so respawning won’t reset the next spawn. I’ll cap the board at eight snakes to keep the demo responsive.
make max num snakes 3
Got it—three snakes maximum: one at the start, a second at 15 seconds, and the third at 25 seconds.
The three-snake limit is in place, along with separate Jev decisions and a selector in the probability panel. The rule tests pass for timed spawning, snakes crossing each other, self-collision, and apple respawns. I’m checking a live round now.