Skip to content
CodexgreenfieldWeb8 files · +1946 −15

Build a browser-LLM Taboo game with Gradio + Transformers.js

Session from clue-vibes-traces on Hugging Face by build-small-hackathon · CC-BY-4.0 · condensed by Coders Talk

23msession
1interventions
GOAL

Build a hackathon Gradio Space where a player writes a clue for a target word (avoiding banned words) and an in-browser Tiny Aya ONNX model guesses it within 30 seconds and 3 tries, then deploy it to Hugging Face Spaces.

  1. Prompt · +0
    Build a Gradio Taboo-style game: player writes a clue for a target word (avoiding banned words), a browser-side Tiny Aya ONNX model tries to guess it, 30s/280 chars, up to 3 guesses, start/download/game/score screens.
  2. Agent did · +0
    Explored docs, dataset, and sibling example gradio apps for the Server/Transformers.js pattern, then created app.py, index.html, static/app.js, static/styles.css and updated requirements.txt for the full game loop.
  3. Agent did · +0
    Verified Python syntax and JS parsing via a bundled Node runtime, checked playable card counts (7237 raw, 7101 playable), aligned Server() usage with example apps, loosened gradio version pin, and rewrote README.md as a proper HF Space card.
  4. Prompt · +0
    Visual bug: after winning round 1, the model status card still shows 'tiny aya found it' instead of resetting to 'awaiting' for round 2.
  5. Agent did · +0
    Traced startRound() and found it didn't reset the model status label; added a resetRoundUi() helper called at the start of each round, verified with node --check.
  6. Prompt · +0
    Add a 'how to play' modal on the start screen noting the ~2GB model download, and verify whether an HF token would speed up the browser-side download.
  7. Agent did · +0
    Added a how-to-play modal with the 2.3GB download warning; researched HF docs and concluded a Space secret token can't safely help client-side browser downloads without exposing it, so declined to wire one in.
  8. Prompt · +0
    When the timer runs out, submit whatever clue was typed instead of just failing the round.
  9. Agent did · +0
    Replaced the timeout handler's automatic loss with a submitClue({allowExpired, fromTimer}) call so a valid in-progress clue is sent on timeout, with existing empty/blocked-word losses preserved.
  10. Intervention · +0
    Stopped the agent mid-way through trying to get Playwright working locally to test mobile responsiveness (missing playwright-core, sandbox issues).
    Why: The mobile responsiveness check was taking too long chasing broken tooling; I wanted to move on to deploying the Space instead.
  11. Agent did · +9m
    Created the build-small-hackathon/clue-vibes HF Space (cpu-basic), ensured .env stayed gitignored, wrote a hackathon-track README, initialized git, worked through auth/merge issues (dubious ownership, askpass helper, remote initial commit) and pushed only the runtime files; confirmed Space reached RUNNING status.
  12. Outcome · +23m
    Space deployed and RUNNING at build-small-hackathon/clue-vibes on cpu-basic hardware; commit 5cab5fd pushed with only the 9 runtime files (app.py, index.html, static assets, README, requirements, dataset json).
VERDICT

I'd specify upfront that mobile-responsiveness testing should rely on manual review or a known-working tool rather than have the agent hunt for a broken local Playwright install, since that ate time for no result. Interrupting that detour and redirecting straight to the HF Space deployment was the right call — the agent then handled the trickier git/auth dance (dubious ownership, askpass, merging the Space's initial commit) cleanly on its own. Next time I'd also ask it to confirm the .env is gitignored before it starts touching git, not after, just to be safe.

I tried this · 0

Discussion · 0

How Builds work