Community demo · Browser automation
Browser flow explorer
Omar’s demo combines planning and Jev browser decisions to collect fresh product flows for design research.
By omar · @omarjpegA planner can choose the goal while a smaller decision model selects browser actions and which captures to retain.
What the creator is exploring
Omar shared a video of a browser workflow for collecting current product flows on demand. The goal is a design reference assembled for the task at hand, rather than a fixed catalog of screenshots.
In a follow-up explanation, the creator says Haiku handles planning while Jev selects browser actions and helps choose which captures are distinct. That division of work is the interesting part: planning the journey and making repeated local decisions need not be the same model call.
Why it is worth a look
This is an example of Jev inside a larger application, where the question alone does not explain the product. State collection, browser controls, capture handling, and the planner all contribute to the workflow.
The architectural idea may be useful for browser agents and research tools. The reviewed posts do not establish the exact state representation, question definitions, or a reusable integration, so this listing does not invent a copyable implementation.
What is available
The original post includes the creator’s video. Open it on X or load the official embedded post on this page. No public repository was established from the sources reviewed for this entry.
Evidence and limitations
This is a creator-shared demo, not an independently tested product. Speed statements in the post are the creator’s claims; we have not reproduced them. The post also does not establish native visual input support in Jev. Check the actual implementation before drawing conclusions about how screenshots or browser state reach the model.
Discovered through jev.directory; this explanation was written from the original announcement and follow-up, with credit to the creator.