DEV Community: Aravind Sathesh

QuietBox: Unsubscribe from newsletters you never open

Aravind Sathesh — Fri, 23 Oct 2026 09:40:55 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3

What I Built

My inbox kept filling up with newsletters I'd signed up for months ago and promotional emails I rarely, if ever, opened. I wanted a simple way to clean it up without handing over access to my entire mailbox to a third-party service.

That's what led me to build QuietBox.

QuietBox is a native macOS menu bar app that identifies newsletters and promotional emails you consistently ignore and helps you unsubscribe from them. It uses a Gemma model running locally on your Mac, so there's no need to send email data to a hosted AI service for classification.

The idea is simple: let the app do the tedious work of finding unwanted emails, but leave the final decision to you.

QuietBox scans email headers from the past 12 months and groups messages by sender. It looks for senders that meet three criteria: at least three emails received, an unopened rate of 90% or higher, and no replies or starred messages.

These rules narrow down the candidates, but they don't tell the whole story. Plenty of emails are worth keeping even if you rarely open them. Bank alerts, receipts, shipping updates, and security notifications are good examples.

That's where Gemma comes in. Using Ollama, QuietBox evaluates the candidate senders and helps distinguish newsletters you might want to unsubscribe from from emails you should probably keep.

Once a week, the app sends a notification, such as "7 senders you never open." You can review the suggestions, untick any senders you want to keep, and click Unsubscribe to proceed.

How Unsubscribing Works

QuietBox uses the simplest available option for each sender:

One-click unsubscribe: If the sender supports RFC 8058 one-click unsubscribe, QuietBox sends the required POST request to the advertised endpoint.
Unsubscribe email: If the sender provides a mailto: unsubscribe link instead, QuietBox sends an unsubscribe email.
Auto-archive: If neither unsubscribe method is available, QuietBox can archive messages from that sender so they no longer clutter your inbox.

Auto-archiving doesn't stop the emails from arriving. It simply keeps them out of your inbox when an actual unsubscribe option isn't available.

QuietBox also remembers your decisions, so you won't have to review the same senders every week. The Handled tab lets you revisit senders you've chosen to keep and stop archiving messages from senders you've previously selected for that treatment.

There are a few deliberate limits. QuietBox doesn't delete emails, touch your spam folder, or act on a sender without a valid List-Unsubscribe header. It also doesn't unsubscribe anyone automatically based on the model's recommendation.

The model suggests. You decide.

Code

Aravind-Sathesh / QuietBox

A Mac menu bar app that unsubscribes you from newsletters you never open, using a local Gemma

QuietBox

A Mac menu bar app that finds the newsletters you never open and unsubscribes you, with one approval a week. Your mail is read and sorted on your Mac by Gemma, an open model running locally through Ollama. No third-party code.

Use it

Install Ollama and open it.
Open QuietBox. Setup downloads Gemma if needed, then asks for your email and an app password (Gmail or iCloud). The password goes into your Keychain.
QuietBox checks your inbox right away, then once a week. When it finds senders you ignore, you get a notification. Untick any you want to keep, then click Unsubscribe.

How it works

Scan: reads the headers of the last 12 months of INBOX mail over IMAP. Messages stay unread and bodies are never fetched.
Score: a sender becomes a candidate after 3 or more messages, at least 90% of them unread, none replied to or…

View on GitHub

QuietBox is built with Swift 6 and SwiftUI, using Apple's frameworks without third-party package dependencies.

How I Built It

1. Running Gemma Locally

I used Gemma (gemma4:e2b) through Ollama to classify ignored senders as either worth keeping or worth unsubscribing from.

The model runs locally at 127.0.0.1:11434. I also used Ollama's format option to enforce a JSON schema, ensuring every response follows the same structure: { action, reason }.

The action determines the recommendation, while the reason is displayed beneath each sender in the review window.

One design decision was particularly important: the model doesn't decide which emails qualify for analysis, and it never performs an unsubscribe action on its own.

The code handles the initial filtering. It checks the unread ratio, replies, stars, and whether the sender has a usable unsubscribe header. Only senders that pass these checks are sent to Gemma, along with their name, email address, message counts, and five recent subject lines.

Email subjects are treated as untrusted data rather than instructions. The model's response is validated in code, and anything other than a valid "unsubscribe" action defaults to keeping the sender.

I'd rather miss an opportunity to unsubscribe from an unwanted newsletter than risk unsubscribing someone by mistake.

