Space Bunny Alpha: Tested Prompts for 4 Web-Building Tasks

# Space Bunny Alpha: Tested Prompts for 4 Web-Building Tasks

Every few months a new model appears out of nowhere, beats the usual suspects at coding, and then disappears behind a paywall or a waitlist. Space Bunny Alpha is currently in that window: an anonymous model — the vendor has not been disclosed — available for testing on OpenRouter and OpenCode Zen. It is positioned as a fast-reasoning model with strong coding ability, native multimodal input (it can read images directly), adjustable reasoning strength, and a 1M-token context window.

Important: it was free during the testing window, but availability, pricing and access channels can change at any time. Always check the platform’s own pages before relying on it. This article collects how to call it and four web-building tasks whose prompts were tested end to end — plus the prompt-engineering lessons that survived contact with reality.

Three Ways to Call the Model

There are three access routes, depending on how you work:

• **OpenRouter web chat** (openrouter.ai/stealth/space-bunny-alpha): register and log in, then click Chat on the model page to start a conversation. This is the best route if you do not write code.
• **The OpenRouter API:** copy the model ID, create an API key in your account settings, and connect it to your own tools or agents in OpenAI-compatible format.
• **OpenCode Zen:** log in to Zen following its documentation to get an API key, connect it inside OpenCode, then select the model from the model list.

Pick the route that fits you: web chat for trying it by hand, the API for plugging it into your own pipeline.

The Workflow That Actually Works

The tasks below were run with a simple discipline that proved its worth:

1. **One independent conversation per task.** Tasks do not interfere with each other, and the model’s context stays focused.
2. **Paste the whole prompt in one go.** For design tasks, upload the reference image with the prompt.
3. **Save what comes back as index.html.** The model returns an HTML code block; save it as a file and double-click to open it in a browser.
4. **Feed bugs back with evidence.** When something breaks, take a screenshot, describe “what is wrong and how to reproduce it” in the same conversation, and ask the model to fix it.

That last step is where most people give up too early. The fix rounds in the tasks below show how far a well-described bug report goes.

Task 1: The 68-Key Keyboard Product Page

The first task was a product page for a fictional mechanical keyboard brand, “Arc Bay”, and its A68 keyboard. The requirements were deliberately checkable: draw exactly 68 keys, make three color themes that genuinely switch, and build only the display and color-selection features — no price, purchase, or login functionality.

Why “exactly 68 keys”? Because checkable requirements produce stable results. “Make it look like a nice keyboard” leaves the model guessing at what “nice” means; “draw exactly 68 keys” gives it a target it can count. The first version came back playable and correct, which is exactly what you want from a code-generating model: a first draft you can keep.

Task 2: The Dashboard Recreated From One Screenshot

The second task was harder: the model was given only a single screenshot of a productivity dashboard — no source code — and asked to recreate it as a real working page. The target had a sidebar, a header, four stat cards, a two-row task area, and a right-side overview panel, with genuine add, filter, and check-off functions.

The first version looked right but had a state contradiction: tasks 5 and 6 stayed labeled “completed” in their subtitles after being unchecked. The fix round is the instructive part: the reference image and problem screenshots were sent back with a description of the phenomenon, and the model fixed it immediately. The lesson is that the model can see — native multimodal input is real — but it needs you to point at the problem precisely. A screenshot plus “here is the contradiction” beats a paragraph of prose.

Task 3: The 45-Second Delivery Game

The third task was a small delivery game, “Night Shift Delivery”: move with the arrow keys, pick up the goods first, then deliver them, scoring 1 point per valid delivery within 45 seconds. Required elements: a start button, a HUD, a countdown, a results screen, and a restart.

The requirements that mattered were the state rules: “a delivery with goods adds exactly 1 point” and “stopping on the delivery point must not score twice”. Games are state machines, and vague prompts leak points. Stating the scoring as checkable invariants — exactly plus one, no double counting — got a playable game on the first version. If you have ever received a game from an AI where the score drifts upward for no reason, the cause was almost always an unstated scoring rule.

Task 4: The 3D Sphere-to-Torus Particle Morph

The fourth task was the most demanding: the same set of glowing particles morphing smoothly between a sphere and a torus, with drag, zoom, and theme switching. The prompt required real 3D projection, “continue morphing from the current intermediate state” (so the animation never snaps), and “pause the auto-rotation”.

The first version had two problems: all particles disappeared when switching to the torus, and the default sphere was too small and too dark. This time the fix round used screenshots of the normal state versus the broken state plus a screen recording, sent back with: “only fix this one issue — enhance the focus lighting but avoid overexposure.” The second version fixed both problems. Two details made this work: the explicit scope (“only this one issue”, so the model did not “helpfully” rewrite something else) and the visual evidence (before/after screenshots leave no room for misinterpretation).

Three Lessons That Held Up

Across all four tasks, three prompt-engineering habits proved their value:

1. **Keep the closing constraints.** Every prompt ended with three hard rules: return only one HTML code block, use no external libraries, and do not access the internet. That is what makes the result save-as-file-and-open. Delete those constraints and you get a page that depends on a CDN that may or may not load.
2. **Make requirements checkable.** “Exactly 68 keys” and “no double counting when stopped on the delivery point” beat “make it pretty”. Checkable requirements give the model a verifiable target and give you a test.
3. **Scope your bug fixes.** Describe the phenomenon plus reproduction steps, attach screenshots, and say “only fix this one problem”. Unscoped fix requests are how working features get quietly broken.

During the testing window, the platforms showed $0 for every round — the particle task’s final round used about 14,700 tokens and took about 200 seconds to generate. That is the testing-window reality, not a price promise. Capacity, pricing, and access channels can change; the platform’s pages are the source of truth.

(Figures and case details in this article are as reported in the source material and have not been independently verified.)

**Series: AI Practice**