DEV Community: Pranesh Nikhar

Off-Peak: the AI agent whose best feature is doing nothing

Pranesh Nikhar — Fri, 23 Oct 2026 18:01:29 +0000

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

What I Built

I have a folder of ten documents I keep not summarizing. Meeting notes, an invoice, a sleep study, a paper I saved, receipts. The obvious fix is an agent that runs immediately. That agent is a bad roommate: it spins the fan, drains the battery, and interrupts me to tell me it is working.

Off-Peak is the opposite. You hand it a pile and a deadline. It watches your laptop's idle time, battery, and thermal state, predicts how long the work will take, and waits until you leave. If you come back early, it pauses after the current item. If the lid closes, it resumes from the last finished item. In the morning, it leaves a report.

It is a scheduler, not a chatbot. The model does the work; the scheduler decides whether the work is worth doing now.

Demo

The recorded run used ten documents and a compressed day. The human is away at lunch and in the evening. Off-Peak deferred 21 times, worked only in those away windows, and finished all ten before the simulated 10:30 PM deadline.

	Baseline: run everything now	Off-Peak
Documents finished	9/10 (one provider 503)	10/10
Interruptions	9	0
Energy while present	1.01 Wh	0.00 Wh
Energy while away	0.00 Wh	3.09 Wh
Model time	130 s	398 s

The baseline finished in 130 seconds and lost one document to a provider 503. Off-Peak took 398 seconds of model time across the day. It is slower. That is the point. It moves the work out of the time I am using the laptop. Nine context switches became zero.

The honest caveat: the Gemma 4 31B endpoint returned intermittent 500/503s during the run. Three documents used Gemma; the rest fell back to Gemini 3.8 Flash. The router kept the queue alive, which is what a durable scheduler is for. The repo also has a fully local Ollama path, and the default model is open-weight Gemma 4 31B.

Code

github.com/praneshnikhar/off-peak

The core of the scheduler is small enough to read:

if state.user_present and self.config.only_when_away:
    if self.config.deadline_override and now >= latest_safe:
        return Decision(
            action="run",
            reason="deadline pressure: the latest safe start has arrived",
        )
    return Decision(
        action=wait_action,
        reason="you are at the keyboard; the latest safe start is ...",
    )

The other three gates are battery, thermal, and window length. If they all pass, the worker runs at most two items per tick, writes the output, checkpoints the item, and yields. Pause is checked before every item, so coming back to the desk is a soft stop, not a lost batch.

How I Built It

Stack: Python 3.10, SQLite, psutil, the Gemini API for Gemma 4 31B, Ollama as the local path, a stdlib HTTP dashboard, and 13 tests.

Queue and checkpointing. Every file is an item with a status. The output is written before the item is marked done. On startup, any running job becomes paused; the worker resumes from the first pending item. Sleep, a crash, or a closed lid costs at most the item in flight.

Telemetry. macOS idle time comes from ioreg, battery and thermal state from pmset, CPU and load from psutil. Linux uses xprintidle and /sys. The scheduler only sees a SystemState dataclass, so the same policy runs against real telemetry or the compressed day.

Prediction. The default predictor is a transparent heuristic calibrated on the agent's own runs: items * overhead + chars/1000 * seconds_per_kchar. The repo also includes a TabPFN adapter that trains on the local run log and reports holdout MAE against a median baseline. The local TabPFN weights need a one-time license token; without it, the calibrated heuristic is used. I chose not to fake a learned predictor for the demo.

Model routing. Gemma 4 31B is the default. The router filters thought parts from the response, parses strict JSON, retries rate limits, and falls back to Gemini 3.8 Flash on provider 500/503. A circuit breaker skips the primary for ten minutes after a failure, so the rest of the queue does not pay the timeout again. Every run records the model that actually handled it. The fallback is visible in the report, not hidden.

Dashboard. One HTML file, one JSON endpoint, no build step, no external fonts or scripts. It reads the same SQLite file as the CLI. The timeline is the audit log: green worked, grey waited, amber paused for you.

What broke. The first version ran the whole pile immediately, which is exactly the behavior I was trying to avoid. The second version paused on user presence but did not have a latest-safe-start calculation, so a job could wait forever. The deadline math is what makes laziness safe. The Gemma endpoint was the third surprise: open-weight models are not automatically more reliable than closed ones. The answer is not to hide the failure; it is to route around it and log it.

Why Does Open Innovation Matter?

The decision layer has to be local. A hosted agent cannot see my battery, my thermal state, or the fact that I just walked back to the desk. Off-Peak's scheduler is a small policy over local telemetry. That is the part that makes the project work. The model is replaceable; the context is not.

Patience is only free with open weights. A metered API makes "run 500 small jobs overnight" an economic decision. A downloaded model makes it a scheduling decision. The marginal cost of deferring is zero, so the agent can afford to be picky about when it runs.

The model is swappable. Gemma 4 31B through the Gemini API for throughput, Gemma through Ollama for a fully offline run, or another model behind the same summarize interface. The policy does not change. When the Gemma endpoint failed, the fallback was a configuration, not a rewrite.