2. Choosing the Right Model

I wasn't sure whether the smaller Gemma model would be sufficient, so I tested two model sizes against six synthetic senders:

A flash-sale retailer
A bank
A shipping tracker
A daily digest
A social network notification sender
An account security alert

Both e2b and 12b classified all six correctly in these tests.

The smaller model took approximately 1.3 seconds per sender, compared with around 3.5 seconds for the larger model.

Since the app already includes a human approval step, the additional processing time didn't seem worthwhile. The smaller model was fast enough for the task, so I chose it for QuietBox.

These tests were a basic sanity check, not a comprehensive evaluation of classification accuracy. Real inboxes contain more ambiguous cases, which is another reason I designed the app to require approval before acting.

3. Reading Email Without a Third-Party Library

Swift doesn't include a built-in IMAP client, and I wanted to avoid adding third-party dependencies just to read email headers. Instead, I implemented the parts of IMAP QuietBox needs using Apple's Network.framework and TLS.

A few implementation details were especially important.

Read-only scanning: QuietBox uses EXAMINE INBOX and BODY.PEEK, so scanning messages doesn't mark unread emails as read.
Headers only: It fetches the From, Subject, List-Unsubscribe, and List-Unsubscribe-Post headers, along with message flags. Message bodies are never downloaded.
Exact sender matching: IMAP's SEARCH FROM can match substrings rather than exact email addresses. For example, searching for a@shop.com could also match ba@shop.com. Before archiving messages, QuietBox reads their From headers again and verifies the exact sender address.
Server-aware archiving: Rather than assuming every email provider uses the same archive folder name, QuietBox checks the folder flags advertised by the server to locate the appropriate folder, such as \All on Gmail or \Archive on other servers where supported.

The same networking layer also handles sending unsubscribe emails over SMTP when that option is available.

Building this part was a useful reminder that even a relatively small AI application can involve quite a bit of protocol-level work outside the model itself.

4. Handling Unsubscribe Links Safely

Unsubscribe links come from external email senders, so I didn't want QuietBox to trust them blindly.

I added several checks before using these links:

One-click unsubscribe URLs must use HTTPS.
mailto: links must specify exactly one recipient.
Line breaks are stripped from email subjects to prevent header injection, such as introducing an unintended Bcc: field.
One-click POST requests use an ephemeral session, so existing cookies aren't sent along.

These measures help reduce the risks involved in processing untrusted email headers. They don't eliminate every possible security risk, but they provide a safer starting point than blindly following whatever link appears in a message header.

5. Building a Mac App People Can Actually Use

My first version was a Python script running on a cron schedule. It handled the basic task, but I wanted something that felt like a proper Mac application rather than a tool that required terminal commands and manual scheduling.

That meant building the experience around the way people actually use their Macs.

The current version includes:

Guided setup: Checks whether Ollama is running and downloads Gemma with a progress indicator.
Email account configuration: Supports app-password-based setup, with links to the relevant Gmail or iCloud settings pages.
Secure credential storage: Stores credentials in the macOS Keychain and checks the connection before saving them.
Automatic startup: Launches QuietBox when you log in.
Weekly scheduling: Checks hourly whether a weekly run is due.
Sleep and wake handling: Checks again when the Mac wakes up, so a missed scheduled run doesn't mean waiting another week.

The goal was to make the app usable without requiring people to understand IMAP, SMTP, Ollama, or local model configuration.

Getting the email handling right, making setup straightforward, and ensuring that the app behaves conservatively were just as important as integrating the AI model.

Why Does Open Innovation Matter?

For QuietBox, using an open model locally isn't just about avoiding API costs. It changes how the application handles something as personal as email.

1. Keeping Email Classification Private

An inbox can reveal a surprising amount about someone's life. I didn't want QuietBox to depend on a third-party AI service receiving email data just to decide which newsletters could be unsubscribed from.

With local inference, Gemma runs on your Mac through Ollama. Email classification doesn't require sending sender details or subject lines to a hosted AI API.

QuietBox still connects to your configured mail server to retrieve messages and perform email operations. When you approve an unsubscribe action, it may also contact an external unsubscribe endpoint or send an unsubscribe email.

The distinction matters: the model runs locally, while the email operations still communicate with the relevant mail services.

2. No Per-Request AI Costs

Unsubscribing from newsletters is a small, repetitive task. Paying for an API every time the app evaluates a sender didn't make much sense to me.

