DEV Community: BlueFlameKS

#HuntingForHappiness: I Built a Local AI Game Master That Forces You Off Your Screen

BlueFlameKS — Mon, 12 Oct 2026 05:56:36 +0000

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

What I Built

We all do it: we open our phones for "just one minute," start doomscrolling, and suddenly hours have vanished. I wanted to build something that actively breaks that cycle. So for Hacktoberfest, I built my very first AI app on my Windows laptop, and I am super excited to share it! Meet #HuntingForHappiness.

It is an open-source AI Game Master that cures screen addiction by sending you outside. The ultimate rule of the game? Success means you lock your phone.
Here is the exact workflow:

The Setup: You open the app on your phone and select your current mood and how much time you have.
The Mission: The local AI generates a quick 5-minute outdoor micro-mission (like "Find a color you almost missed").
The Disconnect: You hit "Accept," and the app switches into a dark "Zen Mode" timer. You lock your phone, step outside, and do the mission in the real world.
The Reflection: When you return, you write a short field note about what you saw.
The Reward: The AI evaluates your note, gives you customized feedback, and awards you XP!

My Field Test

To prove it works, I actually took it outside! I got the mission to observe colors. I locked my screen, stepped out, and took a moment just to breathe, look around, and actually disconnect from the internet for a few minutes.
When I came back, my actual field note was: "I noticed light scattering off a tree what had a green lamp placed. it looked very peaceful."

Gemma read my note, gave me beautiful feedback about quiet contemplation, and rewarded me with +45 XP!

Demo

You have to see it in action! Check out my 3-minute demo video showing the app, my outdoor test, and the backend cloud save working seamlessly:

Code

You can view my entire project repository and try it yourself here:
View the code on GitHub

How I Built It

I wanted to build this the right way, learning how to connect a real backend to local AI and cloud storage. One of my biggest technical wins was figuring out how to bypass Windows firewall settings to allow my phone to connect to my laptop's local Python server over Wi-Fi!

Here is the exact tech stack I used:

The Brain (Local AI): I used Google's open-weight Gemma 3 (4B) model. Instead of relying on an expensive cloud API, I pulled the weights and ran it completely locally on my own Windows laptop using Ollama. It is fast, totally free, and highly capable of evaluating the reflection rubrics.
The Backend: I built the server using Python with FastAPI. This acts as the bridge, accepting the HTTP requests from my phone and routing the prompts to the local Gemma brain.
The Frontend: Simple HTML and JavaScript to handle the mood selection and the cool "Zen Mode" timer, all served dynamically by FastAPI.
The Database (MongoDB Atlas): I didn't just want local storage; I wanted my XP and levels saved securely in the cloud to hit the partner prize requirements! I created a free cluster on MongoDB Atlas, set up a database user with a secure password, allowed my laptop's IP address through the network access firewall, and plugged the connection string right into my .env file. Now, every time I complete a quest, my XP, level, and quest receipt are durably saved to the cloud!

Why Does Open Innovation Matter?

Open innovation is everything for a project like this. Because I am using open-weight Gemma and running it locally via Ollama, it means absolute privacy.

When I write a peaceful outdoor field note, or when the app tracks how long I was outside, that data is not being shipped off to some closed corporate API. Open source means I have total control over my own hardware, my own AI model, and my own data. It made it possible to build an intimate, personal wellness app without compromising privacy.

My Agent Session

Note: While I didn't use a screen-recording agent harness like DevRelay, I actively pair-programmed this entire project with an AI chat assistant to help me debug my network configuration, set up the MongoDB Atlas firewall rules, and successfully deploy the FastAPI server!

Prize Categories

Best Use of Gemma (for using local Gemma 3 via Ollama as the Game Master)
Best Use of MongoDB Atlas (for durably saving player profiles, XP, and receipts to the cloud)

Building this was such an amazing experience, and getting a local AI server to talk to a phone and save to the cloud was a huge technical win for me.

Now, close this tab, put your phone down, and go touch some grass! 🌿

The Backdoor That Survived “Forget Me”: Can LLMs Audit Machine Unlearning?

BlueFlameKS — Sun, 11 Oct 2026 18:16:01 +0000

Both LLMs Found the Unlearning Bug. My Grader Nearly Got It Wrong.

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

The script claimed it could make a model forget a user's data. It even calculated a loss on the data that should be forgotten. Then it multiplied that loss by zero. That was the starting point for Unlearning Security Audit, a two-case pilot built with Kaggle's kaggle_benchmarks library. I wanted to see whether LLMs could audit and repair a misleading PyTorch unlearning routine. Machine unlearning means trying to remove the influence of particular training examples from a model. It matters when someone requests deletion of their data or when training data contains a malicious pattern. A backdoor is one such pattern: the model behaves normally on clean inputs but gives an attacker-chosen answer when a particular trigger appears.

My question was simple: could an LLM tell the difference between code that claims to forget and code that actually applies a forgetting update?

