DEV Community: Jarvis Wick

Slow Mode: the laziest way to go outside

Jarvis Wick — Sat, 24 Oct 2026 05:30:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Trailhead is a local-first Streamlit app that turns a few taps into a short outdoor outing. You pick an activity, how long you have, and where you are; it pulls live weather and remaining daylight from Open-Meteo, then asks a locally running open-weight model — Gemma 3 4B via Ollama — for an "outing card": a plain-language route, what to look and listen for this week, three off-screen challenges, and a one-line safety note. The card exports as printable HTML or PDF.

For Week 3, I asked the sloth question: what if the app made every decision, and the correct answer was "less"?

So in this story Trailhead gets Slow Mode: one button that refuses to let you plan anything.

Meet Theo — invented, but you know him. Theo will spend forty minutes choosing a podcast for a twenty-minute walk. He has 6,412 unread emails and a browser with 31 tabs, three of which are "best walking routes near me." He does not need another planner. He needs a planner that quits early.

Slow Mode is that. One click and it picks the lowest-effort option for every field: a walk (no gear), 15 minutes (the floor), the nearest green space, and a card whose only instruction is "walk to the end of your street and back. That's it." Then it drops him on the "Take me outside" screen — a single line, a return time, and no UI to get lost in.

The whole product becomes a permission slip to do almost nothing.

The Lazy Payoff

The challenge asks how much effort the project actually saves. In the story, Theo timed his old routine against Slow Mode:

Task	Before	With Slow Mode
Choosing an activity	4 min	0
Picking a route	6 min	0
Checking the weather	2 min	0 (automatic)
Deciding when to leave	3 min	0 (return time set)
Total	~15 min	1 click

Fifteen minutes of deliberation replaced by one click and a piece of paper. Theo's review, invented but plausible: "I wanted to argue with it and there was nothing to argue with."

The real payoff isn't the minutes. It's that the app has no settings to fiddle with in Slow Mode — nothing to optimize, no feed to scroll, no "just one more tweak." It ends the planning by removing the choices.

Demo

In the story: Theo opens Trailhead, hits Slow Mode, and gets a card for a 15-minute walk to the end of his street. The printer makes one page. He takes it, walks for fifteen minutes, and comes back. The app never asks him for an account, a rating, or a streak.

Code

How I Built It

The engine (real). Slow Mode isn't a separate model — it's the same engine with the decisions pre-filled. The model is constrained to a JSON schema and validated with Pydantic, so the output is structured rather than prose I have to parse:

response = client.chat(
    model=OLLAMA_MODEL,                       # default: gemma3:4b
    messages=[{"role": "system", "content": SYSTEM_PROMPT},
              {"role": "user", "content": prompt}],
    format=OUTING_CARD_JSON_SCHEMA,           # Ollama constrains generation
    options={"temperature": 0.3},
)
data = json.loads(response.message.content)
card = OutingCard(**data)                     # Pydantic validates