My files stay mine. Off-Peak never uploads files. In API mode, the text of a document is sent as a prompt to the model endpoint; the queue, outputs, telemetry, and history stay in SQLite on the laptop. In Ollama mode, nothing leaves the machine.

The failure is inspectable. When the endpoint returned 500/503, the fallback and the checkpoints were visible in the report. I could see which model handled each document. There was no opaque service deciding to drop the queue.

The Lazy Payoff

9 interruptions avoided.
0 minutes watching a progress bar.
3.09 Wh of estimated model energy moved off my active hours.
10/10 documents finished before the deadline.
The most productive thing my laptop did this week was while I was not there.

The point is not that the agent is fast. It is that the agent is patient. Slowness is not a bug; it is a scheduling decision.

Limitations

The recorded day is compressed, and the energy numbers are estimates from model time and a fixed laptop wattage. Ten documents is a demo, not a benchmark. The Gemma endpoint was intermittent, so the model mix is reported honestly. Calendar integration is the obvious next step for the idle horizon.

Prize Categories

Best Use of Gemma. Gemma 4 31B is the default model for the work. The recorded run used it for the documents it could, and the local Ollama path uses Gemma for a fully offline run. The scheduler is model-agnostic, but Gemma is what makes the no-API-key path real. I am also entering the overall prize; the TabPFN adapter is in the repo, but I am not claiming that category because I could not run the gated weights in this environment.

What shaped this

The Hidden Physics of AI on Your Own Machine: Inference Engineering, Local-First by John Afariogun — local inference is a physical problem, not just a privacy checkbox.
30 Days of a Local AI Agent on My Own Machine: What Actually Broke by galagent — the failures that matter are restarts and resource contention, which is why checkpointing is central here.
Temporal + AI Agents: The Missing Piece for Production-Ready Agentic Systems by akki907 — the durable-execution lesson, applied here with SQLite checkpoints rather than a Temporal cluster.

Try it

Repo: github.com/praneshnikhar/off-peak

git clone https://github.com/praneshnikhar/off-peak
cd off-peak
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
cp .env.example .env  # add GEMINI_API_KEY
python -m offpeak demo --backend gemini --model gemma-4-31b-it
python -m offpeak serve --port 8765

Fully local:

ollama serve
ollama pull gemma3:1b
python -m offpeak demo --backend ollama --model gemma3:1b

If the agent is going to do the work, it should at least have the manners to wait until I am gone.

Tender Radar: finding government tenders for small contractors, entirely on their own laptop

Pranesh Nikhar — Sat, 17 Oct 2026 14:45:15 +0000

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

What I Built

Tender Radar is a local-first government tender radar for small contractors.

A small electrical contractor bids on public tenders. Notices land on GeM, state portals and department boards, and the office has to answer three questions fast: which notices matter, is the firm actually eligible (turnover, similar work, licences), and how do we assemble the compliance paperwork without missing a clause. Miss one certificate and the bid is rejected on technical grounds; the preparation cost is gone. Many MSME contractors pay commission agents for this filtering, or simply miss tenders they would have won.

Tender Radar answers all three on the contractor's own machine:

Extracts the eligibility clauses from each notice (turnover, EMD, experience, licences, certifications)
Matches every clause against the firm's own documents (past bids, completion certificates, licence and ISO scans, audited financials), with a quote behind every claim
Flags risky terms in plain language (an EMD at 9% of value, a deadline three days out, a job ten times anything the firm has built)
Estimates win probability from the firm's historical bids with TabPFN
Drafts the covering letter, compliance statement and capability summary behind a citation guard that deletes any sentence its own documents cannot support

Who would pay: MSME contractors who pay agents per bid, or lose tenders they never saw. One won tender a year covers a year of tooling.

Demo

The board, ranked by fit and win probability:

One tender, with the evidence quote and document citation behind every requirement:

The print-ready bid pack it produces:

Everything above was computed locally, on purpose: the whole point is that it runs on the machine that holds the sensitive documents. Five commands take you from clone to board (full list in the README): install, generate the demo corpus, load it, scan 8 tenders, open the dashboard. The corpus is a synthetic but realistic electrical MSME (Jaipur, Class-A licence, about INR 3.7 crore average turnover), clearly labelled; live portal ingestion is scaffolded behind a key.

Code

github.com/praneshnikhar/tender-radar, built during the challenge window. scripts/eval_summary.py reproduces every number below.

How I Built It

Extraction, verdicts and drafting all run on Gemma 4 (gemma4:latest, 4.6B Q4) via Ollama, fully local. Amounts are parsed deterministically in code, because money must never depend on a model's mood. Matching is hybrid retrieval (a built-in TF-IDF embedder plus BM25) followed by one Gemma verdict pass per tender. Win probability is TabPFN v3.5 with thinking mode.