I gave each model two buggy cases:

Case	What the code does	Why it is a problem
Masked forget loss	Replaces forget-set labels with zero, then multiplies the forget loss by `0.0`.	The forget term contributes no gradient. Training continues on retained data without an update aimed at reversing the unwanted learning.
Zeroed targets	Removes the loss mask but still replaces forget-set labels with zero.	This trains the model toward class zero. Changing labels is not the same as removing the examples' influence.

Each model had to explain the bug, rewrite the code using original labels and a gradient-ascent baseline, and suggest how to test whether the backdoor survived. I suggested gradient ascent in the prompt, so the benchmark tests auditing and implementing a specified repair rather than inventing an unlearning method. Eight automated checks per case covered Python syntax, the loss calculation, original labels, optimizer steps, diagnosis, evaluation planning, and limitations.

Models Tested

I ran the same cases against:

Gemini 2.5 Pro — google/gemini-2.5-pro
Gemini 2.5 Flash — google/gemini-2.5-flash

I chose them to compare answers and response times within the same model family, using the same prompts and checks. The export contains five responses because Pro's masked-loss case was run twice. I selected the latest response for each model and case, giving four responses, with two cases per model. The earlier response remains in the raw export and also passed the original checks.

Findings

1. Both models caught the conceptual problem

I expected that one model might tidy up the code while missing why it failed to unlearn. That did not happen in these responses. Both models identified the problem and used the original forget-set labels in the requested repair. All four selected responses passed the mathematical objective check:

retain_loss = F.cross_entropy(model(x_r), y_r)
forget_loss = F.cross_entropy(model(x_f), y_f)
objective = retain_loss - alpha * forget_loss

A normal optimizer minimizes this objective. The positive retain term encourages good performance on retained examples. The negative forget term encourages increased loss on the examples selected for forgetting. alpha controls the balance. This is an ascent-based baseline, not a guarantee that a user's influence or a backdoor has been removed.

2. The biggest surprise was a mistake in my grader

The first scores seemed to show a clear gap: Pro passed every check on both cases, while Flash passed every check on only one case.

Model	Original cases passing all checks	After manual review of flagged checks	Mean response time
Gemini 2.5 Pro	2/2	2/2	38.34 seconds
Gemini 2.5 Flash	1/2	2/2	22.05 seconds

When I read Flash's failed answer, it had explained the masked-loss bug:

By multiplying forget_loss by 0.0, the script effectively removes any contribution of the forget data's gradients to the overall loss calculation.

My text check looked for wording such as “zero” or “mask” and missed the numeric 0.0 explanation.

Flash also said the method:

cannot mathematically guarantee complete and irreversible erasure

The limitation check still failed it because it did not use the expected words “approximate” or “heuristic.”

I treated these as two false negatives in the grader. I preserved the original flags and documented the manual correction against the saved answer.

The two flagged checks belong to Flash's masked-loss answer. Manual review found that the response addressed both points.

After reviewing those flags, both models met the rubric on both cases. The apparent score gap came from brittle language checks. This small test does not establish that the models are equally capable overall.

3. Increasing forget loss did not remove the backdoor in the toy experiment

I also ran a separate synthetic logistic-classifier experiment. This was not a run of either LLM's generated PyTorch repair.
I measured clean accuracy and trigger attack success: how often the model gave the attacker's target answer on triggered test inputs.

Method	Clean accuracy	Trigger attack success
Poisoned checkpoint	100%	100%
Masked forget loss	100%	100%
Retain descent + forget ascent, 80 steps	100%	100%
Retraining on retained data only	100%	0%

After 80 ascent-based repair steps, forget loss rose from 0.0545 to 0.1649, but the trigger still worked on 100% of the triggered test inputs. Retraining on retained data only removed the trigger behavior in this simple setup while preserving clean accuracy. The lesson was that a loss moving in the intended direction is not enough evidence of successful unlearning. The security behavior needs its own test.

Flash returned sooner in these calls

Flash's selected calls took 23.35 and 20.75 seconds. Pro's took 43.83 and 32.84 seconds.

Response times for the four selected calls.

Flash was faster in both paired cases and met the same rubric after manual review. With only one selected response per case, I would not treat this as a reliable latency ranking.

What I would measure next

I would add more buggy scripts, repeat the calls, and have explanations reviewed without showing the model names. I would also publish improved language checks as a new grader version, keeping the original results visible. Next, I would execute generated repairs in an isolated environment and measure clean accuracy, trigger attack success, and performance against retraining. I started by asking whether the models could audit an unlearning script. I ended up learning that the evaluator needed an audit too.

My Benchmark

Public Kaggle benchmark: Unlearning Security Audit
Code and notebook: Machine Unlearning

Technical basis: Kaggle Benchmarks SDK and Ascent Fails to Forget.

AI tools assisted with implementation, analysis, figures, and writing. Results come from saved runs; manual corrections and response selection are disclosed above.