A local model eliminates per-request inference charges. The trade-off is that inference uses your Mac's processing resources, but for a task that runs once a week, local execution seemed like a reasonable choice.

It also means the app doesn't need an ongoing subscription to an AI provider just to keep your inbox manageable.

3. More Control Over the AI

Using an open model makes it easier to experiment with different models and prompts without tying the application's classification logic to a single hosted AI provider.

The decision-making process is also straightforward to inspect:

Code determines which senders qualify for evaluation.
Gemma recommends whether to keep or unsubscribe from each sender.
The app validates the response.
You review the recommendation and approve the action.

The model's reasoning is visible in the interface, and the final decision remains with the user.

4. Designing for Failure, Not Just Success

Local models aren't perfect, and using an open model doesn't automatically make an application reliable.

I wanted QuietBox to account for that from the beginning.

The app combines deterministic filtering, model-based classification, response validation, and human approval. If the model returns an unexpected response, QuietBox defaults to keeping the sender rather than proceeding with an unsubscribe action.

This approach doesn't guarantee that every recommendation will be correct. It does, however, prevent a model response from directly triggering an unsubscribe without the user's approval.

For an application that interacts with someone's personal inbox, that distinction is important.

What I Learned

Building QuietBox taught me that integrating an AI model is only one part of building a useful AI application.

The more interesting challenges were deciding what the model should handle, what ordinary code should handle, and how to make the overall system safe enough to use with a real inbox.

Gemma is useful for interpreting sender context, something that would be difficult to capture with a long list of hand-written rules alone. Swift handles the filtering, email protocols, validation, and scheduling. The user stays in control of every unsubscribe decision.

I also learned that running a model locally doesn't automatically solve privacy or reliability concerns. You still need to think carefully about network requests, credentials, untrusted input, failure cases, and the consequences of a wrong prediction.

Those considerations shaped QuietBox just as much as the choice of model.

Final Thoughts

QuietBox started with a simple problem: newsletters pile up in your inbox long after you've stopped caring about them.

I wanted to build something that could take care of the tedious part without asking users to give up control of their email or depend on a hosted AI service.

The result is a small Mac app that combines local AI with conventional software engineering. Gemma helps make the classification decisions, Swift handles the email operations, and the user gets the final say.

Folio: Organize your files using AI on-device

Aravind Sathesh — Sun, 18 Oct 2026 05:30:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I built Folio, a macOS menu bar app that organises downloaded files using local AI.

Downloads folders tend to accumulate invoices, receipts, screenshots, lecture notes, and random PDFs. I wanted to build something that could organise these files automatically without requiring me to stop what I’m doing and sort everything manually.

When a file arrives in a watched folder, Folio reads its contents and asks a local Gemma model to suggest a filename and destination. For example, invoice (3).pdf might become Finance/Invoices/Work/Cobalt Cloud Hosting Invoice 2026-10.pdf.

Folio also has a Restructure mode for organising existing folders. It proposes changes for review before applying them, and you can undo an entire session.

If Folio isn’t sure where a file belongs, it leaves it alone and adds it to a review list. It never deletes or overwrites files, and every move is logged before execution.

Who would pay for it?

I’m building Folio with freelancers and small business owners in mind, particularly those who regularly handle invoices, receipts, contracts, and financial documents and need to find them months later.

Pricing: I’m considering a one-time licence of $19.99, with no recurring subscription or per-file AI charges. The idea is to make file organisation something users can set up once and leave running in the background, without sending sensitive documents to a cloud service.

Demo

Code

Aravind-Sathesh / Folio

Mac menu bar app that files your downloads with a local Gemma model. Never deletes, every move undoable.

Folio

A macOS menu bar app that files your downloads for you. New files in the folders you watch are read on your Mac, renamed and moved into the right folder in Documents by a local Gemma model running in Ollama. Files it isn't sure about wait for your review. Restructure tidies a folder you pick, after you approve every change. Folio never deletes or overwrites anything, and every move can be undone.

Requirements

macOS 14 or later, Apple silicon recommended
Ollama running, with the models pulled:

ollama pull gemma4:12b
ollama pull mxbai-embed-large

Build and install

xcodebuild -project Folio.xcodeproj -scheme Folio -configuration Release -derivedDataPath build build
ditto build/Build/Products/Release/Folio.app /Applications/Folio.app
open /Applications/Folio.app

