Touch Grass Bingo: A Browser-Based Offline AI App That Runs Entirely on Your Device

A browser-based bingo app that runs Llama 1B locally to generate outdoor exploration cards — no server, no API key.
Touch Grass Bingo is a single-file web app that uses WebLLM and WebGPU to run Llama 3.2 1B locally in the browser, generating 5×5 outdoor exploration bingo cards based on your city and available time. All inference happens on-device — no backend, no API keys, no location data leaving your phone. The author's v1-to-v3 development log reveals key on-device AI constraints: small models can't reliably output strict JSON, model size directly affects mobile usability, and a forgiving parser beats a brittle contract. The project makes a concrete case for open-weights models: privacy by default, zero operating cost, and full control over model choice.
An AI App That Wants You to Put Down Your Phone
At a time when most AI applications are becoming increasingly dependent on cloud compute and massive API calls, developer Sanny1921 took the opposite approach with Touch Grass Bingo — a lightweight web app that runs entirely in your browser, built around a refreshingly rebellious idea: it wants to be the part of your day you spend the least time on.
The interface is straightforward: enter your city or neighborhood, choose how much time you have (15 minutes to 2 hours), and pick a vibe (Leisurely Stroll, Photo Safari, Street Food & Crowds, or Nature & Wildlife). An open-weights AI model then generates a 5×5 bingo card filled with prompts like "Find a stray dog," "Hear temple bells," or "Spot a flower." The center square is free, and completing a line earns you a BINGO.
Once your card is generated, you're supposed to pocket your phone and head outside, checking off squares in the real world. As the author puts it: "You open it for 30 seconds, then you leave." That design philosophy feels genuinely rare in an era of deliberately addictive apps.

