Focus67Dumby: A Fully Offline Visual Sticky Note That Uses Small Local Models to Tell Tutorials from Slacking

A developer opens YouTube to look up a system design walkthrough, and forty-five minutes later finds himself buried in the Shorts feed — an experience almost everyone has had. Two categories of tools already try to solve this, but each has a fatal flaw: traditional website blockers (Cold Turkey, Freedom) use a sledgehammer to crack a walnut, blocking all of YouTube or Reddit outright and stalling your workflow when you actually need to watch a tutorial; cloud AI activity trackers (Rize, Reclaim) charge $15+ per month while continuously uploading window titles, private repo names, and screen activity to third-party servers — simply unacceptable for engineers who care about privacy or work under an NDA.

Focus67Dumby, a submission for week two of the Hacktoberfest Open Source AI Challenge, offers a third path: a 350x530 dark-amber floating sticky note that runs 100% offline and uses a small local open-source model scheduled through Ollama to judge whether you're working or slacking off.

Product Form: The Sticky Note Is the Interface

Focus67Dumby compresses its interaction to the bare minimum: lock in the current goal (e.g., "fix the Express auth middleware"), pick a sprint duration (e.g., 25 minutes), choose a local Ollama model from a dropdown, and start. The sticky note sits quietly in a corner of the screen, watching active-window switches in the background and taking in-memory screenshots downsampled to 512x288, distinguishing productive work, relevant tutorials, and off-topic entertainment. Not a single byte is sent to the cloud the entire time.

The model dropdown discovers locally installed models in real time via Ollama's GET /api/tags, letting users hot-swap based on their hardware — a point hammered home repeatedly across several technical sections of the original article.

Ollama is an open-source local LLM runtime that bundles model weight downloads, quantization format management, GPU/CPU scheduling, and a unified HTTP interface into one package. Developers only need to run ollama pull <model> to fetch a model and can then call it through the REST API on 127.0.0.1:11434. Compared with loading weights yourself via PyTorch or llama.cpp, Ollama handles VRAM allocation, model hot-swapping, and request queuing, and supports a keep_alive parameter to control how long a model stays resident in VRAM. This is precisely the underlying dependency that lets Focus67Dumby enumerate local models in real time in its dropdown and hot-swap by hardware condition — and the prerequisite for its "zero cloud calls" promise, since inference happens entirely on the user's own machine.

Technical Architecture: Small Models + Perceptual Differencing

The app is built on Python 3.11 (CustomTkinter + Win32 ctypes + Pillow), calling open-weight models through Ollama's local REST API (127.0.0.1:11434). The original article lays out the division of labor among the primary models:

• gemma4:e2b / gemma4:e4b: The multimodal vision and text main engine, evaluating both the foreground window title and a compressed base64 screenshot payload, returning results in strict JSON mode.
• gemma3:270m / gemma3:1b: Ultra-edge text mode, where the 270m version uses roughly 290MB of memory and can classify a window title in under 50 milliseconds on a battery-powered low-spec laptop.
• qwen3-vl:2b / qwen3.5:2b: A swappable open-source vision option for reading small-font UI text in split-screen browser tabs.

What actually makes this tool usable is a handful of system-level engineering details, which the original breaks down in some depth:

Perceptual differencing cache. Window titles lie — when Chrome only shows "LinkedIn," you might actually be playing LinkedIn's puzzle mini-game. Vision mode grabs an in-memory screenshot, scales it to 512x288 (JPEG quality 65), and computes a 16x9 grayscale perceptual signature. If pixel change is below 3% and the window title is the same (say, reading a static document), it hits the local session cache directly: 0 ms latency, 0 GPU calls.

30-second workspace calibration. Real engineering tasks span multiple windows (VS Code, terminal, localhost browser, OAuth popup). During the first 30 seconds of a sprint, the app enters a calibration phase, automatically adding any window you touch to a trusted workspace for 0 ms instant switching, while maintaining a rolling 4-window breadcrumb trail so the model understands that a login popup was spawned by the main task.

Two strikes and escalating intervention. A quick Alt-Tab won't trigger a false positive. If two consecutive checks both land on an off-task window (the 2nd, 4th, 6th... time), the sticky note escalates intervention at your chosen level: from a native Windows notification (with an auto-generated custom .ico icon), to notification plus system sound, to a popup takeover with sound — forcing itself on top via Win32's WS_EX_APPWINDOW, flashing a red border, and shaking the sticky note left and right across the screen until you return to work.

Headless Linux and Docker determinism. All GUI, screenshot, and Win32 imports are wrapped in lazy-load guards, so the app can run a deterministic offline CLI simulation (python -m src.main --headless --demo) in a clean headless Linux Docker container and pass all unit tests in 0.75 seconds.

The perceptual signature borrows from the idea of perceptual hashing (pHash): after grayscaling and downsampling an image, pixel intensities are compressed into a fixed-length low-dimensional vector, so that visually near-identical frames map to similar signatures. Focus67Dumby scales screenshots to 512x288 and then computes a 16x9 grayscale signature, essentially turning "is this screen the same as the last one" into a cheap numerical comparison rather than another round of visual inference. The 3% pixel-change threshold tolerates irrelevant noise like cursor blinking, a ticking clock, or hover highlights, avoiding needless GPU calls from repeatedly deciding "the screen changed" while you read a static document.

Why It Has to Be Local Open-Source Models