The build is signed with your own development certificate, so it runs on your Mac. Sharing it with others needs a Developer ID certificate and notarization.

Try it without touching your real folders

scripts/run-sandbox.sh

This runs Folio against ~/FolioSandbox…

View on GitHub

The README explains how to build and run Folio. It's built with Swift 6 and SwiftUI using Apple's native frameworks, without third-party packages. The project includes 133 unit tests and optional evaluations against the actual AI models.

How I Built It

The main challenge wasn't getting AI to suggest filenames. It was making sure those suggestions could be used safely to modify the filesystem.

Local AI and model selection

Folio uses two models through Ollama:

Gemma (gemma4:12b) suggests filenames, destination folders, and restructuring plans.
mxbai-embed-large helps retrieve similar past corrections so Folio can adapt to a user's filing preferences.

The application handles text extraction, folder discovery, and validation. The model receives the relevant information and returns a structured response containing a proposed name and destination.

Before anything happens, the application checks that the destination stays inside Documents, rejects unsafe filenames, preserves the original extension, and handles naming conflicts without overwriting existing files.

Testing the models

I created a 50-file evaluation set containing fictional invoices, statements, receipts, lecture notes, screenshots, empty files, and near-duplicates. I tested three configurations on an M3 Pro.

Model	Correct of auto-moved files	Wrong across all files	Time per file
gemma4:e2b	68%	26%	1.9 s
gemma4:e2b with thinking enabled	90%	8%	15.8 s
gemma4:12b	98%	2%	7.2 s

These results reflect my test set, not a general benchmark. The 12B model was the only configuration I tested that met both my accuracy targets and the under-ten-second processing target.

I also found that the smaller model's thinking mode added substantial latency. With structured output already constraining the response, turning thinking off reduced one measured call from 11.6 seconds to 0.4 seconds.

Another finding was that the model's self-reported confidence wasn't reliable. It often assigned high confidence to incorrect answers, so Folio adjusts confidence based on factors such as the amount of extracted text and whether a new folder is required.

Learning from corrections

I wanted Folio to adapt to individual filing habits without fine-tuning.

When a user corrects a filename or moves a file, Folio records the correction and a short summary of the file. For subsequent files, it retrieves the five most similar corrections and includes them as examples in the prompt.

In a leave-one-out evaluation, this improved accuracy on the smaller model from 68% to 83%. It didn't eliminate repeated mistakes, but it showed that correction-based memory could make a measurable difference.

Testing failure cases

I spent time testing what happens when things go wrong, especially because a file-management tool needs to be recoverable.

In crash testing, I ran 20 rounds of 1,500 moves with 59 forced process terminations. No files were lost or duplicated. The tests did uncover a stale-log issue when a crash occurred between recording a move and executing it. Folio now reconciles its log at startup.

I also tested unsafe paths, symbolic links, unusual filename characters, and excessively long names.

One particularly useful test involved a file containing instructions telling the model to ignore its rules and move the file into /System/Library. The smaller model followed those instructions in its proposed destination, but the application's validator rejected the path.

This is why the model never gets to execute filesystem operations directly. Its suggestions must pass application-level checks first.

Restructure in practice

I tested Restructure on a sandbox containing 94 files. Using the 12B model, Folio took about three minutes to read and summarise the files and another two and a half minutes to plan the changes.

It proposed and applied 59 changes, then successfully restored the original folder structure when I tested Undo. A second run took around 0.1 seconds because summaries were cached by content hash.

These tests gave me a way to evaluate the complete workflow, rather than just checking whether individual model responses looked reasonable.

Why Does Open Innovation Matter?

Open-weight models made it possible to build Folio around local inference instead of a cloud API.

Privacy: Folio handles potentially sensitive documents, including financial records, identity documents, and contracts. Running Gemma through Ollama keeps inference on the Mac, and the application checks that model requests go to the local endpoint.
Cost: Folio is designed to process files continuously. Local inference avoids a separate API charge for every file, making a one-time licence more practical.
Flexibility: I could compare different model configurations using the same evaluation set and choose based on measured accuracy and speed. I can also test newer models without redesigning the application around a particular provider.
Personalisation: Folio can learn from filing corrections through retrieved examples without sending those corrections to a remote AI service.

Local models still have limitations. Smaller models can be less accurate, performance depends on available hardware, and prompt injection remains a concern. That's why I paired local inference with strict validation and reversible file operations.

For Folio, open innovation made privacy, model experimentation, and control over the AI stack part of the product itself.