The citation guard is the part I am proud of, and it exists because a 4B model is not a frontier model. I caught it marking a clause "met" while its own rationale argued the firm fell short. So every "met" carries a quote, verified before display: exact match, or a fuzzy match where numbers are compared numerically ("INR 84.5 lakh" passes against "INR 84.50 lakh"; "two crore" fails against "2 crore"). A deterministic amount cross-check runs independently of the model.

Measured on an M3 laptop with 8 GB RAM, everything local: 51 clauses extracted across 8 tenders, every one with a parsed amount; verdicts 24 met, 5 partial, 19 missing, 3 unknown; the quote guard rejected 3 model citations (downgraded, reason recorded) and the cross-check caught 4 numeric conflicts; drafting removed 8 unsupported sentences across 16 sections; 21 LLM calls, about 83k tokens, US$0.00; 22 minutes for 8 tenders.

Win model ablation on the same time-ordered split (147 submitted bids): sklearn baseline AUC 0.731 / Brier 0.260 vs TabPFN v3.5 + thinking: AUC 0.752 / Brier 0.209. A should-I-bid number lives or dies by calibration.

Reading that shaped the guard: Your AI cited a real file. It still lied to you. and Making RAG admit when it is guessing.

Why Does Open Innovation Matter?

The data is competitively sensitive. A contractor's audited financials, past bids and pricing are the most sensitive documents the firm owns. Every document-reading and document-writing step is a local open-weight model. The only network call in the system is the TabPFN win model, and it sends features (value, distance, competitor count), never documents.
Zero marginal cost changes behaviour. The alternatives cost money per bid (agents) or per seat (SaaS). Local inference makes scanning one more notice free, so the firm checks every notice instead of the ones it can afford to check.
Small-data problems need small-data models, and a fallback. Win probability is modelled over about 220 historical bids; TabPFN is built for that regime, unlike closed AutoML that wants thousands of rows. The pipeline also degrades gracefully to sklearn, so it has zero mandatory external dependencies.

The honest trade-off: a 4B local model is slower and rougher at prose than a frontier API on a per-tender basis. The guard makes that safe, and the privacy and cost properties make it worth it. A closed API would have been easier to build and impossible to ship to this customer.

My Agent Session

Tender Radar: building a local-first government tender radar with Gemma 4, TabPFN, and a citation guard

You

Side Hustle challenge: build with open-source AI at its core. Government tender radar for small contractors. What it does: scrapes tender portals such as GeM, matches tenders to a small firm's past work and certifications, builds an eligibility checklist, and drafts the compliance sections. Open stack: a multi-agent pipeline with a vector index of the firm's documents, running locally. Who pays: MSME contractors who currently pay agents commissions or miss tenders entirely. Why open wins: their financials and past bids are competitively sensitive. Locked constraints: week 3 only for now, budget 0, electrical contractor persona. Create a new folder and start making everything, first plan.

Agent

Plan first, then build. Key decisions from environment reconnaissance:

▸ bash sysctl CPU + RAM; docker --version; ollama list

Input

$ sysctl CPU + RAM; docker --version; ollama list

Output

Apple M3, 8 GB RAM. Docker daemon hung (no response). Ollama installed with gemma4:latest (4.6B Q4, tools+thinking, 3.3GB) already pulled. No embedding model present. Local Postgres 17 on :5432 but no pgvector extension.

Decisions: SQLite as default store (fully local, ACID, brute-force cosine search is instant at demo scale) with an optional Postgres+pgvector path documented; open-weight LLM via Ollama; built-in hashed TF-IDF embedder as fallback so nothing needs downloading; TabPFN for the win-probability model with sklearn fallback. Architecture: notices -> extract -> match -> score -> draft -> bid pack. Prize targeting: Gemma (core LLM), TabPFN (win model), honest about everything else.

Agent

Scaffolded the project: pyproject, db/schema.sql, and the core modules.

▸ write src/tender_radar/ingest/fixtures.py

Input

src/tender_radar/ingest/fixtures.py

Output

FixtureGenerator: synthetic but realistic electrical MSME (Sharma Electricals & Co., Jaipur, Class-A license, ~3.7 crore avg turnover), 18 firm documents (audited financials, licence, ISO, 10 completion certificates, capability statement), 40 tender notices in authentic Rajasthan procurement style, 220 historical bid outcomes.

▸ write src/tender_radar/match/__init__.py

Input

src/tender_radar/match/__init__.py

Output

Hybrid retrieval: vector similarity + BM25 over document chunks, then one LLM verdict pass per tender. quote_verified(): exact match passes; fuzzy match with unit-aware numeric comparison. numeric_cross_check(): deterministic backstop comparing INR amounts in the clause vs the cited document.

You

dont pull any models, choose any model which i already have, but i will be using api key

Agent

Understood - using only gemma4:latest locally for LLM work, API key for TabPFN, and the built-in embedder. Smoke-tested Gemma 4 on clause extraction: it returned clean structured JSON with all five requirement types correctly segmented; a full generated tender notice read like a real state portal document.

Agent

Two real bugs found and fixed during the build worth recording:

