CrazyJev Lab

How Room Rush uses Jev: from state to confirmed finds

CrazyJev ·

Room Rush gives Jev a 75-second shopping window. It does not ask a chatbot to invent a shopping list: a browser inspects IKEA pages, Jev selects among available actions, and the runner checks whether a product was actually collected. No checkout or payment takes place. CrazyJev is independent of IKEA and TypeSafe AI.

The loop: state → choice → action → confirmation

  1. State: the runner reads the current page, visible product candidates, the room theme, collected items and remaining time. Your optional note guides the search.
  2. Choice: Jev selects an available action. The runner validates the selection before acting; model output is not an unrestricted browser command.
  3. Action: the browser searches, opens a product, scrolls or tries to add an item. Screen frames appear on the computer inside the room.
  4. Confirmation: the runner checks the shopping state. A product counts only after confirmation, not just because a model mentioned it or a button was clicked.
  5. Repeat: updated state goes into the next choice until the round finishes or the time window closes. Browser startup happens before the shopping timer.

The room timer, browser action, network request and model call are different clocks. A quick decision cannot make a slow page load instant. This is why we do not label the entire shopping workflow as “milliseconds.”

What the result counts

A confirmed find is a distinct product in the server's completed receipt. Jev decisions counts successful, validated action choices. Retried requests do not become extra decisions unless they produce a distinct accepted choice. Older receipts that do not contain this measurement show it as unavailable, never zero.

A completed timer can yield no products. That remains a completed run, but it does not qualify as an effective completion in the growth funnel. Effective completion requires at least one confirmed item and the result being displayed to the player. Cancellations and errors stay separate.

Reproduce and inspect a round

Start Room Rush, choose a room and theme, then watch the computer, timer and collection list together. Open the final item list and inspect the products. Share the result to create a public record of the theme, confirmed items, recorded duration and decision count. The public link lasts 90 days and does not contain your personal note or private image-generation token.

“Try this theme” reuses the room and seed. It does not replay the same browser session: inventory, page response, model choices and recent finds can change the result. Custom notes are private, so a visitor must supply their own brief for a custom room.

How much does a round cost?

A verified per-round dollar cost is not available in this article. It requires provider billing evidence for all attempts, browser runtime, storage and any requested image generation. Multiplying the decision count by an assumed unit price would miss retries and other services. A generated room image is an optional illustrative concept, not a measured layout or proof of purchase.

For a reproducible cost study, retain the source version, provider/model, region, start time, successful and failed requests, browser duration and billed units. Report failed and empty rounds as well as successful ones. Keep model fees, browser fees and optional image fees separate, and publish both the denominator and exclusions.

Evidence limits

This article documents the implementation and measurement contract. It does not claim a representative success rate, a measured average cost or a speed advantage over another model. A public result verifies one run's recorded outcome; it cannot establish general reliability. The live demo remains dependent on model and storefront availability.

Try Room Rush · Read the Reaction measurement method

Development observations: September 20, 2026

We retained 11 real attempts: 4 completed with confirmed products, 2 completed empty, 3 failed and 2 were interrupted during development reloads. The four nonempty receipts contained 1–2 products and 6–10 accepted decisions, each with a 75-second shopping window. All four produced a public share record locally.

These used local Next.js and Wrangler storage, a real remote Cloudflare browser, and Jev through Vercel AI Gateway. Code changed during debugging; per-run patch hashes were not captured. This is not a fixed-build benchmark or a production success-rate estimate. The denominator includes all attempts, including interruptions. Billing cost remains unavailable.

The last three attempts were empty, empty, then a browser timeout. We stopped before the planned 20–30 samples. Loading shopping-bag pages appeared in the failed confirmation captures; a click alone was not counted. Investigate storefront readiness before restarting the larger batch. Download the sanitized observations.

Follow-up: all 21 development attempts

Across the debugging batches we retained 21 attempts: 10 completed with products, 2 completed empty, 7 failed and 2 were interrupted. Nonempty completed receipts contain 1–3 products and 6–11 accepted decisions. All ten created a public share record locally. Later batches include source fingerprints; the final run overlapped a homepage wording correction and is explicitly marked as changed-source. These are several development versions, not a fixed-build benchmark. The earlier 11-attempt snapshot remains available above.

Download all 21 sanitized records.