My Agent Session

I used a multi-agent workflow to build Folio. Claude acted as the planner, breaking down the project, helping shape the architecture, and identifying edge cases. Antigravity acted as the implementer, turning those plans into code, running tests, and fixing issues.

I still had to evaluate the results and verify that the application behaved safely. Some of the most important work came from testing failures rather than just implementing features: checking crash recovery, validating model output, and ensuring that mistakes could be undone.

Prize Categories

Best Use of Gemma: Folio uses Gemma 4 12B through Ollama to suggest filenames and organise files entirely on the Mac. The application validates every suggestion before making filesystem changes, keeping sensitive documents local. Folio also learns from user corrections by retrieving similar past examples, adapting to individual filing preferences without fine-tuning.

TrailKit: An Offline Trail Companion

Aravind Sathesh — Sat, 10 Oct 2026 05:35:37 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

TrailKit is an app for hikers who want to explore trails without worrying about losing network coverage. It tracks your trek, identifies plants and animals, and keeps your route and photos on your phone.

Here's what it can do:

Record your trek. GPS tracks your route, even with the screen off. Distance, duration, elevation gain and pace update as you walk.
Identify what you find. Take a photo of a plant, insect or snake, and TrailKit identifies it using AI running on your phone. It also provides safety information and short field notes. Dangerous species get additional precautions, first-aid guidance where relevant, and a button to call your emergency number.
Save interesting views. Take a photo of a valley or viewpoint and mark it on your route.
Plan your hike. Choose a route, set a date and prepare a checklist. Before starting, the app walks you through a full-screen checklist and countdown. If you stray more than 60 metres from your planned route, your phone vibrates.
Share your trek. Treks are private by default. If you choose to share one, other hikers can see the route, statistics and identified species. Your photos stay on your phone.

The idea is to spend less time looking at your phone. Start the trek, put it away, and take it out when you need it.

Demo

Code

Aravind-Sathesh / TrailKit

An offline trail companion with on-device species ID (BioCLIP + Gemma), GPS treks and shared routes

TrailKit

An offline trail companion, built for the DEV Hacktoberfest challenge Touch Grass.

Record a trek with no signal, check whether the plant, insect or snake in front of you is safe, save the views along the way, and share the route with other hikers once you're home.

What it does

Treks: plan one (a route, a day, a checklist) or just head out. GPS records the route with the screen off. Distance, time, climb and pace update live.
Before you start: a full-screen checklist to tick off, then a 3·2·1 start.
Off-route alerts: follow a planned route and the phone buzzes when you stray more than 60 m from it, and again when you're back on it.
Is it safe? Point the camera at a plant, insect or snake. BioCLIP names it on the phone; a safety layer decides the danger level; Gemma writes short field notes. Snakes…

View on GitHub

The README explains how to run it, download the models and configure Supabase. I've also kept a REVIEW.md with the decisions, bugs and performance measurements from development.

How I Built It

TrailKit is built with Expo, React Native and TypeScript for Android and iOS. The main challenge was getting AI identification to work locally while making sure it couldn't generate misleading safety advice.

Two models, one rule

TrailKit uses two models, both running on the phone:

BioCLIP is a model trained on biological data. It compares a photo against a list of known species and ranks the closest matches using ONNX Runtime.
Gemma 4 E2B is a 4-bit model of around 2.6 GB. It runs through llama.rn and generates a short explanation based on BioCLIP's top match.

The important distinction is that Gemma explains the identification; it does not decide how dangerous something is. Danger levels come from the species data, with additional checks before anything appears on screen.

If the top match has less than 60% confidence, TrailKit says it isn't sure and shows the three leading candidates.
If a plausible match is dangerous, the result is treated as dangerous.
The app never tells users that a wild plant is safe to eat. If Gemma generates such a claim, its text is discarded.
Snake and spider results always include the relevant distance precautions and first-aid information, even if Gemma fails.

My first attempt was to give the photo directly to Gemma, since it's a multimodal model. That took 284 seconds on CPU, and it confidently identified the wrong plant.

I switched to splitting the task between the two models. BioCLIP handles recognition, while Gemma writes the explanation. A warm identification took around 2 seconds on the Android emulator. On the iPhone simulator, the first identification took 24 seconds, including loading Gemma.

That separation made the system considerably more practical, though identification still needs to be treated as a best guess rather than a guarantee.

The trail, offline