The live demo and source code are hosted on GitHub Pages and a GitHub repository respectively, released as an entry for the Hacktoberfest open-source AI challenge.
Tech Stack: Running a Language Model in the Browser
What makes this project interesting isn't the feature set — it's the technical choices. It demonstrates what on-device AI actually looks like on ordinary consumer hardware.
- Model: Llama 3.2 1B Instruct, a lightweight open-weights model.
- Runtime: WebLLM, which runs the model directly in the browser via WebGPU.
- App: A single plain HTML file — no framework, no backend, no API key, hosted for free on GitHub Pages.
The first time you tap "Generate My Card," the browser downloads roughly 700MB of model weights, which are then cached locally. All subsequent inference happens on your device, never touching a server.
This architecture has real implications. No backend bills, no ops overhead — the developer can leave it running for free indefinitely. The entire app is a static file, which is about as close to zero marginal cost as you can get.
WebGPU is the browser's next-generation graphics and compute API, which landed in mainstream browsers in 2023. It lets web pages tap directly into GPU compute (GPGPU). Compared to its predecessor WebGL, WebGPU maps more closely to modern GPU driver models, and its compute shader support makes it well-suited for the parallel matrix operations that neural network inference requires. WebLLM is built on top of WebGPU — it loads model weights into GPU memory and performs token-by-token autoregressive inference on the GPU, bypassing the performance limitations of the traditional browser sandbox. Chrome and Edge currently have the best WebGPU support; Safari and Firefox are still catching up, which explains why the author specifically notes that screenshots were taken in Android Chrome.
Llama 3.2 1B Instruct is a lightweight instruction-tuned model released by Meta in 2024, designed for edge devices. "1B" means roughly one billion parameters — about 1/70th of the 70B variant. Instruction tuning allows it to follow natural language directives and produce formatted output rather than just completing text, which is what lets it understand a prompt like "generate a bingo card." The 700MB download size comes from quantization: the original FP32 weights are compressed using low-precision formats like INT4, dramatically reducing size at the cost of modest accuracy loss, making the model practical on consumer devices.
From v1 to v3: Hard-Won Lessons in Small-Model Engineering
The author candidly documented a late-night development process full of pitfalls — essential reading for anyone working on on-device AI.
v1: The Strict JSON Failure
The first version asked the model to return a JSON array of 24 strings. The model loaded fine on mobile, but consistently returned malformed JSON. After three retries, the app gave up and fell back to a built-in starter card. The result: an "AI app" that never actually used AI.
The fragility of small models when it comes to strict structured output comes down to limited context modeling capacity. JSON formatting requires the model to "remember" its position in the overall structure with every token it generates — whether brackets are balanced, whether commas are missing, whether strings are properly escaped. Models above 70B handle this global structural awareness reasonably well; at 1B, positional awareness degrades noticeably over long sequences, and when generating 24 structurally identical entries, accumulated errors easily cause format corruption. This is exactly why production systems often use "structured output" or guided decoding — filtering out illegal tokens at decode time to lock the model's output to valid states in a JSON finite-state machine. The author's switch to numbered lists in v2 is essentially a reduction in formatting constraint complexity, trading strictness for a much higher success rate.
v2: New Contract, New Model
Recognizing that 1B-scale models simply aren't great at strict JSON, the author changed the output contract to a plain numbered list (e.g., "1. Spot a street dog") and wrote a forgiving parser: it ignores numbering style, bullet points, Markdown formatting, and duplicates, stripping out invalid lines.
He also tried the larger Qwen2.5 1.5B, but the extra 1GB of download repeatedly triggered cache errors on WiFi. This surfaced a key insight: on mobile, model size is part of the product. That one line captures the core constraint of on-device AI — the parameter counts that cloud deployments chase can translate directly to unusability at the edge.
v3: Back to Basics
The final version returned to the Llama 3.2 1B that was already cached on his phone, kept the numbered list format, and added a "salvage" mechanism: the app keeps the best result across three attempts, and if the model produces at least 14 valid squares, it fills in the rest from a starter list rather than discarding everything. Download retries and a visual progress percentage were also added.
This combination finally worked. The card in the screenshots was genuinely generated by the model on the author's own Android device running Chrome — not a mocked-up UI.
The author is also honest about limitations: a 1B model produces simple, generic prompts ("find a flower"), not a curated local guide. Larger models would generate sharper, more location-aware content — and that's the first thing he'd improve with more time.
Why Open Models Matter
The project makes a few concrete arguments for open-weights models that hold up well in practice:
- Location data stays local: The city text you enter only goes to the model running on your own device — it never reaches anyone else's server. Privacy is built in by default.
- Zero operating cost: No API bill means the app can stay free and open to everyone indefinitely, hosted as a single static file.
- Models are swappable: During development, the author switched models and prompts multiple times with a single line of code change. With a closed API, you're at the provider's mercy.
These three points — privacy, cost, and control — map directly to the core advantages of open-weights models over closed APIs. For indie developers, these factors often determine whether a project survives long-term.
"Open weights" and "open source" are different things, though they're frequently conflated. Open weights means the model's parameter files can be publicly downloaded and run locally, but the training code, dataset, or license may still carry restrictions. True open source typically requires full transparency around training pipeline, data provenance, and commercial use rights. The Llama series is open-weights — you can download and run it locally, but Meta's license includes additional terms for commercial use at scale. For an indie developer project like this one, the distinction barely matters in practice. But when evaluating the "freely swappable" advantage, it's worth noting that your freedom to swap is ultimately bounded by each model's license terms — not the same as an unrestricted open-source license like Apache 2.0.
What's Next
The author's roadmap includes letting users with better devices and connectivity opt into larger models, supporting card saving and sharing so friends can race on the same card, and using time-of-day and weather data to dynamically adjust card content.
Touch Grass Bingo is a small, slightly tongue-in-cheek project — but the technical validation behind it is solid: a 1B parameter model running local inference in a stock mobile browser via WebLLM, with no backend, no API keys, and zero operating cost. It's an honest data point on what on-device AI can and can't do. And it's a reminder that not every AI application needs to pile on parameters and compute. Sometimes the best product design is the one that gets people to put down their phones and go outside.
Related articles

Why Does the Tesla Roadster Need to Fly? A Deep Dive into Musk's Wild Demo
Tesla's Roadster launch showed wall-climbing, upside-down driving, and flying stunts—but The Vergecast notes the demo car may lack a battery, the Rocket version is invite-only and not street-legal, and the website terms don't guarantee delivery. After nine years of delays, why does this car still need to exist?

AI Is Not a Replacement: Human-AI Collaboration Through the Lens of Factory Root Cause Analysis
Starting from factory root cause analysis, this article explains how AI accelerates evidence chain construction rather than replacing human experts, exploring the pragmatic implementation logic and business value of 'AI supporting people rather than replacing them.'

AI Agent Decision Auditing: Building an Evidence Chain in Regulated Workflows
Starting from a Reddit discussion, this article analyzes three core issues in AI agent decision auditing within regulated workflows: what fields audit records should contain, how to handle feedback latency for erroneous decisions, and how to continuously calibrate LLM judge consistency with human judgment.