▸ bash python -m pytest test/ (after debugging sqlite error)

Input

$ python -m pytest test/ (after debugging sqlite error)

Output

(1) 'table evidence has 11 columns but 10 values were supplied' - traced by counting the literal '?' placeholders in the SQL string; an edit had updated the Python tuple to 11 values but left 10 placeholders. Fixed the placeholder count, not the tuple. (2) Quote guard rejected 'INR 84.5 lakh' against a document saying 'INR 84.50 lakh' because tokenization split '84.50' into [84, 50]. Rewrote the check: currency amounts are parsed with units (crore/lakh -> same scale) and compared numerically; bare numbers still require verbatim token match. Verified: 'two crore' fails against '2 crore'; 'INR 6.2 crore' fails against 'INR 62 lakh'; equivalent reformattings pass. 8 tests pass.

Agent

Full measured run on 8 tenders, all local on the M3/8GB: 51 clauses extracted, every one with a parsed amount. Verdicts: 24 met / 5 partial / 19 missing / 3 unknown. The guard rejected 3 model citations (downgraded to unknown with reason) and the deterministic amount cross-check caught 4 numeric conflicts, including one where the model marked a clause 'met' while its own rationale argued the firm fell short. Draft guard removed 8 unsupported sentences across 16 sections. 21 LLM calls, ~83k tokens total, $0.00. Took screenshots of the board, detail page, and print-ready bid pack.

You

tabpfn_sk_REDACTED - this is the tabpfn key

Agent

Installed tabpfn-client and found the auth subtlety: the library reads TABPFN_TOKEN, not TABPFN_API_KEY, so the config now accepts both and calls set_access_token explicitly. A/B tested checkpoints on the same time-ordered 75/25 split over 147 submitted bids:

▸ bash compare default vs v3.5_default vs v3.5_default+thinking on the same split

Input

$ compare default vs v3.5_default vs v3.5_default+thinking on the same split

Output

default checkpoint: AUC 0.6713, Brier 0.2137. v3.5_default: AUC 0.6713, Brier 0.2137. v3.5_default + thinking(medium): AUC 0.7378, Brier 0.2084.

Thinking mode became the default. Final eval: sklearn baseline AUC 0.731 / Brier 0.260 vs TabPFN v3.5+thinking AUC 0.752 / Brier 0.209 - better on both, and calibration is what a 'should I bid?' number needs.

You

use the devrelay tool to make a submission for week 2 (Side Hustle), as this is a week 2 project

Agent

Submission workflow: pushed the repo to GitHub (praneshnikhar/tender-radar, built within the challenge window), generated web-sized screenshots for the post, extracted the exact DEV submission template from the challenge page, saved this session (scrubbed, no keys or local paths), and published the submission post with the required devchallenge and hf26challenge tags, entering Best Use of Gemma and Best Use of TabPFN.

Prize Categories

Best Use of Gemma: Gemma 4 does all clause extraction, verdicts and drafting, running locally via Ollama.
Best Use of TabPFN: TabPFN v3.5 with thinking mode is the win-probability model, with a same-split ablation against an sklearn baseline.

Built in a day for Hacktoberfest Week 2. The firm's data never leaves the laptop; the bills never arrive.

WanderLog: an offline field journal that answers "where did I see that kingfisher last time?"

Pranesh Nikhar — Thu, 08 Oct 2026 17:15:26 +0000

I have a habit of seeing things outside and then losing them to my own memory. The peacock that called from the fog. The kingfisher that dove twice off the jetty and came up with a fish. The lizard big enough to hiss like a bicycle pump.

So I built WanderLog — a local-first field journal that turns my coding agent into a naturalist's notebook. It's a Model Context Protocol (MCP) server. I go outside; when I get back I record a thirty-second voice memo of what I saw, and one command turns it into structured sightings and a walk. Everything else — remembering, finding, connecting — happens on my own machine, with open-source AI, with no network.

Stack: TypeScript · MCP (Model Context Protocol) · SQLite · ONNX Runtime · Transformers.js · open-weight embeddings (all-MiniLM-L6-v2) · local gemma3:4b via Ollama · ElevenLabs Scribe (optional) · Sentry gen_ai tracing
Code: github.com/praneshnikhar/wanderlog

What I Built

WanderLog is a field journal for the person who notices things outside and forgets them: the birder without a checklist, the hiker who wants to remember which trail had fog on the lake, the person who sees a peacock on the commute and wants to know whether it's the same one from last month.

It's built around one rule: the screen should be the shortest part of the experience. There's no dashboard to maintain, no logbook to transcribe, no "curated profile of your nature observations." There's a walk, a thirty-second voice memo, and a question you can answer a month later.

On the trail, you just talk to your phone like you're telling a friend what you saw. At home, one command:

$ npm run log-voice -- ~/walk.m4a
transcribing walk.m4a with ElevenLabs...
transcript (scribe_v2, eng):
  "Saw a white-breasted kingfisher at the lake jetty. It dove twice and got a fish.
   Also spotted a rain lily on the path side, fresh after last night's rain.
   Walked the Central Park loop, three point two kilometers in fifty minutes. Fog on the lake."
