Outside Window: A Local AI Agent That Gets You Off the Screen

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

What I Built

Outside Window is a privacy-first personal agent that helps someone take one realistic outdoor break today.

Most wellness apps turn going outside into another dashboard to manage. Outside Window takes the opposite approach: the screen should be the shortest part of the experience.

The app gives the user:

1. A recommended time window for today.

2. A short ten-minute outdoor micro-quest.

3. A one-tap “I went outside” or “Not today” check-in.

4. A local outing log that can be exported as CSV.

5. A learning loop that can eventually improve its recommendation from the user’s real outcomes.

The first recommendation is intentionally transparent rather than pretending to be a highly accurate model before enough personal data exists. The current demo uses a clear heuristic and records the outcome needed to train a personal model later.

The project is for people who work, study, or spend too much time online and want a gentle nudge rather than another productivity system.

Synthetic seed rows are clearly labelled and are not presented as real user behaviour or model evidence.

Demo

Repository: github.com/BOTPranav-01/outside-window

Run the local demo:

PowerShell

git clone https://github.com/BOTPranav-01/outside-window.git
cd outside-window
npm install
Copy-Item .env.example .env
npm run seed
npm run dev

Open:

Plain text

http://localhost:8787/

The demo flow is:

1. Load today’s recommendation.

2. Read the generated ten-minute quest.

3. Tap I went outside or Not today.

4. Inspect the saved event at /api/outings.

5. Export the user-owned log from /api/export.

The Gemma path can be enabled locally with Ollama:

PowerShell

ollama pull gemma3:4b
npm run dev

Without Ollama, the app uses a safe deterministic fallback quest so the core demo remains functional offline.

A deployed URL and short screen recording should be added here before publishing. Do not submit a fake URL:

Plain text

Live demo: TODO — add after Render deployment
Video demo: TODO — add a 60–90 second recording

Code

The complete open-source code is available here:

View the Outside Window repository on GitHub

The repository includes:

• TypeScript Hono API

• Node SQLite persistence

• CSV import/export

• Zod validation for model-generated quests

• Open-Meteo client with coarse coordinate rounding and caching

• Feature builder for time, weather, and outcome data

• Python prediction sidecar

• Leave-one-out evaluation against a fixed 6 PM baseline

• Docker Compose configuration

• Render service and worker configuration

• Tests for the contracts, database, weather features, and workflow recovery

• MIT license

How I Built It

Local-first data ownership

The outing history is stored in SQLite on the machine running the app. The user can export it to CSV or import it again. There is no hosted user database in the default setup.

This makes the privacy boundary understandable:

• Outing history stays local.

• Synthetic seed data is explicitly labelled.

• Open-Meteo receives only coarse-rounded coordinates when weather is enabled.

• Gemma can run locally through Ollama.

• Optional external providers are isolated behind configuration.

• No raw voice recordings are stored by the application.

Open-source AI with Gemma

The micro-quest generator uses a provider adapter pointed at Ollama:

Plain text

OLLAMA_BASE_URL=http://localhost:11434
OLLAMA_MODEL=gemma3:4b

The prompt asks Gemma to return only a strict JSON object containing:

• quest title

• one to three steps

• exactly ten minutes

• a safety note

The response is parsed and validated with Zod. Invalid or unavailable model output cannot silently become a success-shaped response; the application falls back to a safe deterministic quest.

This is where open innovation matters technically. The model provider can run on the user’s machine, can be swapped through environment variables, and does not require sending a personal outing history to a closed AI API.

Prediction and honest evaluation

The prediction sidecar defines the intended features:

• hour

• weekday

• temperature

• apparent temperature

• precipitation probability

• rain

• humidity

• wind

• eventual outing outcome

The evaluation script compares a fixed 6 PM baseline with a leave-one-out classifier and prints a Markdown table.

The included demo dataset is synthetic and labelled as synthetic. It is only a repeatable smoke test for the evaluation pipeline. It is not evidence that the model predicts real people accurately. Real accuracy requires real user-owned observations collected over time.

Durable state

The user-day workflow stores its state locally and has a recovery test that simulates a worker restart without duplicating the user-day state.

The next production integration is Temporal: the same state machine will compute a window, sleep durably, send a nudge, wait up to 45 minutes for a check-in, record the outcome, and trigger a refit.

I kept that distinction explicit rather than claiming a local state test is already Temporal Cloud.

Why Does Open Innovation Matter?

A closed wellness assistant could produce a polished recommendation, but the user would have little ability to inspect or own the system making decisions about their daily behaviour.

Open innovation makes several things possible here:

• Local inference: Gemma can run offline through Ollama.

• Model choice: the provider can be swapped without rewriting the application.

• Inspectable features: the recommendation inputs are visible rather than hidden.

• User-owned history: SQLite and CSV make the outing log portable.

• Honest evaluation: the fixed 6 PM baseline is included instead of reporting only a model score.

• Community improvement: the feature builder, validator, and workflow state are open to review and extension.

The project is intentionally modest about what it knows. It does not claim that a model can solve motivation. It creates a small feedback loop that respects the user and improves only when the user supplies real outcomes.

My Agent Session

This section is optional. Add the public DevRelay session link after saving and making the session public.

Plain text

TODO — add public DevRelay agent session link

I used AI assistance during implementation and will disclose that accurately in the DEV article settings.

Prize Categories

Gemma

I am entering the Gemma category only when the submitted demo runs Gemma locally through Ollama. Gemma generates the structured ten-minute quest, and the application validates the output before showing it to the user.

I am not claiming categories for integrations that are only configuration placeholders.

Limitations

This is a new project built during the Week 1 challenge window.

Current limitations:

• The recommendation is still a transparent demo heuristic.

• The included evaluation rows are synthetic and cannot demonstrate real-world accuracy.

• The real TabPFN integration is not yet claimed.

• Temporal Cloud orchestration is not yet claimed.

• ElevenLabs audio is not yet claimed.

• Sentry tracing is not yet claimed.

• A public Render deployment still needs to be added before submission.

• Voice check-in is planned but not part of the current validated demo.

These limitations are deliberate. The goal is to show what works, identify what remains, and avoid presenting scaffolding as a finished integration.

Credits and Disclosure

Built with TypeScript, Hono, Node SQLite, Zod, Vitest, Python, FastAPI, Open-Meteo, Ollama/Gemma, Docker, and Render configuration.

The project is MIT licensed. No non-trivial borrowed code is included without attribution.

AI tools assisted with implementation. The repository, application structure, tests, documentation, and integration decisions were created for this challenge project.