Local AI Game 🚀: AFK.exe + Ollama in Nature (Offline)
Discover a local AI game offline with AFK.exe + Ollama. Learn local-first AI, React Three Fiber, GPS privacy, and setup trade-offs—start today!
AFK.exe Turns Coding Breaks Into a Game Loop
Most productivity apps try to keep you chained to your desk. AFK.exe does the opposite. You complete a coding contract, spend a bit of energy, then step outside to earn it back. A walk can also unlock a photo mission. When you come back, a local AI model checks the photo and, if it fits the mission, helps you earn rewards for growing your virtual office.
That setup makes AFK.exe more than a cute developer game. It's also a hands-on test of local-first AI: can a multimodal model add useful functionality to an app without sending photos, code, or location data to a cloud inference service? The project's answer is a small, tightly scoped system built with React, Three.js, GPS, and Ollama. The model has a limited job, and the rest is handled with deterministic rules.
This article breaks down how the game loop works, what the local AI actually does, and where the design makes trade-offs. It also separates the hosted browser demo from the full repository version, because they don't offer the same AI features.
What Is AFK.exe?
AFK.exe is a developer-themed progression game built around a loop that nudges you away from the screen. You start in a small 3D office, sit at a desk, and take short coding contracts. Completing a contract means fixing a bug and passing its authored tests. In return, you earn money, experience, and practice in skills like Debugging, TypeScript, Testing, Performance, and Async.
Work costs energy, and the way to restore it is to go outside. A qualifying walk usually lasts at least 10 minutes and takes you at least 150 meters from where you started. Walking earns fresh-air tokens, which you can spend on plants and office upgrades. Over time, a plain room can turn into a greener workspace with vines, warmer lighting, and better equipment.
The game loop is the product idea
The loop is simple: code, walk, notice something outside, then bring a little of it back to the office. That's the point. The outdoor part isn't a "later" add-on like a leaderboard or a badge system - it's the source of the energy and currency that drive progression.
The phone experience supports the walk. It can track the outing with GPS and includes an optional nature-photo mission. You can put the phone away and just check back when a mission appears. Walking earns rewards on its own, and the photo task gives you a reason to pay attention to what you're actually seeing instead of staring at a screen the whole break.
Back at the desk, AFK.exe also includes a companion named Inez (a small plant-headed character) and a career progression system. Five skills take you through ten career titles and ongoing mastery. Some milestones unlock developer workflows: an AI Debugger at level 2, a Code Optimizer at level 4, and a Test Generator at level 6. The features are meant to connect to coding, not just decorating a room.
The demo and the full app are different
The hosted browser build lets you explore the game and the phone experience. It does not host the local model. If you want the local AI, you'll need the repository version running on your own computer with Ollama installed and the model available locally.
There's also another important qualifier: the demo video uses labelled admin acceleration for the career tour. Its outdoor sequence relies on a sample image and admin approval. It doesn't show a real GPS-qualified walk or a successful photo check by the local model. The developer-tool screenshots show available workflows, not AI-generated outputs from that recording.
None of that is necessarily bad - it just means the demo shows the shape of the experience, not every underlying feature in a live, end-to-end run. Keeping those claims separate helps you understand what you can actually test in a browser versus what requires the local setup.
How the Local AI and Privacy Design Work
AFK.exe uses Qwen3.5 4B, an open-weight multimodal model served locally via Ollama. The model has two main roles: assessing a nature-mission photo and providing text-based developer assistance. The same local model is used for both, but the workflows are separate.
Photo checks are bounded, not authoritative
After a walk, the model examines a downscaled photo against the selected mission's visual criteria. It returns structured output: whether the image seems to match, an estimated confidence, a reason, and a review flag. Zod validates the response before the game uses it.
If the result is uncertain, you don't just get the bonus anyway. The game can hold it for review instead. That's a sensible way to use a vision model: give a plausibility judgement, but treat uncertainty as a reason to slow down rather than pretending the model is sure.
That said, there's a hard limitation: a model looking at a photo can't prove where or when it was taken. The project itself describes the image matching as a plausibility check, not proof of a real outing. GPS rules handle walk qualification separately, and the model handles visual matching. These shouldn't be confused with a tamper-proof verification system.
Deterministic rules stay out of the model's hands
One of the cleanest design choices is what AFK.exe does not ask AI to decide. Coding contracts are validated by authored test fixtures. Walk qualification uses GPS calculations on the phone. The model doesn't determine whether code tests passed or whether your walk hit the distance and time thresholds.
That separation matters because vision and language models are probabilistic. A test result or a distance calculation should be reproducible. Letting the model handle those decisions would add uncertainty without improving the underlying task. Instead, the model is used where interpretation can help: matching an image to a visual mission and generating suggestions for a developer.
The developer tools also stay behind a safety boundary. Generated suggestions show up as text and aren't executed automatically. That keeps you in control of what you apply. In coding, the difference between proposing a change and running it isn't cosmetic - it affects what level of trust and permission that feature requires.
Local processing reduces data sharing, but it's not magic privacy
AFK.exe is built to avoid an account, cloud inference service, and API key. Walk records and game progress are stored in IndexedDB. The phone can transfer a walk summary and re-encoded photos to the desk over a local network or via an outing file. That transfer doesn't include GPS coordinate history. Reward grants use a transaction, too, so importing the same outing again doesn't repeatedly pay out.
This means photos and code don't need to be sent to an external inference provider for the described AI features. It also makes the prompts and reward rules easier to inspect because they're in the open-source repository. The project is MIT-licensed, and the repo includes the game, phone PWA, a local Ollama adapter, tests, setup instructions, and third-party attributions.
But local-first doesn't automatically mean cost-free or "no data leaves your device" in every setup. Model downloads and initial setup still require internet access. Inference uses your computer's hardware and electricity. You still have to understand your device, your browser, and your local network setup. The practical benefit is less third-party data transfer - not a universal guarantee that nothing ever goes anywhere.
What the Implementation Gets Right - and What It Costs
The stack is set up for a browser-based game plus a phone companion, without relying on a hosted backend. The interface uses React, TypeScript, and Vite. The office is procedural Three.js geometry via React Three Fiber. Game progress, walk records, and photo evidence are stored in IndexedDB.
It's a workable combination for something visual and interactive. React handles interface state; React Three Fiber brings the 3D office into the web app; IndexedDB gives the browser a place to persist local data. The local model adapter is another component in the system, not the whole product.
A simple architecture with explicit boundaries
At a high level, the data flow looks like this:
- The phone records a walk and captures a mission photo.
- A walk summary and re-encoded photo move to the desk, over a local network or as an outing file.
- The desk app stores the relevant data locally and sends the photo to a loopback-only adapter.
- Ollama runs Qwen3.5 4B on the computer.
- The app validates the model response before deciding whether to award a photo bonus.
This keeps the model as an optional local service inside a broader flow. It also narrows what gets transferred and makes an external inference API unnecessary for the feature.
There's no per-request provider bill, but inference isn't free. You pay with hardware, electricity, and time spent installing and running the model. Whether that trade-off feels worth it depends on your device and how patient you are with setup. If you have a capable computer and care about keeping images local, it may be a good exchange. If you want a plug-and-play mobile experience with zero configuration, it probably won't feel as good.
The phone is the least predictable part
GPS on a phone isn't a perfect always-on service. Depending on the device and browser, background location updates can pause when the screen is off. AFK.exe includes a pocket mode that tries to keep a minimal screen awake where supported, but it can't eliminate every platform-specific limitation.
This is a familiar product trade-off: keeping a screen active can make tracking more consistent, but it increases battery usage and won't work the same everywhere. So the experience needs to explain how tracking works, what permissions it needs, and what to do if the browser pauses. If the app depends on a walk being measured, device behavior has to be treated as part of the product - not just an implementation detail.
The same idea applies to photo missions. A photo check can be a playful reward, but it shouldn't be presented as proof of when or where you were. The design feels more believable when the reward is modest and the uncertainty has a clear outcome. That's also the safer option compared to pretending the model can reliably police whether you took a genuine walk.
Open source makes the trade-offs inspectable
Open source matters here beyond distribution. A user or contributor can look at the prompts, the uncertainty threshold, the walk rules, and the transfer flow. They can add missions or adjust the Ollama integration without first getting access to a paid API key.
That doesn't mean every user will audit the code, or that every local setup will behave identically. But it does change the conditions for scrutiny. With the MIT license and published implementation, technically minded users have a way to verify what the app claims it does.
And honestly, the broader product idea is the strongest part: the most valuable action happens away from the app. The software gives you a reason to take a break, but the break itself is the walk - and the attention it forces you to pay. Local AI supports that loop without turning the cloud into the center of the experience.
How to Run the Full Version
The hosted browser build is the fastest way to try the office and the basic game loop. If you want local AI, use the repository version on a machine that can run Ollama. The basic setup is:
git clone https://github.com/bmartin2000/Gooutdoors.git
cd Gooutdoors
npm install
ollama pull qwen3.5:4b
npm run dev
Ollama needs to be running; if necessary, start it with ollama serve. The README also covers installing the phone PWA, local HTTPS, LAN pairing, and file transfer. Read those instructions before testing the phone workflow - especially if you plan to try GPS tracking across different devices.
A few expectations to set before you install:
- The model is local, but the initial download isn't offline. You'll need internet access for dependencies and the model.
- Your computer runs the inference. Performance depends on hardware, and the process uses power.
- The browser demo doesn't include hosted AI. For model-backed features, you need a local Ollama setup.
- GPS tracking depends on the phone and browser. Test what happens on your own device instead of assuming background tracking will always keep working.
- AI suggestions aren't automatically applied. Review the generated developer output before using it in your own code.
The implementation was developed with Codex assistance for tasks including debugging and refinement. The project write-up says the commit history makes the implementation visible, but it doesn't include a saved agent-session transcript. That distinction is worth keeping in mind: tool assistance can be part of the process without claiming a tool wrote the entire product.
For code and setup details, see the AFK.exe GitHub repository. The original project write-up includes demo context and implementation notes.
Conclusion
AFK.exe is an interesting local AI experiment because it keeps the model's job narrow inside a system you can actually follow. GPS calculations qualify walks, authored test fixtures validate coding contracts, and the model checks visual mission photos or generates developer suggestions. Those boundaries feel more convincing than handing every decision to AI.
The trade-off is real, though: local inference takes setup, suitable hardware, and power, and phone GPS behavior can vary. The hosted demo is helpful for exploring the game, but it isn't a substitute for the repository version if you want to test local AI.
If the idea sounds fun, start with the GitHub repository, read the setup notes, and try the phone workflow on your own device. Then take the walk - seriously. That's the part of AFK.exe no model can do for you.