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 / Hacktoberfest-2026

Hacktoberfest 2026

Projects for the DEV Hacktoberfest 2026 challenges, one folder per week.

Week	Project
WEEK 0	codeforces buddy: a focus buddy for a friend's road to Codeforces 1800, with on-device Gemma

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.

DEV Community: Aravind Sathesh