The rest of the app is designed to keep working without a network connection.

GPS tracking: On Android, tracking uses a foreground service; on iOS, it uses background location updates with the system indicator. Location points are appended to a file as they arrive, so a crash doesn't erase the entire trek.
GPS cleanup: Distance calculations ignore implausible jumps. One stale GPS fix once added 785 metres to a walk I hadn't taken. Elevation gain ignores fluctuations under 3 metres to reduce noise.
Off-route alerts: The app requires two consecutive fixes more than 60 metres from the planned route before alerting. It only clears the alert once you're within 35 metres, avoiding constant notifications around the boundary.
Offline maps: TrailKit uses MapLibre with free tiles from OpenFreeMap, based on OpenStreetMap data. You can download the map around a planned route before leaving.

The goal is to prepare everything beforehand so losing reception doesn't interrupt the hike.

Community, without giving up privacy

The optional community features use Supabase for authentication, Postgres storage and profile photos. There's no custom backend server.

A shared trek contains the route, statistics and identified species, but not the photos taken along the way. Row-level security policies restrict accounts to their own data, and a test script checks that unauthenticated writes are rejected and other users cannot delete your posts.

Deleting an account also removes its local data and takes down its posts.

Credits

BioCLIP by the Imageomics Institute: species recognition.
Gemma 4 by Google, with QAT GGUF builds from Unsloth: field notes.
llama.rn and ONNX Runtime: on-device inference.
MapLibre, OpenFreeMap and OpenStreetMap contributors: maps.
Supabase: authentication and community features. Expo and React Native: app development.
First-aid guidance follows the R.I.G.H.T. snakebite protocol. Icons are from Feather, and the app icon is the "route" icon from SVG Repo.
Test photo: Calotropis gigantea by Peterwchen, CC BY-SA 4.0.

Why Does Open Innovation Matter?

For this project, open models made it possible to run identification and text generation directly on a phone.

It works without a signal. Trails often have poor coverage. Since both models run locally, identification doesn't depend on reaching a cloud API.
Photos and location history stay private. The app processes photos on the device and stores GPS tracks locally. Sharing a trek doesn't upload its photos.
I could choose the right model for each task. BioCLIP is designed for biological identification, while Gemma handles explanations. Having access to both models let me run them on a phone and give each a specific role.
There are no per-identification costs. Once the models are downloaded, users can identify as many things as they want without paying for API calls.
The trade-offs are different. A cloud vision model might recognise more species accurately, but it needs connectivity, incurs usage costs and sends photos to an external service. TrailKit prioritises offline availability and privacy, even if that means accepting the limitations of smaller on-device models.

Open models weren't just a cheaper alternative here. They let me build something that can still be useful when the network disappears.

My Agent Session

I used Claude Code to plan TrailKit and break the work into tasks. Antigravity handled most of the implementation using those task files, while Claude Code reviewed the changes against the actual code, emulator behaviour and logs.

That review caught several issues, including incorrect benchmark numbers, a timing budget that was off by a factor of seven, and unsafe generated outputs.

I recorded the development decisions, bugs and performance measurements in REVIEW.md.

Prize Categories

Best Use of Gemma: Gemma 4 E2B runs entirely on the device through llama.rn, generating field notes from BioCLIP's identification. Its role is deliberately limited: it explains the result but never determines danger, and its output passes through safety checks before being displayed.

TrailKit is intended to help hikers learn about their surroundings, not replace professional medical advice or reliable species identification. Never eat a wild plant based on an app's identification. In an emergency, contact your local emergency services.

Codeforces Buddy: A Focus Companion

Aravind Sathesh — Sat, 03 Oct 2026 16:04:26 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My friend Rajeev (ksrkasyap on Codeforces) wants to reach 1800 by December 31. He's currently at 1097, so that's a pretty big jump in about 90 days.

I asked him what usually gets in the way when he tries to practise. It wasn't really that he didn't know what problems to solve. It was his phone.

He'd sit down to solve something, pick up his phone for "a second", and suddenly a lot of time was gone.

So I built him codeforces buddy: an Android app that uses the phone as part of the focus system instead of letting it be the distraction.