Slow Mode (the story's idea). It's a preset plus a stricter prompt: pick the smallest outing, the nearest green space, and exactly one thing to notice.

slow = UserInput(
    activity=Activity.WALK,
    time_available_minutes=15,
    location_name=nearest_green_space(lat, lon),
)
card = generate_card(slow, prompt_variant="smallest possible outing")

Everything else (real). Open-Meteo's geocoding and forecast APIs are free and keyless, so the only network call carries a city name or a coordinate. fpdf2 renders the PDF, render_html gives a print-CSS fallback, and SQLite keeps a local journal so past cards stay readable offline.

Stack: Python 3.15, Streamlit, httpx, the official ollama client, Pydantic, fpdf2, SQLite. No Node, no build step, no custom JavaScript.

Why Does Open Innovation Matter?

For a tool built around doing less, open matters in four very practical ways:

A small local model is enough. Slow Mode generates a deliberately tiny outing. A 4B model on a laptop handles that in seconds, with no cloud round trip and no account to create. The laziness extends to the setup.
It works at the trailhead. Generating a card is local inference against a local ollama serve. There's no signal required at the moment the app is supposed to get you out the door.
Nothing to monetize means nothing to optimize for. No telemetry, no usage stats (Streamlit's are disabled in config), no feed. Your walk isn't a data point.
Swappable by design. OLLAMA_MODEL changes the brain in one env var. If you want a faster, dumber model for a 15-minute walk, that's a legitimate choice — and it's yours to make.

The open part is why the app can be this boring. There's no growth team to satisfy.

My Agent Session

Prize Categories

I'm entering Best Use of Gemma — every card is generated by Gemma 3 4B running locally through Ollama, constrained by a JSON schema and validated with Pydantic.

Trailhead's First $19: a side hustle from the trailhead (Week 2)

Jarvis Wick — Sat, 17 Oct 2026 17:36:24 +0000

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

What I Built

Trailhead is a local-first Streamlit app that turns a few taps into a short outdoor outing. You pick an activity, how long you have, and where you are; it pulls live weather and remaining daylight from Open-Meteo, then asks a locally running open-weight model — Gemma 3 4B via Ollama — for an "outing card": a plain-language route, what to look and listen for this week at this latitude, three off-screen challenges, and a one-line safety note. The card exports as a printable HTML file or a PDF.

Then I asked the Week 2 question: who would actually pay for this?

Hikers won't. Hikers have phones. The person with money to spend and no signal is the person selling the walk — the independent nature guide standing at the trailhead, handing paper to strangers.

So in this story, Trailhead grows one button: "Export a guided-walk packet." Same open-weight engine underneath. It just prints a stack of cards instead of one.

The Customer Who Isn't Real

Mara Okonkwo is invented, but she's the person I had in mind. She runs Foothills Slow Walks, a weekend side hustle: $19 per walker for a 90-minute "listen to the forest" loop in the Blue Ridge foothills. Eight walkers on a good Saturday. One of them, most weeks, comes back the next Saturday.

Her problem wasn't the walk. It was the five minutes before it. She wanted to hand each walker a card with what was happening that week — the first of the spring peepers, the tulip poplars dropping, which birds had just arrived. She'd tried a phone app. It needed a cloud call and the trailhead has one bar of signal. It also wanted her route notes and her location on somebody else's server, which, for a guide whose whole product is a secret route she spent two years finding, was a non-starter.

So: a product that runs where she works, keeps her route private, costs nothing per card, and spits out something she can hand to someone with no phone at all.

Demo

In the story: Mara opens the app on a laptop in the passenger seat, types Slow Walk — Great Falls Loop, 90 minutes, 8 walkers, hits Export packet, and thirty seconds later the printer spits out a single letter-size page: six cards, each with the same route but a slightly different "challenge of the day," cut lines and all. She hands them out with a pen.

Code

How I Built It

The engine (real). The model is constrained to a JSON schema and validated with Pydantic, so the output is structured instead of prose I have to parse:

response = client.chat(
    model=OLLAMA_MODEL,                       # default: gemma3:4b
    messages=[{"role": "system", "content": SYSTEM_PROMPT},
              {"role": "user", "content": prompt}],
    format=OUTING_CARD_JSON_SCHEMA,           # Ollama constrains generation
    options={"temperature": 0.3},
)
data = json.loads(response.message.content)
card = OutingCard(**data)                     # Pydantic validates

If validation fails it retries once; if Ollama is unreachable it falls back to a template card, so the app never dead-ends in front of a customer.

The packet (the story's one new idea). Instead of rendering one card, the export loops over n walkers, generates a card per walker with a shared route but a varied challenge, then tiles them six-to-a-page for cutting:

cards = [generate_card(activity, route, i) for i in range(walkers)]
pdf = TrailheadPacket(start_with_6_cards=True)
for card in cards:
    pdf.add_cutout_card(card)   # 2 x 3 grid, letter size
pdf.output("slow_walk_packet.pdf")

Everything else (real). Open-Meteo's geocoding and forecast APIs are free and keyless, so the only network call carries a city name or a coordinate. fpdf2 handles the PDF, render_html gives a print-CSS fallback, and SQLite stores past packets so Mara can reprint last week's without regenerating it.

Stack: Python 3.15, Streamlit, httpx, the official ollama client, Pydantic, fpdf2, SQLite. No Node, no build step, no custom JavaScript.

Why Does Open Innovation Matter?

For a side hustle, "why open" stops being philosophy and becomes the margin.

It runs where the work happens. Generating a packet is local inference against a local ollama serve. A closed API would strand Mara at the trailhead with one bar of signal — the exact place the product has to work.
Her route stays hers. The only thing that ever leaves the laptop is a city name to a keyless weather API. No account, no telemetry, no server holding the route she spent two years finding.
The math only works because inference is free. At $19 per walker, paying per-token for eight cards a session eats the side hustle. Local inference has no per-request cost, no quota, no pricing page that moves under her.
She can tune it to her woods. OLLAMA_MODEL swaps the brain in one env var; a fine-tune on her route's species would make the seasonal highlights better than any general-purpose API knows how to be.

The open part isn't a talking point here. It's the whole reason the product clears a price a real person would pay.

The $19

In the story, Mara's first packet costs her nothing to produce and sells for $19 as part of a Saturday walk. She doesn't pay for the software. She pays — the second time — with a request.

"Can it know my loop's birds better?"

Which is, it turns out, a feature request an open-weight model can actually grant.

My Agent Session

Prize Categories

I'm entering Best Use of Gemma — the card generator is Gemma 3 4B running locally through Ollama, constrained by a JSON schema and validated with Pydantic.

Trailhead: Gemma 3 plans your walk on your own laptop - then gets you off the screen

Jarvis Wick — Sat, 10 Oct 2026 10:36:04 +0000

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

Ja4V8s28Ck / trailhead

Trailhead

A local-first Streamlit app that uses an open-weight LLM to turn a few taps into a short outdoor outing, then gets you off the screen.

What it does

Pick your outing — Activity (walk, run, hike, birding, nature observation, photography), time (15 min – 3 hrs), and location (city name or lat/lon)
Get conditions — Fetches live weather, sunrise/sunset, and daylight remaining from Open-Meteo (free, no API key)
Generate a card — A locally running open-weight model (Gemma 3 4B via Ollama) creates an "outing card" with
- A general route suggestion (no fake map data)
- What to look and listen for this week at your latitude and season
- 3 "off-screen challenges" (e.g., "Sit silently 3 minutes and count the sounds you hear")
- A one-line safety note based on actual weather and daylight
Go outside — Download the card as HTML or PDF, or tap "Take me outside" for…

View on GitHub

What I Built

Trailhead is a local-first Streamlit app that turns a few taps into a short outdoor outing — and then deliberately gets out of your way.

You pick three things: an activity (walk, run, hike, birding, nature observation, photography), how much time you have (15 min to 3 hours), and where you are (a city name, or raw lat/lon). Trailhead pulls the live weather and remaining daylight from Open-Meteo, then asks a locally running open-weight model — Gemma 3 4B via Ollama — for an "outing card":

A route suggestion in plain language ("loop through the nearest green space, turn around at the halfway mark") — deliberately no invented trail names and no fake map data.
Seasonal highlights for this week at this latitude: what to look and listen for right now.
Three off-screen challenges — concrete, phone-free things to do, like "sit silently for three minutes and count every distinct sound you hear."
A one-line safety note grounded in the actual conditions ("dark in 40 min — bring a headlight or turn around by 6:20pm").

Then it tries to make the screen the shortest part of the experience. Download the card as a self-contained HTML file or a PDF and print it. Or hit "Take me outside", which replaces the whole UI with a single line — "See you in 42 minutes" — and a return time. When you get back, you jot down 1–3 notes. Everything is stored locally in SQLite, and past cards stay readable offline.

Who it's for: anyone who wants a reason to step outside but doesn't want to spend twenty minutes scrolling for one. The whole point is under 60 seconds on-screen, then out the door with a piece of paper.

Demo

Code

How I Built It

The core is open-source AI running locally, so let me start there.

Gemma 3 4B via Ollama, with structured output. I didn't want to parse prose out of a model at runtime, so the model is constrained to a JSON schema and the result is validated with Pydantic:

response = client.chat(
    model=OLLAMA_MODEL,                      # default: gemma3:4b
    messages=[{"role": "system", "content": SYSTEM_PROMPT},
              {"role": "user", "content": prompt}],
    format=OUTING_CARD_JSON_SCHEMA,          # Ollama constrains generation
    options={"temperature": 0.3},
)
data = json.loads(response.message.content)
card = OutingCard(**data)                    # Pydantic validates

Ollama keeps generation inside the schema; Pydantic catches the rest. If either fails, we retry once, and if Ollama is unreachable the app falls back to a template card, so it's never a dead end.

Weather without an API key. Open-Meteo's geocoding and forecast endpoints are free and keyless, so the only thing Trailhead ever sends over the network is a city name or a pair of coordinates. Everything else — the prompt, the model call, your notes — stays on the machine.

Rendering. render_html produces a self-contained file with print CSS, so "download" really means "print it and take it with you." fpdf2 produces a matching PDF. Both are pure Python.

Storage. A single SQLite file. Cards are serialized with model_dump_json() and read back through the same Pydantic models, so a saved card and a fresh one are the same object.

Stack: Python 3.15, Streamlit, httpx, the official ollama client, Pydantic, fpdf2, SQLite. No Node, no build step, no custom JavaScript.

Why Does Open Innovation Matter?

For Trailhead the answer is concrete:

It works where you actually need it. Generating a card is a local inference call — no cloud API. Once the model is pulled, the generator runs entirely against a local ollama serve. A closed API would make the app useless the moment you lose signal, which is exactly where an outdoor app should work.
Location data never leaves the device. Trailhead knows where you walk. The only network call carries a city name or a coordinate to a keyless weather API — no account, no telemetry (Streamlit's usage stats are disabled in config), and no server holding a record of your habits.
The model is swappable. OLLAMA_MODEL=llama3.2:3b streamlit run app.py is the entire model-swap story. A 3B model is faster on a laptop; a larger one gives richer seasonal detail. You could fine-tune your own and point the same code at it — no provider, no pricing page, no rate limit.
It costs nothing to run. No keys, no billing, no quota. A hobby project that gets people outside shouldn't depend on anyone's credit card, least of all the runner's.

The open part isn't decoration. It's the reason the app can run offline, keep your data, and be changed by whoever runs it.

Prize Categories

I'm entering Best Use of Gemma — the entire card generator is Gemma 3 4B running locally through Ollama, constrained by a JSON schema and validated with Pydantic.

Groundtruth: a revision partner for my cousin that only answers from his notes

Jarvis Wick — Sun, 04 Oct 2026 15:05:09 +0000

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

What I Built

My cousin asked me to be his revision helper. He was working through college coursework and wanted someone to quiz him on it. I could say yes to the first session and not to the six after it, so I built the part that does not need me in the room.

He had a specific problem before this one. He re-reads his notes until they feel familiar, then walks into an exam believing he knows the material. When he asked a chatbot to quiz him instead, it explained things that were never in his syllabus, produced citations that looked completely real and told him he was right when he was not. That is not a bug in that tool. It has every fact on the internet and no idea which lines of his notes are the ones that matter.

Groundtruth reads his notes and does three things:

writes questions that can be answered only from that material
grades his free-text answers against it
shows the exact line that settles every verdict

When his notes do not cover something, it says so instead of guessing.

He is using it now. I did not manage to get a quotable reaction out of him, which I choose to read as a good sign.

Demo

The video is the bundled cell biology sample, so you can watch the refusal happen without supplying your own notes. Ask it about mitosis and it will tell you the notes never covered mitosis, because they do not.

Code

Ja4V8s28Ck / groundtruth

A revision partner

Groundtruth

A revision partner that only answers from a student's own notes and shows the exact line it used for every verdict. Demo link.

Why I built it

He had a specific problem before this. He re-read his notes until they felt familiar, then walked into an exam believing he knew the material. When he asked a chatbot to quiz him instead, it explained things that were never in his syllabus, invented citations that looked real and told him he was right when he was not. That is not a bug in that tool. It has every fact…

View on GitHub

https://github.com/Ja4V8s28Ck/groundtruth

Python and Streamlit, about 1,500 lines. You need Ollama running and two models:

ollama pull qwen3:4b           # writes and grades, 2.5 GB
ollama pull nomic-embed-text   # finds passages, 274 MB

Then pip install -r requirements.txt and streamlit run app.py. Click "Use the sample notes" and you have a working session in about 20 seconds. No API key, no account, nothing to sign up for.

How I Built It

The model is not bolted onto a search box. Take it out and there is no product left, because there is no keyword path to writing a good revision question.

Citations you can check

This is the part I care about most. Most AI study tools tell you whether you were right. This one shows why it thinks so, in the words of your own notes.

Every chunk keeps the line range it came from. When the model grades an answer it has to return a verbatim quote and the chunk id. Back in Python that quote is checked against the real text with a sliding window match, which tolerates the model paraphrasing slightly and then returns the exact span from the file.

If the model returns correct and cannot produce a quote that exists in the notes, the verdict is downgraded rather than shown. You can open the file and check every claim the app made.

Three guards, because a 4B model is generous

qwen3:4b is small enough to run on a laptop and loose enough to grade things correct that are not. Three checks in the store catch that:

Quote verification. A correct verdict with no matching quote in the notes is never displayed.
Term coverage. If the retrieved passage covers almost none of the terms in the answer, the verdict is downgraded. This is what makes the refusal falsifiable. The app cannot be wrong by inventing and it cannot be wrong by being vague.
No spoilers. The hint shown for a wrong answer is checked so it does not hand over the answer itself.

Term coverage came out of a failing test. A vague answer was being graded incomplete, but that word implies the notes covered it and for a vague answer that is not knowable. So I made the claim falsifiable instead. If the notes barely mention what you wrote, the app is not permitted to assert that the notes covered it.

The model thinks before it answers and you cannot stop it

This was the surprise of the build. My machine has an RTX 4060 and Ollama reports the model running at 100% GPU, yet a call whose entire real answer was one word took 4.6 seconds and generated 166 tokens:

wall 4.64s   generated 166 token done=stop
reply: 'Hmm, the user just asked me to reply with the single word "ready"...'

qwen3 is a reasoning model and Ollama ignores think: false for it. So did enable_thinking through the chat template kwargs and through the options bag. So did asking it in the system prompt not to reason.

Attempt	Tokens generated
`think: false` (the default we send)	166
`chat_template_kwargs.enable_thinking=false`	133
`options.enable_thinking=false`	162
System prompt "answer directly, do not reason"	146

Roughly 150 tokens of preamble on every single call and it is 80 to 90 percent of the latency. Nothing suppresses it on this model.

What did help was noticing the calls were independent. Each passage is asked about separately and the calls share no state, so they now run in a thread pool:

build_session(count=8)   before   16.81s
build_session(count=8)   after    12.18s

That is only 28 percent and the reason is worth being plain about. The GPU is saturated on generation, not on request overhead, so overlapping the calls hides the setup cost and nothing else. 35 tokens per second is simply what a 4B model generates on that chip. The real fix is a model that does not think and I did not have time to swap one and re-verify the guards before submitting.

A bug that only appeared once I added an embedding model

Worth writing down, because it is the kind of failure that hides.

My indexer looped over the chunks and embedded them one at a time, but it returned early as soon as the vector array existed. Chunk 0 got a real vector and every other row stayed zero. Semantic search filters zero scores out, so it cheerfully returned nothing but chunk 0 while the header still said the search was semantic. Grading was citing the first section of the notes and nothing else.

It never fired while I had no embedding model installed, which is exactly the window in which I was testing everything else. The moment I pulled nomic-embed-text it was live. The fix was one batched call for the whole document:

rows with a real vector: 10 of 10
probe "sodium potassium pump"  -> chunks [3, 1, 6]
probe "glycolysis"             -> chunks [8, 3, 2]

Why Does Open Innovation Matter?

His notes are not mine to upload. Course material, a lecturer's slides and the record of what a student is weak at are not the builder's to hand to a third-party server. It runs over localhost, so the notes never leave the machine. There is no server to leak them to because there is no server.

It has to work with no network. Revision happens at 7am in a quiet room the night before an exam and depending on a cloud API means depending on someone else's uptime and someone else's billing.

There is a cost argument as well and it is the weakest of the four. A small model on your own hardware is free and renting an equivalent one costs a few cents a session. Free is not the interesting part. It's about keeping our data to ourselves.