logged walk #1
a walk on Central Park loop, 3.2 km, 50 minutes, fog on the lake. Walked on 2026-10-08.
logged sighting #1
bird white-breasted kingfisher, at lake jetty, dove twice and got a fish. Spotted on 2026-10-08.
logged sighting #2
plant rain lily, at path side, fresh after last night's rain. Spotted on 2026-10-08.

No typing, no forms. The memo became a walk, two sightings linked to that walk, and three searchable journal entries — and the spoken "three point two kilometers" became a real number.

Then the journal answers questions about itself, from the same local model:

$ WANDERLOG_OLLAMA_MODEL=gemma3:4b npm run demo

  "where did I see the kingfisher last time?"

  1. [2026-10-03] sighting #10 — white-breasted kingfisher at Maota Lake, Amber
     score=0.465 semantic=0.500 keyword=0.186

  Answer from local gemma3:4b:

  According to entry [1] (2026-10-03), the white-breasted kingfisher was last
  sighted at Maota Lake, Amber. The note specifically states "bird
  white-breasted kingfisher, at Maota Lake, Amber".

It doesn't search for the word "kingfisher" — it searches for what the entry means. "Where did I see it last time" and "bird with the blue flash near the lake at golden hour" both land on the same entries, because the journal is understood by the same open-weight model that understands you. And the answer above was written by a 4B model on the same laptop: it cited the entry number, parsed the date, and got the place right.

Demo

The full loop on a real walk — memo recorded on the trail, logged at home, question answered — is being field-tested on Friday, October 9. The video and an honest field report will land right here after the walk:

Everything in the terminal sessions above is real output from the actual project, not mock-ups: the voice run is a real transcription of a real audio file, and the search output comes from the seeded journal.

Code

praneshnikhar / wanderlog

WanderLog

A local-first field journal for people who spend time outside.

WanderLog is a Model Context Protocol (MCP) server that turns your coding agent into a naturalist's notebook. Log the birds, plants, and trails you see on a walk; later ask in plain language "where did I see the kingfisher last time?" — and get an answer computed entirely on your machine.

Open-source AI at the core. Semantic search runs on an open-weight sentence-transformer (Xenova/all-MiniLM-L6-v2, Apache-2.0) executing in-process via Transformers.js and ONNX Runtime. Everything that understands your journal — Q&A and voice-note parsing — runs on Gemma (gemma3:4b) through Ollama, on your machine. No API keys, no cloud.
No internet required. After the first run, the embedding model is cached and every query is answered with zero network calls. Your sightings, notes and locations never leave the SQLite file on your disk.
Voice-first. A…

View on GitHub

MIT licensed, one npm test away from reproducible: a hermetic smoke test drives every tool over real MCP stdio, plus unit tests for the voice pipeline that stub both the ElevenLabs and Ollama calls.

How I Built It

flowchart LR
    subgraph trail [On the trail]
        A[Voice memo<br/>no typing]
    end
    subgraph home [At home, on-device]
        B[Transcribe<br/>ElevenLabs Scribe · optional]
        C[Parse<br/>gemma3:4b via Ollama]
        D[(SQLite journal<br/>sightings · walks · vectors)]
        E[Semantic search + answers<br/>MiniLM embeddings · gemma3:4b]
    end
    A --> B --> C --> D --> E
    A -.->|--transcript: no network at all| C