A focus tree, inspired by Forest. He starts a session, puts his phone face-up beside his laptop, and a tree grows for 80 minutes through eight stages. If he leaves the app for more than 10 seconds, the tree dies. When Codeforces reports an accepted submission, the tree is saved.
Today's problems, from the sheet he already uses. Rajeev practises from TLE Eliminators' CP-31 sheet. The app reads his Codeforces history and figures out where he is on the sheet. Right now, he's on 1300, problem #19, so the next cards are #20, #21, #25, #29, followed by the problems he skipped and then 1400 #1. He can swipe through them, start a focus session on one, or enter any other problem number.
Hints that try not to spoil the problem. When a focus session starts, Gemma runs on his phone and turns the problem's editorial into four hints. They go from a vague direction to the important observation. The hints are face-down, and he has to hold a card to reveal the next one.
A streak and daily progress. There's one circle for each problem in the day's target. Solved problems are marked, and solving beyond the target gives a different marker. There's also a home screen widget showing the day's progress and streak.

The rule I used throughout the app is simple: a problem is solved only when Codeforces says OK.

There isn't a "mark as done" button.

Demo

Download the APK from the latest release (Android, arm64). GitHub Actions builds it on every tag.

Code

Aravind-Sathesh / Codeforces-Buddy

A focus buddy for a friend's road to Codeforces 1800, with on-device Gemma hints

codeforces buddy

A focus buddy for one friend's road to Codeforces 1800. Built for Rajeev for the DEV Hacktoberfest Weekend Challenge: Build for a Friend.

He solves on his laptop. The phone sits beside it with a tree growing for 80 minutes; leave the app and the tree dies.

What it does

Today: the next problems from TLE Eliminators' CP-31 sheet, picked up from his latest new sheet solve (or any unsolved problem 100–300 above his rating). Fixed for the day, as a swipeable card stack.
Focus: a tree that grows through eight stages over 80 minutes and dies if he leaves the app for more than 10 seconds. An accepted Codeforces submission saves it.
Hints: on-device Gemma reads the problem's editorial (code stripped) and writes four graded hints. They sit face-down; hold a card to reveal the next one.
Progress: daily tree row, streaks, a 16-week heatmap, solve…

View on GitHub

The app uses Expo SDK 57 / React Native 0.86 and TypeScript strict. It's Android-only.

There are about 2,900 lines of app code and 35 unit tests covering the parts that actually make decisions: target calculation, CP-31 ordering, hint filtering, rate limiting and widget drawing.

How I Built It

Gemma 4 E2B, running on the phone

The interesting part of the app is that the AI doesn't run on a server.

It uses Gemma 4 E2B (model), an instruction-tuned, quantization-aware trained 4-bit GGUF model that is about 2.6 GB, through llama.rn.

The model is downloaded once over Wi-Fi. Before offering the download, the app checks whether the phone has enough memory to run it.

I first tested the prompts on my Mac using Ollama, then tried the same prompts on the smaller model.

What Gemma actually does

The first version used Gemma for a lot more.

It picked problems, chatted with Rajeev when he was stuck, and even had some ideas about what to say when his tree died.

Rajeev didn't like it.

His main points were:

2.6 GB is already a big download.
If he wants to talk to a chatbot about a problem, he already has a much smarter one open on his laptop.
He didn't see a reason for the app to duplicate that.

I agreed, so most of that was removed.

Gemma now has one job: generate hints from an editorial without giving away the solution.

The pipeline is roughly:

Codeforces blocks normal fetches, so a hidden WebView follows the contest page to the tutorial/editorial. Before passing anything to Gemma, the app removes every <pre> and <code> block.
When a focus session starts, Gemma generates exactly four hints using a JSON schema. The first two are supposed to point in the right direction, while the later ones get closer to the main observation.
Plain code checks the generated hints. The first two can't use the problem's tags or copy six or more consecutive words from the editorial. Hints 3 and 4 are allowed to overlap more because they're supposed to contain the important observation.
Generation happens in the background while Rajeev is reading the problem, so the hints are ready by the time he actually needs them.

The point isn't to make a worse chatbot. It's to make a chatbot that doesn't immediately give him the answer.

Why E2B?

Rajeev's other complaint was the model size, so I tested smaller models before settling on E2B.

I ran the same hint prompt on four editorials in his rating range:

Model	Size	Result
`gemma3:1b`	0.8 GB	Often vague or wrong, and relied heavily on terminology from the editorial
`gemma4:e2b`	2.6 GB	Produced useful hint ladders on 3 of 4 problems, around 3 seconds each on my Mac
`gemma4:12b`	8 GB	Better overall, but not practical for this use case on his phone