The author's core argument is straightforward: this category simply cannot exist as a sustainable, trustworthy business on closed-source cloud APIs.

First, data sovereignty. To judge whether you're watching a React tutorial or scrolling memes, the AI has to see window titles and screen context. Sending a developer's desktop screenshots to a closed-source cloud API every 10 seconds means .env files, proprietary company source code, DMs, and banking pages all leak out. Running gemma4:e2b or gemma3:270m on 127.0.0.1 means screenshots never even hit disk — they're evaluated in memory/VRAM and discarded immediately.

Second, unit economics. At one poll every 10 seconds over an 8-hour workday, each user generates 2,880 multimodal API calls per day. At closed-source API pricing, a heavy user would burn $20 to $40+ per month in token costs alone, forcing a bloated subscription SaaS model. Local inference's marginal cost is a permanent $0.00 — which is exactly why a $19 one-time lifetime license (Pro desktop edition) can work while the core repo stays 100% open source.

Third, zero vendor lock-in. An 8GB VRAM GPU can run vision mode, an old laptop can run gemma3:270m on CPU alone, and it works on a train with no Wi-Fi; and even if Ollama isn't running, deterministic heuristic rules serve as a fallback.

The key difference between multimodal vision models (like gemma4, qwen3-vl) and pure text models is the presence of a vision encoder: the image is first cut into patches and encoded into visual tokens, which are then fed into the language model alongside text tokens. That means a single inference with a screenshot consumes far more tokens than text-only, and scales with image resolution — which is precisely why downscaling screenshots to 512x288 at JPEG quality 65 is critical for cost control. Conversely, ultra-small pure text models like gemma3:270m have no vision branch and can only read the window title string, but they use only ~290MB of VRAM and can finish a single judgment in under 50 milliseconds, making them a good fallback for battery-powered scenarios. Understanding this division of labor is key to understanding the economic motivation behind the "vision mode / text mode" dual-track design in the original article.

Feedback from the First Real User

The author handed the finished product to his first real user — a college friend stuck in a perennial loop of "open YouTube to watch a lecture, an hour later scrolling random videos."

What immediately won him over was the form factor: not a heavy browser extension, not a full-screen dashboard, just a floating sticky note. He genuinely got excited when the note distinguished legitimate task windows from off-topic browsing and, in "popup takeover plus shake" mode, physically wobbled across the screen.

Testing also surfaced real-world friction: actual workflows require jumping between multiple windows (opening a secondary login popup, switching between a quick browser task and the terminal), and once "always on top" was unchecked on the borderless Windows sticky note, it could get buried under the browser. This feedback directly led to the 30-second workspace calibration feature and a Win32 taskbar persistence fix. As for willingness to pay, monthly subscriptions are a red line for students and indie developers — validating the positioning of "a one-time low-price packaged desktop installer + an open-source core repo."

Engineering Process and Review Dimensions

The project was built and validated with an agent-driven workflow, governed by AGENTS.md, ARCHITECTURE.md, MISTAKES.md, and a custom focus67dumby-master skill spec to keep coding agents from producing monolithic spaghetti code. The spec enforces thread-safe queue.Queue() / root.after() UI scheduling, structured JSON prompts of under 60 words tailored to small models, Win32 foreground window detection, and an 8-point clean Linux Docker rebuild gate policed by a 15-test pytest suite.

The project submitted to three review tracks: Best Gemma App (building local multimodal vision and title classification around the Gemma family, with JSON schema validation and keep_alive VRAM management), Best Entire App (a complete shared agent-driven engineering workflow and repo memory artifacts), and Best Render App (hosting an interactive product frontend, sticky note state simulator, and license checkout portal on Render with continuous deployment from GitHub).

Takeaways Worth Noting

Focus67Dumby's value isn't just a wobbling sticky note. It demonstrates a product pattern that's taking shape: breaking down continuous-sensing AI features that used to require the cloud into combinations of small models that run on consumer hardware, using engineering techniques (perceptual differencing, caching, calibration, tiered intervention) to compensate for the limits of single-shot inference — in exchange for the possibility of honoring privacy commitments and one-time pricing. For indie developers and side projects, a $19 lifetime license may not build a big business, but it proves at least one direction: when inference costs drop to zero, subscriptions are no longer the only answer.

The code and interactive landing page are both public; the desktop app and source are hosted in the Thrizzio/Focus67Dumby repo on GitHub.

One-line Summary

Focus67Dumby uses small local open-source models plus engineering tricks to turn anti-slacking AI into a 100% offline floating sticky note.

Paragraph Summary

Focus67Dumby is an entry in the Hacktoberfest Open Source AI Challenge that tries to carve a third path between "sledgehammer website blockers" and "$15+/month cloud activity trackers." It's a 350x530 dark-amber floating sticky note built on Python 3.11 and CustomTkinter, calling local open-source models like gemma4, gemma3, and qwen3-vl through Ollama to make offline judgments about active window titles and downsampled screenshots — data never hits disk or the cloud. Its usability depends on several engineering details: a 3%-threshold perceptual differencing cache, 30-second workspace calibration, two-strikes escalating intervention, and 15 pytest tests that run in 0.75 seconds in a headless Linux Docker container. The author argues this category can't work on closed-source cloud APIs — roughly 2,880 multimodal calls per user per day corresponds to $20–$40+ per month in token costs, while local inference has zero marginal cost, which supports a $19 one-time lifetime license.