Storage — one SQLite file (~/.wanderlog/journal.db): sightings, walks, and a small embeddings table that stores each entry's vector as a blob. At field-journal scale (hundreds to low thousands of entries) a vector database would be ceremony, not engineering — cosine similarity over the table runs in milliseconds.
Embeddings — @huggingface/transformers loads an open-weight ONNX sentence-transformer (all-MiniLM-L6-v2, Apache-2.0) and runs it in-process with ONNX Runtime. First run downloads ~23 MB once; after that, every query is answered with zero network calls. If the model can't load, search degrades gracefully to keyword overlap — the journal still works at the edge of the trail.
Voice — the new piece. A memo is transcribed (ElevenLabs Scribe by default, optional), then a local open-weight model parses the transcript into JSON — walk, sightings, places, notes — validated against a zod schema. If the model invents a category the schema doesn't know, the entry is kept and bucketed as other rather than dropped. Pass --transcript and the entire pipeline runs offline; no bytes leave the machine. One honest wrinkle: Scribe runs zero-retention by default (enable_logging=false), which is an enterprise feature on ElevenLabs' side — on smaller plans the CLI says so up front and offers WANDERLOG_STT_LOGGING=1 (explicit retention) or the fully local path instead of silently downgrading your privacy.
Q&A — answer_question retrieves the top evidence locally, then asks your local Ollama model (I tested llama3.2:3b and Google's open-weight gemma3:4b) to answer strictly from those entries, citing entry numbers. No Ollama? It returns the ranked evidence, which for a field journal is usually answer enough.
Ranking — hybrid score: embedding similarity (75%) merged with keyword overlap (25%), with a freshness tiebreak so a "when did I last see X" question prefers the recent entry over an equally-relevant older one.
Tracing — every journal operation is instrumented with Sentry's gen_ai semantic attributes: tool calls are gen_ai.execute_tool spans, transcription is gen_ai.transcription, parsing and Q&A are gen_ai.chat with token counts, and search and embeddings are spans too. Set SENTRY_DSN and you can watch the agent think.

Measured on my MacBook (no GPU fan spin-up, no cloud): cold model load 244 ms, one embedding 3 ms, full semantic search over a 16-entry journal 9 ms. The only thing slower than that is me, on the trail.

Why Does Open Innovation Matter?

The closed version of this product would be an app with a cloud account. And the cloud version of a field journal is exactly wrong, for four reasons:

Location data stays private. Every sighting has a place attached — sometimes precise coordinates. eBird and iNaturalist are amazing, but they ask me to send every observation (and where I was standing) to their servers. WanderLog keeps the notebook in a file I own. Not a server I don't control — a file I can cat, back up, or delete with my own hands.
The model is swappable because it's open. WANDERLOG_EMBED_MODEL and WANDERLOG_OLLAMA_MODEL are environment variables. Don't like MiniLM? Point it at another open-weight embedder and the journal starts understanding you differently — no vendor change, no data migration, no "new API version." That's what open weights buy you: your data is interpreted by models you choose, not by a company's pricing page.
It costs nothing and runs anywhere. A laptop, a Raspberry Pi, a 2020 MacBook — the whole inference stack is ONNX Runtime plus a 23 MB model, and the optional Q&A and parsing layer runs on gemma3:4b, a 4B open-weight model that fits comfortably in RAM. There is no per-token bill, no rate limit, no "free tier."
You can change how the agent behaves. It's an MCP server; the journal-keeper prompt, the tools, and the scoring are all source in a repo you can fork. Fine-tuning your agent is editing the prompt — the whole behavior contract is inspectable.

The one cloud call in the whole system — transcription — is opt-in in both directions: you can use it, skip it (--transcript), or swap it, and everything downstream of the transcript is open weights on your disk. The open approach won precisely where it matters: everywhere the network ends. The trail is the last place on earth that has birds but no bandwidth, and WanderLog was designed for exactly that boundary — the model is already on the disk, the data is already on the disk, and the two of them never need to meet a server.

The tools

Tool	What it does
`log_sighting`	Record a species, category, place, weather, field notes
`log_walk`	Record an outing: trail, distance, duration, notes
`log_voice_note`	Voice memo (or raw transcript) → transcription + structured entries
`search_journal`	Hybrid semantic + keyword search, computed on-device
`answer_question`	Local-Gemma answer with citations; evidence fallback
`journal_overview`	Totals, category counts, last outing

Plus MCP resources (journal://stats, journal://day/{date}, journal://category/{category}, journal://walk/{id}), so any client can browse the notebook like files.

My Agent Session

The build — including verifying the voice pipeline with a real memo and catching the zero-retention tier limit the hard way — is saved on DEV as an agent session:

WanderLog: verifying the voice pipeline end-to-end and catching a zero-retention 403

You

My Mac lagged and I had to force restart — I think you were in the middle of verifying the voice extension?

Agent

Picking up where we left off: re-running the typecheck and the full test suite (voice unit tests + MCP smoke test), then the real end-to-end run with gemma3:4b.

▸ bash npm run typecheck && npm test

Input

$ npm run typecheck && npm test

Output

tsc --noEmit clean. Voice tests passed (JSON parse fallback, zero-retention multipart to ElevenLabs, transcript structuring into walk + sightings). Smoke test: 15 checks passed, including log_voice_note over real MCP stdio.

Agent

All green. Next: the on-device path through scripts/log-voice.ts with gemma3:4b, writing to a temp DB so the real journal is untouched.

▸ bash WANDERLOG_DB=/tmp/wanderlog-e2e.db WANDERLOG_OLLAMA_MODEL=gemma3:4b npm run l...

Input

$ WANDERLOG_DB=/tmp/wanderlog-e2e.db WANDERLOG_OLLAMA_MODEL=gemma3:4b npm run log-voice -- --transcript "saw a white-breasted kingfisher at the lake jetty, it dove twice and got a fish. also a rain lily on the path side. walked the central park loop, 3.2 kilometers in 50 minutes, fog on the lake."

Output

logged walk #1 — a walk on central park loop, 3.2 km, 50 minutes, fog on the lake. logged sighting #1 — bird white-breasted kingfisher, at lake jetty, dove twice and got a fish. logged sighting #2 — plant rain lily, at path side. (parsed on-device with gemma3:4b)

You

Here's an ElevenLabs API key so you can test a real voice memo. (Key omitted from this transcript for security.)

Agent

Generating a real voice memo with macOS text-to-speech, then running the full audio → transcript → structured entries pipeline.

▸ bash say -v Samantha -o /tmp/memo.aiff "saw a white-breasted kingfisher at the lak...

Input

$ say -v Samantha -o /tmp/memo.aiff "saw a white-breasted kingfisher at the lake jetty... walked the central park loop, 3.2 kilometers in 50 minutes" && afconvert -f m4af -d aac /tmp/memo.aiff /tmp/memo.m4a && ELEVENLABS_API_KEY=*** WANDERLOG_OLLAMA_MODEL=gemma3:4b npm run log-voice -- /tmp/memo.m4a

Output

transcribing /tmp/memo.m4a with ElevenLabs...
log-voice failed: ElevenLabs transcription failed: HTTP 403 {"detail":{"type":"authorization_error","code":"forbidden","message":"Only users from the enterprise or trial tier can use ZRM mode.","status":"not_allowed"}}

Agent

That's a real finding, not a fluke: the code asks for zero-retention (enable_logging=false) by default, and ElevenLabs gates that to enterprise/trial plans. Confirming the rest of the pipeline works when logging is explicitly allowed, and that the user is told the tradeoff instead of it happening silently:

▸ bash ELEVENLABS_API_KEY=*** WANDERLOG_STT_LOGGING=1 WANDERLOG_OLLAMA_MODEL=gemma3:...

Input

$ ELEVENLABS_API_KEY=*** WANDERLOG_STT_LOGGING=1 WANDERLOG_OLLAMA_MODEL=gemma3:4b npm run log-voice -- /tmp/memo.m4a

Output

transcript (scribe_v2, eng): "Saw a white-breasted kingfisher at the lake jetty. It dove twice and got a fish. Also spotted a rain lily on the path side. Fresh after last night's rain, walked the Central Park loop. Three point two kilometers in fifty minutes. Fog on the lake"
logged walk #1 + 2 sightings (bird + plant), linked to the walk. (parsed on-device with gemma3:4b)

Agent

Now fixing the failure mode: a 403 from the zero-retention gate must become an actionable error — never a raw HTTP dump, and never a silent downgrade of the privacy default.

▸ edit src/voice.ts — if !keepLogging && res.status === 403 && /ZRM|zero[- ]retentio...

Input

src/voice.ts — if !keepLogging && res.status === 403 && /ZRM|zero[- ]retention/i.test(detail): throw new Error("ElevenLabs plan does not support zero-retention mode — set WANDERLOG_STT_LOGGING=1 to let ElevenLabs keep the audio for this transcription, or pass an existing transcript instead.")

Output

Edit applied.

Agent

Adding a unit test that simulates the ZRM 403 and asserts the helpful message.

▸ edit test/voice.test.ts — add zrmDenied mock returning 403 with the enterprise-tie...

Input

test/voice.test.ts — add zrmDenied mock returning 403 with the enterprise-tier message; assert.rejects(transcribeAudio(audioPath), /WANDERLOG_STT_LOGGING=1/)

Output

Edit applied.

Agent

Re-running everything, plus a live check against the real API to see exactly what a user now gets.

▸ bash npm run typecheck && npm test && (live run without WANDERLOG_STT_LOGGING)

Input

$ npm run typecheck && npm test && (live run without WANDERLOG_STT_LOGGING)

Output

typecheck clean. Voice tests: 5 sections, incl. "transcribeAudio explains the zero-retention plan limit instead of dumping HTTP 403". Smoke: 15 checks. Live run: "log-voice failed: ElevenLabs plan does not support zero-retention mode — set WANDERLOG_STT_LOGGING=1 to let ElevenLabs keep the audio for this transcription, or pass an existing transcript instead."

You

Commit it, and don't worry about rotating the key.

Agent

▸ bash git add -A && git commit -m "add voice-note pipeline: ElevenLabs transcriptio...

Input

$ git add -A && git commit -m "add voice-note pipeline: ElevenLabs transcription, on-device gemma3 parsing, Sentry tracing" && git push

Output

[main 9cd5580] add voice-note pipeline: ElevenLabs transcription, on-device gemma3 parsing, Sentry tracing — 14 files changed, 1618 insertions(+), 156 deletions(-). fec0cbc..9cd5580 main -> main

You

Pasted the DEV submission template for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

Agent

Pulled the challenge rules, confirmed the project's first commit (Oct 6) is inside the challenge window, then restructured the existing DEV draft to the template: voice-first story, gen_ai tracing, honest zero-retention wrinkle, and the three prize categories it genuinely qualifies for.

▸ get_challenges Hacktoberfest Week 1 — Touch Grass

Input

Hacktoberfest Week 1 — Touch Grass

Output

Submissions due Oct 11, 11:59 PM PDT. Judged on: writing quality (heaviest), relevance to theme, creativity, technical execution, optional partner use. Required tag #hf26challenge. Featured: Best Use of Gemma. Partner: ElevenLabs, Sentry Agent Tracing, and others.

▸ update_article article 4804421 — full restructure to the submission template with the voice-...

Input

article 4804421 — full restructure to the submission template with the voice-memo flow, Sentry tracing section, prize categories, and field-test TODOs

Output

Draft updated on DEV.

Prize Categories

WanderLog genuinely uses three of this week's partner technologies, so I'm entering all three:

Best Use of Gemma — gemma3:4b via Ollama is the intelligence of the project: it parses spoken notes into structured field entries and answers journal questions with citations, strictly from retrieved evidence. It runs on the same laptop that holds the journal.
Best Use of ElevenLabs — Scribe is the transcription leg of the voice flow, and the only cloud step. Zero-retention by default, optional by design (--transcript skips it entirely), and honest when the plan can't honor zero-retention instead of quietly logging your audio.
Best Use of Sentry Agent Tracing — every operation the agent performs emits gen_ai.* traces to Sentry when SENTRY_DSN is set: tool calls, transcription, chat with token counts, embeddings, and search. It's how I watched a 4B model on a laptop behave like an agent.

What's next

I'm taking WanderLog to Central Park, Jaipur this week for a real field test — logging actual sightings from a voice memo, and asking the journal questions at the end. This post will be updated with the field report and the video.

Built in three days, entirely inside the Hacktoberfest Week 1 window, MIT licensed, with a hermetic test suite that exercises every tool over real MCP stdio.

Open source made this project possible — the model is open, the runtime is open, and the notebook is yours. Go outside. Take notes. Ask it questions later.

Built for Hacktoberfest 2026 Open-Source AI Challenge: Week 1 — Touch Grass. Built on open-source AI: Transformers.js + open-weight embeddings, Gemma 3 via Ollama, MCP, SQLite — all open, all local, all yours.

I built a voice language tutor that lives on my friend's laptop

Pranesh Nikhar — Sat, 03 Oct 2026 21:11:51 +0000

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

What I Built

A friend of mine is learning Spanish. They're not bad at it — they're scared of it. Practicing with a real person means being wrong out loud, in front of another human, and that freezes them. Language apps feel like flashcards with a timer, not a conversation. And a tutor costs money they don't have.

So I built Habla Conmigo — a patient voice tutor that lives on their own laptop. You talk to it like a person: tap the mic, say whatever you want in Spanish (or half-Spanish, half-English, or completely stuck English), and it replies out loud, gently correcting mistakes and keeping the conversation going.

It solves the exact problem my friend had: a practice partner with zero judgment, infinite patience, and a memory that follows the conversation across turns.

Demo

Live (deployed, UI + API — the model itself runs locally, by design): habla-conmigo.onrender.com

Code

github.com/praneshnikhar/hacktoberfest

How I Built It

Three layers, one conversation loop:

Browser mic → ffmpeg — the frontend records a webm blob; the server converts it to mp3 with ffmpeg.
ElevenLabs Scribe (STT) — transcribes the audio, auto-detecting language so a stuck student can fall back to English mid-sentence.
Open-weight model via Ollama (the tutor brain) — the reply comes from a model running locally on the laptop (Llama 3.2 / Gemma 3), with a system prompt that makes it a tutor: reply in the target language, keep it to 1–3 sentences, correct one mistake at a time, always end with a follow-up question.
ElevenLabs TTS — speaks the reply back in a warm multilingual voice.

Conversation memory (last 8 turns) lives in the server, so the tutor follows topics across turns instead of starting fresh every sentence.

The whole thing is ~700 lines of plain Node.js + Express + vanilla JS. No framework, no database, no cloud AI.

Why Does Open Innovation Matter?

This is the part I care about most, because the open pieces are why the app exists at all:

A nervous learner's words never leave their machine. The core of this app — the part that understands and replies — is an open-weight model running locally. A closed API would ship every halting, half-grammatical sentence of a shy person to a third-party server, and bill per message. Here it's free and private, and it even works offline.
No lock-in, swap any model in one line. Because the brain is Ollama, changing the teacher is a one-line .env change: Llama → Gemma → Qwen → whatever ships next. Try doing that with a closed model. This also means the tutor can be fine-tuned later for my friend's specific mistakes.
Open where it matters, closed only where it adds value. The one closed service (ElevenLabs) does one narrow thing — voice — and even that degrades gracefully: remove the API key and the app still works as a text tutor. The product doesn't collapse when the proprietary part is taken away.
It costs nothing to run. The model is free, the runtime is free, the voice tier has a free plan. "Practicing a language" shouldn't have a subscription.

The counterfactual is what convinced me: with a closed model, I would have needed a paid API, an account per user, a data policy, and a conversation my friend couldn't afford to have.

My Agent Session

Built end-to-end with the opencode agent harness (open-source CLI coding agent) driving the implementation, debugging, and this write-up.

Prize Categories

Best Use of ElevenLabs — an open-source agent given a voice: Scribe STT + multilingual TTS power the full conversational loop
Best Use of Render — deployed via the included render.yaml blueprint

Tags: #devchallenge #weekendchallenge #hf26challenge