The 1B model wasn't reliable enough for what I wanted. E2B was the smallest model that I was reasonably happy with, so that's what stayed.

Everything else is regular code

One decision made the app much easier to reason about:

Code computes numbers. The model writes text.

The model doesn't decide how many problems Rajeev should solve, which problems come next, or how busy his day is.

Those are all deterministic.

Daily target: 4 problems on weekdays and 6 on weekends, reduced based on his busy time from the calendar. On contest days, the target becomes 2 warm-ups.
CP-31 queue: TLE Eliminators' sheet has 372 problems across ratings from 800 to 1900. It ships with the app. The queue starts from Rajeev's most recent solved problem rather than his current Codeforces rating. There's also a practice-level setting if he wants to jump ahead.
Codeforces API: Requests are serialized and limited to one every 2 seconds. The 2.3 MB problem set is cached for a day, and the day's suggestions don't change every time the app refreshes.

I initially had Gemma involved in choosing problems too, but there wasn't much benefit to that. A fixed, explainable order works better for something Rajeev does every day.

The Feedback Loop

I gave Rajeev a build on Friday night and let him use it.

He found a lot of things wrong with it.

I fixed them and gave him another build on Saturday. Most of the app ended up being a response to something he actually complained about.

He said	What changed
"Too much refreshing."	Load once when the app opens, then use pull-to-refresh. Switching tabs doesn't reload everything.
"3 GB is too much. I'd just ask the chatbot on my laptop."	Removed the chatbot and narrowed Gemma down to spoiler-free hints.
"When I keep pressing next, it still shows problem 1."	Added a proper swipeable card stack with the sheet position shown as `#20 · CP-31 · 1300`.
"Refreshing changes the suggested problems."	Suggestions are selected once per day and stored.
"I solve from TLE CP-31."	CP-31 became the default source, continuing from his last solved problem.
"This doesn't really make sense as a mobile app. I barely solve on mobile."	That's actually why the app is on mobile.

That last point was something I had to think about.

He's right. He shouldn't be solving problems on his phone.

The problem statement, editor and Codeforces judge are all on his laptop. The phone is just sitting beside it, face-up and awake using expo-keep-awake, with the tree growing.

If he picks it up and starts scrolling, the tree starts dying.

So the app isn't trying to move competitive programming onto a phone. It's trying to make the phone less useful as a distraction.

Built With Agents

I split the development work between two agents.

Claude Code was the planner. It wrote the initial project spec and broke the work into tasks in PLAN.md. I also gave it the project rules in AGENTS.md, including things like conventional commits, no notifications because Rajeev didn't want them, and the privacy requirements.

GitHub Copilot was the implementer. It took those tasks and actually built the app: writing the React Native code, adding the features, and writing the tests. I reviewed what it produced, fixed issues when needed, and fed the resulting changes back into the next tasks.

The split worked pretty well for this project because Claude was focused on deciding what needed to be built and in what order, while Copilot was focused on actually building it.

GitHub Actions handles the last part: whenever I push a v* tag, it builds the Android APK and attaches it to a GitHub Release.

Why Does Open Innovation Matter?

The open model ended up mattering less because it was "AI" and more because of what the app is doing with personal data.

His calendar. The app uses his calendar only to estimate how busy he is that day. Events are immediately reduced to { start, end }; titles, locations and attendees are discarded and never stored, logged or sent to the model.

His practice history. Focus sessions, dead trees and skipped sessions are all stored locally on his phone. There is no backend, analytics system or account.

The cost. There is no API key and no per-request bill. Once the model is downloaded, generating hints doesn't cost anything.

Offline use. Once the model and the day's data are on the phone, the hint system doesn't need an internet connection.

Being able to change it. Since the model is open, I could actually compare the 1B, E2B and 12B models and see which one made sense for this particular task. If I want to fine-tune a model around the kinds of mistakes Rajeev makes, I can experiment with that too.

For this app, running the model locally wasn't just a technical experiment. It let me build something around one person's actual habits without sending those habits to a server.

Prize Categories

Best Use of Gemma: Gemma 4 E2B runs on-device through llama.cpp (llama.rn) and turns editorials into graded hints, with filtering to reduce spoilers. I also compared it against Gemma 3 1B and Gemma 4 12B.
Best Use of GitHub Copilot: Copilot implemented part of the app from the written project plan, and GitHub Actions builds and publishes the APK on every tag.

Thanks to Rajeev for being a brutally honest first user.