DEV Community: Jeffrey Turov

Memoria: Keeping Family Voices Alive with Local Whisper + Gemma

Jeffrey Turov — Tue, 27 Oct 2026 08:17:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

Memoria is a local oral-history archivist. You give it a family voice memo. It returns a structured keepsake containing:

the complete transcript with timestamps;
the people, places, and time references explicitly mentioned;
themes and a short summary;
verbatim quotes checked against the transcript;
three thoughtful questions to ask during the next conversation.

The result is exported as JSON and Markdown. There is also a small web interface with a playable demo recording.

I built it for the Ghost in the Machine theme as a way to honor the past without surrendering it to a cloud service. A recording of a grandparent is not ordinary prompt data. It can contain names, addresses, health details, and stories that a family never intended to publish.

Memoria runs both speech recognition and language understanding locally. The recording and transcript never leave the machine for inference.

Demo

Open the live Memoria demo

Press “Archive this memory” to run the complete pipeline on local CPU models. Please allow about a minute.

The bundled 58-second story is synthetic and fictional, narrated with TTS specifically so that no private family recording is exposed. The processing is not mocked: the button runs Whisper and Gemma against that audio. The demo tunnel is temporary; the repository contains everything needed to run it locally.

Code

github.com/jeffreyturov-dev/memoria-local

The repository includes the CLI, FastAPI demo, synthetic demo audio, generated example output, tests, and setup instructions.

How I Built It

The pipeline is deliberately small and inspectable:

voice memo
    │
    ▼
faster-whisper / Whisper small (CPU int8)
    │  transcript + segment timestamps
    ▼
Gemma 3 4B IT QAT through llama.cpp
    │  strict JSON memory card
    ▼
deterministic quote validation
    │
    ├── JSON archive
    ├── Markdown keepsake
    └── local web result

Whisper handles the voice. Gemma receives only the resulting transcript and must produce eight fields: title, summary, people, places, time references, themes, quotes, and follow-up questions. Temperature is zero, missing evidence becomes an empty array, and the prompt explicitly forbids adding facts.

A small model can still produce a quotation that sounds plausible but does not occur in the recording. For an archive, that is unacceptable. I therefore added a deterministic guard after generation:

def verify_quotes(card, transcript):
    normalized_transcript = normalize_words(transcript)
    verified = []
    for quote in card["quotes"]:
        if isinstance(quote, str) and normalize_words(quote) in normalized_transcript:
            verified.append(quote.strip())
    return verified

Only whitespace and letter case are normalized. If the passage is absent, Memoria drops it rather than presenting it as the speaker's words. The original transcript always remains beside the generated card, so a family can review the source rather than trusting the summary blindly.

The demo uses FastAPI, a concurrency lock, and a 25 MB limit for local audio uploads. No API key or account is required.

The Moment It Landed

The fictional demo story describes a grandfather's radio repair shop, yellow marigolds, cinnamon tea, and a rebuilt red bicycle called La Valiente. Memoria recovered those details and preserved this passage verbatim:

A broken thing is only a story waiting for patient hands.

It then suggested questions such as asking what the radios sounded like and why the bicycle had that name. That was the moment the project stopped feeling like a transcription wrapper: the useful output is not just what was said, but a gentle prompt to record the next chapter while you still can.

The recording is synthetic, and I have kept that distinction visible in the demo and repository. A real family archive should start with consent and human review, not an invented claim of authenticity.

Verified Results

I ran the project rather than stopping at a screenshot or a plausible demo response:

Check	Actual result
Unit tests	6/6 passed
Demo audio duration	57.79 seconds
Full CLI run, audio → archive	33.36 seconds
Public web run through the tunnel	29.47 seconds
Whisper language detection	English, 0.9993 probability
Displayed quotes	3/3 found in the transcript

For the offline-mode run, I forced HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY to a dead localhost address, with only localhost excluded. The complete cached-model pipeline still produced the transcript and memory card. The generated example is committed under demo/output/ for inspection.

The unit tests cover fenced JSON parsing, missing-field rejection, hallucinated-quote rejection, whitespace normalization, human-readable people fields, and preservation of the original transcript.

Why Open Innovation Matters

Open weights and open-source inference are not decorative details here; they make the product possible.

Privacy: a closed transcription or LLM API would send intimate family material to infrastructure the family does not control. Memoria performs both stages locally.

Longevity: an oral-history archive should not become inaccessible because a vendor retired a model endpoint. The code is MIT-licensed, the archive is plain JSON and Markdown, and the inference components can be replaced.

Offline use: after the models are downloaded, the pipeline works without cloud AI access. That makes it usable in the places where families actually sit down together, not only where connectivity and a subscription are available.

Zero marginal inference bill: there is no per-minute or per-token charge for a longer conversation. The trade-off is CPU latency and the need to review a small model's work.

Limitations

Memoria does not independently fact-check a summary, and a high language-detection score does not guarantee a perfect transcript. Names can be misheard; in the demo, the source script says “Mateo” while Whisper transcribes “Matteo,” and the card faithfully follows that transcript. This is exactly why the source text and human review remain essential. Only record and archive someone else's story with their consent.

Prize Categories

Best Use of Gemma: Gemma 3 4B IT QAT performs the local structured memory extraction through llama.cpp.
Overall: a complete, tested, locally runnable oral-history tool with a real public demo.

Slow and Steady: An Agent That Runs My Apify Side Business While I Sleep

Jeffrey Turov — Sat, 24 Oct 2026 08:12:57 +0000

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

What I Built

I run 13 public web-scraping Actors on the Apify Store as a side business. Keeping up with the platform — blog announcements, Store trends, pricing-compliance deadlines, new monetization features — is exactly the kind of chore I kept putting off. So I built Phoenix: an autonomous agent on a cron schedule that does the whole daily platform watch for me and delivers an 8-line report while I'm still asleep.

Every morning, on its own, it:

scans the Apify blog RSS for anything published in the last 48 hours
pulls the Apify Store top-10 to spot demand trends
audits my Actors' pricing configuration (pay-per-event migration compliance)
checks my saved tasks against the Store's newest SEO surface, published task examples
executes whatever is deliverable end-to-end — not just reading, but doing: configs, fixes, submissions — then logs done-vs-read in a dated markdown file
watches dev.to challenges with cash prizes and drafts submissions (yes, the research for this very post was done that way)

The sloth philosophy, applied: conserve energy, let the machine do the rounds.

Demo

Real, unedited output from this morning's run (October 24, 2026):

Blog scan: Apify shipped bulk task-example publishing via API on Oct 22 — their case study claims organic traffic to an Actor page doubled after publishing examples.
Audit: I have 11 saved tasks across my Actors and zero published task examples. Gap identified, publish payloads prepared.
Action attempted: the agent tried the publish API call… and got 403 platform-feature-disabled. Instead of silently failing, it traced the cause: my account had burned through its $5 monthly hard limit — 0.58 GB of residential proxy (~$4.60) consumed by one overeager scraper run. It flagged it for my review, with the numbers.

I learned about a new Store SEO feature and a billing problem before my first coffee, with zero clicks.

Code

The harness is Hermes Agent — an open-source agent runtime by Nous Research (docs). The daily watch is a cron job that hands the agent a task file; the agent loops: scan → reason → act → log. The platform knowledge lives in plain-markdown "skill" files, and the actual checks are small scripts the agent writes and runs itself, like this abridged one from today:

import json, urllib.request

def getj(url):
    req = urllib.request.Request(url, headers={"User-Agent": "phoenix-cron"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

# Which of my Actors are still PPE-compliant?
acts = getj(f"https://api.apify.com/v2/acts?my=1&token={TOKEN}&limit=50")
for it in acts["data"]["items"]:
    det = getj(f"https://api.apify.com/v2/acts/{it['id']}?token={TOKEN}")["data"]
    if det.get("isPublic"):
        print(det["name"], "->", (det.get("pricingInfos") or [{}])[0].get("pricingModel"))

No framework lock-in: the harness calls shell, Python, and a real browser over CDP. That's the whole stack.

How I Built It

Orchestration: Hermes Agent, open-source. The agent reads its instructions, picks tools, writes its own helper scripts, and iterates until the task verifies — a real agent loop, not a Zapier-style flow.
Scheduling: a boring, glorious cron line. Slow and steady, every day at the same hour.
Knowledge: markdown skill files (actor doctrine, preflight checks, the publishing API contract). When Apify changed task-example limits from 50 to 10 per Actor, I edited a text file — not a support ticket.
Model-agnostic: the harness doesn't care which LLM drives it. You can point the same setup at an open-weight model and the loop still works; the automation survives the swap.

Why Does Open Innovation Matter?

Three concrete things a closed automation platform wouldn't give me:

My credentials never leave my machine. The agent touches Gmail, Apify, and Stripe tokens daily. They live in local files on my own server in Luxembourg — not in a vendor's cloud, not in someone's "workspace".
Everything is inspectable and forkable. Skills are text. Scripts are text. Logs are text. When something breaks at 6 AM, I can diff it, fix it, and the fix is permanent — not a black-box retry policy I can't see.
No platform risk on the orchestration layer. Closed assistants lock you into their model, their pricing, their roadmap. An open harness means my morning routine keeps working even if I switch models tomorrow. Open weights crossing the quality bar is a when, not an if — and I'm already wired for it.

The Lazy Payoff

About 45 minutes of daily platform-watch compressed into reading 8 lines. This week alone the agent prepared task-example configs for the Store's new SEO surface, verified pay-per-event pricing on all 13 public Actors ahead of the migration deadline, and caught a hard-limit billing issue — all while I did literally nothing.

Sloths had it figured out. Build the thing once, let it do the rounds forever.

Sloth Digest 🦥 — a local Gemma 3 agent that does my inbox triage so I don't have to

Jeffrey Turov — Tue, 20 Oct 2026 08:10:45 +0000

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

What I Built

Sloth Digest is a local AI agent that reads my unread Gmail overnight and hands me a morning digest, so I never have to open a cold inbox again.

Every email gets triaged by an open-weight model running entirely on my own machine (Gemma 3 4B IT, QAT-quantized, served by llama.cpp on plain CPU) into three buckets:

⚡ Needs you — reply, pay, confirm, decide — each with a suggested one-line action
👀 Worth 10 seconds — FYI, no action needed
😴 Skip safely — promos, newsletters, notification noise

Who gets to be lazier? Me, every single morning. Instead of 15–30 minutes of scanning subject lines and context-switching, I read one short markdown page and only touch the 3–4 emails that actually need a human.

Here's real output from the bundled sample inbox:

# 🦥 Sloth Digest — morning triage

## ⚡ Needs you (4)
- **Energia Lux** — Your October invoice — €84.12 due Oct 27
  Electricity bill of €84.12 is due soon.
  → Pay the invoice before October 27th.
- **Marco Silva** — Re: Thursday moved to 15:00?
  Plumber availability needs confirmation for Thursday.
  → Confirm 15:00 or propose an alternative time.
...

## 😴 Skip safely (1)
- **ShopMega** — 🔥 70% OFF ends tonight — don't miss out!
  Promotional email about a limited-time sale.

6 emails triaged locally in 14s (~12 min of manual triage saved).
Nothing left this machine.

Demo

Live demo: https://vid-exploring-omissions-warren.trycloudflare.com

It shows the sample inbox (6 fake emails — bills, a friend asking for a confirmation, a flash sale, a delivery notice, a medical appointment reminder) and runs the triage live on the local Gemma model when you hit the button. ~14 seconds on CPU, no cloud API involved anywhere.

You can reproduce the whole thing offline:

./llama-server -m gemma-3-4b-it-qat-Q4_0.gguf --port 8801
python sloth_digest.py --demo   # sample inbox, zero credentials needed

Code

jeffreyturov-dev / sloth-digest

Local AI agent that triages your Gmail overnight into a morning digest — Gemma 3 4B, 100% offline, privacy-first

🦥 Sloth Digest

A local AI agent that reads your unread Gmail overnight and hands you a morning digest — so you don't have to.

Every email is triaged into three buckets by an open-weight model running entirely on your own machine (Gemma 3 4B IT QAT via llama.cpp):

⚡ Needs you — reply, pay, confirm, decide (with a suggested action)
👀 Worth 10 seconds — FYI, no action
😴 Skip safely — promos, newsletters, notification noise

No email content ever leaves your computer. Works offline. Costs nothing per run — set it up once and forget it.

Why local?

Your inbox is the most private dataset you own. A closed API means sending every message — invoices, medical appointments, personal threads — to someone else's servers. Sloth Digest runs the whole pipeline against a local OpenAI-compatible endpoint, so the "open" piece is the product:

Privacy: nothing leaves the…

View on GitHub

The agent is ~200 lines of Python stdlib. The only dependencies are llama.cpp (for inference) and, for the optional web UI, FastAPI.

How I Built It

The architecture is deliberately boring — a sloth would approve:

unread Gmail ──► fetch (Gmail API, strictly read-only)
                   │
                   ▼
        ┌─────────────────────┐
        │ Gemma 3 4B IT (QAT) │  per email: CATEGORY / SUMMARY / ACTION
        │ llama.cpp, CPU      │  strict 3-line verdict, temperature 0
        └─────────────────────┘
                   │
                   ▼
        morning digest (markdown, grouped by urgency)

Three design choices make a small 4B model reliable enough to trust with triage:

Rigid output contract. The model must answer with exactly three lines (CATEGORY / SUMMARY / ACTION) at temperature 0. No essays, no JSON to break.
Graceful degradation. Anything unparseable lands in "check manually" instead of being silently misfiled. A triage tool that hides emails is worse than no tool.
Read-only by construction. The agent fetches unread mail and prints a digest. It never marks, archives, or deletes anything — the worst it can do is be wrong on a page you skim anyway.

Local inference is not a gimmick here, it's the point: the whole pipeline — fetch, classify, summarize — runs against llama.cpp's OpenAI-compatible endpoint on 127.0.0.1. Pull the network cable and it still works.

Why Does Open Innovation Matter?

Your inbox is probably the most private dataset you own: invoices, medical appointments, family threads, business negotiations. Triage means reading all of it — and with a closed API, "reading" means shipping every message to someone else's servers, on someone else's terms, under a privacy policy that can change.

Because Gemma's weights are open and llama.cpp is open source, the equation flips:

Privacy by architecture, not by promise. Nothing leaves the machine, so there's nothing to leak, log, or train on.
Works offline. Plane, cabin, outage — the digest still runs.
Free forever. No per-token bill. I set it up once and it costs me exactly zero per run, forever. That's the sloth economics a closed API can never offer.

The Lazy Payoff

I ran it on my real unread inbox this morning: 8 emails triaged in ~20 seconds, and the digest correctly separated two things I genuinely needed to act on from the newsletter noise. Manual triage averages ~2 minutes per email once you include the context-switching — so the agent saves me roughly 15 minutes a day, ~90 hours a year, for a one-time setup cost and €0 in API fees.

The cron job runs at 7am. I wake up, read one page, and go back to being lazy. The sloth wins. 🦥

Prize Categories

Best Use of Gemma — Gemma 3 4B IT (QAT) is the entire brain of the agent, running locally via llama.cpp.

I Let an AI Agent Run Parts of My Real Businesses for a Year. Here Are the Receipts.

Jeffrey Turov — Mon, 19 Oct 2026 21:02:13 +0000

One year ago, I opened a terminal on a small home server and gave an AI agent its first real task.

I'm not a developer. I run a small hotel in Mersch, Luxembourg. I had no team, no budget for an agency, and a long list of things that needed to exist: a booking site, a phone receptionist, payments, a second company, SEO, ads.

Today, that agent — the same one, still living in the same terminal — runs a real slice of my entrepreneur life. Not demos. Not chat screenshots. Production systems, with real customers and real money.

This is episode 1 of an 8-part series. Everything I claim here is publicly verifiable, and I've linked the receipts.

What "running a business with an AI agent" actually means

Forget the viral stories about AIs asking for donations. Here's the boring, real version:

It answers my hotel's phone. A voice AI receptionist picks up real calls, checks availability, quotes our direct rate (10% below the OTAs), and takes bookings. Guests talk to it daily. It announces call recording, because compliance isn't optional.

It filed my second company. Statutes, government forms, notary coordination, registry filing. The ministerial authorization for my new company (a SARL-S, the Luxembourg equivalent of an LLC) arrived this month. The AI drafted; I signed. That division of labor matters, and I'll come back to it.

It published an MCP server on the official registry. Any AI agent in the world can now discover my hotel federation and book real rooms with 0% OTA commission — versus the 15-25% the platforms take. It's live on Smithery and Glama too.

It runs the money plumbing. Stripe Connect charges, platform fees, payouts, a revenue dashboard with real processing fees computed per merchant. Manual payouts — because I keep a human hand on money movements. On purpose.

It watches itself. Dozens of cron jobs, watchdogs, and health checks. When Booking.com started captcha-ing my server's IP mid-October, the monitoring caught it and the agent rebuilt the pipeline through a different path within a day.

The receipts

My hotel's live booking site: yashahotel.com (Stripe Connect in production)
My company's site: adagasolutions.lu
The MCP server: smithery.ai/servers/@jeffreyturov/adaga-network — also on the official MCP registry
The technical write-up of the MCP build: my previous article here on dev.to
My hotel company exists in the Luxembourg trade register since 2005 — the AI part is what happened in the last 12 months

What the agent does alone vs. what I validate

This is the part most "AI entrepreneur" stories skip, so let me be precise:

The agent does, end-to-end and without asking: research, code, deployment to my sandbox, testing, monitoring, documentation, drafting emails, answering comments on my articles, scraping, data pipelines.

I validate, always: external communications to institutions, anything touching money movements, client-facing promises, legal signatures, and publishing on my personal accounts.

That boundary isn't a limitation of the AI. It's a governance choice, and it's exactly why this still works after a year: the agent is fast, and I am the brakes.

The failures are the best part

I'll dedicate a full episode to this, because it's where the real learning is: the agent once reverted my production site by deploying from an outdated copy. Google revoked my Gmail tokens because of a password reset and killed half my integrations. Booking.com banned my server IP. A cron job nearly got me disqualified from a dev challenge by double-submitting.

Every single one of those failures is now a documented procedure the agent will never repeat. That — not the model, not the prompts — is the actual moat.

The series

Ep.2 — The AI receptionist (with audio)
Ep.3 — The AI that filed my company (with the documents)
Ep.4 — Strangers' AI agents booking my rooms (the MCP deep-dive)
Ep.5 — Everything that broke (the viral one, probably)
Ep.6 — The money: honest ranges
Ep.7 — The machine: 1 human, ~100 learned procedures, 0 employees
Ep.8 — One-year review + the book

I'm writing this for two kinds of people: developers who want to see what a year of agentic operations actually looks like under the hood, and small business owners who suspect they can't afford an agency — you're right, and there's another way now.

Which episode do you want first? Tell me in the comments — I'll adjust the order.

I built an MCP server that lets AI agents book real hotel rooms (no OTA commission)

Jeffrey Turov — Fri, 16 Oct 2026 15:26:46 +0000

Booking.com takes 15-25% commission and owns the customer relationship. I run a small
network of independent establishments in Luxembourg, and I wanted AI agents to be able to
book them directly — machine-native, at the establishment's exact direct price.

So I built Adaga Network — Direct Booking Federation: one MCP endpoint that fans out
to every establishment in the network.

The architecture

Each establishment runs the same open template: an mcp.js module mounted on /mcp inside its existing Express app. No new port, no new service — a pure proxy to the app's own REST API.
The federator (adagasolutions.lu/network/mcp) is a Streamable HTTP stateless MCP server that keeps a registry of tenants and calls their MCP tools in parallel (6s timeout per tenant, dead tenants are skipped and reported).

3 tools cover the whole journey:

Tool	What it does
`network_directory`	Lists every establishment (brand, type, city, slug)
`network_search`	Fan-out live availability + exact total prices, sorted
`network_book`	Creates a REAL booking, hands secure card payment to the human

The payment hand-off is a feature

The agent never touches card data. network_book returns payment instructions; the human
completes a Stripe Checkout; unpaid bookings expire automatically. Booking confirmed only
after payment — and a 409 if the room became unavailable in between.

What I learned writing tool descriptions

The tool description is the #1 selection criterion for agents. After running the tools
through a TDQS audit, the fixes that mattered:

State auth requirements, rate limits and pagination explicitly (mine: none, none, none)
Put the full workflow in the transactional tool's description
Describe every optional input format (phone: international format, extras: integer ids)
Units everywhere: prices in euro cents, dates YYYY-MM-DD, max 30 nights

Distribution

Official MCP Registry: io.github.jeffreyturov-dev/adaga-network
Glama connector with health checks (hourly) — a watchdog pings the endpoint every 10 min
The honest pitch: no OTA commission — the traveler pays the exact direct price, the establishment keeps its customer.

Salons and restaurants join the network next. If you run an independent establishment and
want AI agents to book you directly, the onboarding template takes 2-4 hours.

Live links

Network page for establishments: adagasolutions.lu/agents-ia
First federated hotel (live direct booking): yashahotel.com
The hotel's own agent page: yashahotel.com/agent

I built an offline review-reply concierge for my family's hotel — €0 per reply, five languages, no cloud

Jeffrey Turov — Tue, 13 Oct 2026 09:00:08 +0000

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

What I Built

review-concierge drafts thoughtful, multilingual replies to guest reviews — entirely offline, on the machine already sitting at the hotel's front desk, at a marginal cost of exactly €0 per reply.

Who pays for this? Small independent hotels. My family runs one: a 28-room hotel near Luxembourg City's train station, with 280+ Google reviews written in five languages (French, German, English, Dutch, Portuguese). Replying to reviews is one of the highest-ROI tasks in hospitality — and the closed-source answer to it, MARA, costs €70–100 per property per month. That's a real line item for a family business. The core of that job — a well-written, on-brand draft in the guest's own language — is something an open-weight model now does for free.

The side-hustle angle cuts both ways: it's a tool a small business would pay for, and it's only viable because open weights make the marginal cost zero.

Demo

🟢 Live demo (temporary tunnel up for the judging period): https://intersection-keno-blind-fixes.trycloudflare.com — paste a guest review in any language, watch the reply draft locally on plain CPU. Nothing you type leaves the machine it runs on.

Real run, real review (one of our actual 3★ Google reviews, mentioning a broken shower holder and mould in the bathroom):

$ python reply.py --file reviews_yasha_sample.csv --out replies_yasha.csv
[3/10] done (438 chars)

→ We're so sorry to hear about the issues you experienced with the bathroom
  and shower head, and thank you for pointing out the broken holder – we
  appreciate you finding a resourceful solution! We sincerely apologize that
  the air-conditioning wasn't working as advertised and for the inconvenience
  this caused. We're immediately addressing the mildew and mould, and
  replacing the shower head holder. Thank you for your feedback; we truly
  value it and hope to welcome you back for a much better experience.

  The Yasha Hotel team

Notice what it did: acknowledged the specific problems, thanked the guest instead of arguing, named a concrete fix — and did it in English, because the review was in English. The French reviews get French replies, the German ones German, the Dutch one Dutch. I verified all 10 drafts against 10 real reviews: 10/10 in the correct language, 10/10 specific, zero arguments with guests. The full input/output table is in the repo's README.

There's also a tiny web UI (app.py, ~70 lines) so a non-technical front-desk person can paste a review and get a draft in ~20 seconds — no terminal required.

Code

Code: codeberg.org/veysel-devia/review-concierge

The core is reply.py — ~120 lines, Python standard library only. It talks to a local llama.cpp server running Gemma 3 4B (QAT, Q4_0), Google's open-weight model, on a plain CPU (no GPU, ~12 tok/s, a full draft in ~20 s).

How I Built It

Two model calls per draft, both against the local OpenAI-compatible endpoint:

Language detection — the model itself classifies the review (temperature 0, ISO 639-1 out). No extra dependency, no langid/fasttext baggage.
Reply drafting — a system prompt that encodes a reputation-manager playbook: reply entirely in the detected language (hard constraint, restated in the user message), 40–80 words, acknowledge one specific detail, apologise without arguing, name a concrete fix for maintenance issues, never discuss the neighbourhood, sign as the hotel.

The one real bug I hit is instructive: my first version said "reply in the same language as the review" — and Gemma 4B, primed by the Luxembourg hotel context, answered roughly half the English reviews in French. The fix was making the constraint explicit and mechanical (detect first, then inject "the review is in English, reply in English"). Small-model prompting is engineering, not vibes.

Why Does Open Innovation Matter?

Three reasons, and they're the whole business case:

€0 marginal cost is the product. A review-reply SaaS charges per property per month because every reply costs them an API call. With open weights, the hundredth reply costs exactly as much as the first: nothing. That's what turns "nice AI demo" into "tool a 28-room hotel can actually afford."
Guest data never leaves the building. Reviews contain personal data — names, stay dates, occasionally health details in complaints. Under GDPR, piping them through a third-party API is a compliance conversation most small hoteliers don't want to have. Local inference means there is no conversation: the data stays on the machine, verified working with all egress blocked.
The voice is a text file, not a paywall. The hotel's tone, apology policy and signature live in a system prompt the owner can edit. With closed tools, that's an enterprise tier.

My First User

The first user is my family's hotel — which is also how I knew what to build. I ran the tool against 10 of its real, currently-unanswered Google reviews (the exact mix a small property faces: a glowing 5★ from a returning business traveller, a furious 1★ in French about a mattress, a 3★ in Dutch). The drafts it produced are good enough to post after a 30-second human read — which is the correct workflow anyway: the AI drafts, the human owns the reply. Would they pay for it? They already pay with something scarcer than money: the reviews were sitting unanswered because nobody at the front desk has time to craft careful replies in five languages. Now the time cost is a paste and a skim.

Prize Categories

Best Use of Gemma — the entire product runs on Gemma 3 4B, Google's open-weight model, served locally through llama.cpp. Open weights are not an implementation detail here; they're what makes the economics and the privacy story work.

I built a free AEO checker — is your website visible to ChatGPT, Perplexity and Google AI?

Jeffrey Turov — Sat, 10 Oct 2026 01:51:48 +0000

A restaurant owner in my town asked me a question I hear more and more: "When someone asks ChatGPT where to eat tonight, does it say my name?"

Honest answer: nobody knows without checking. So I built a free tool that checks — and I open-sourced the logic as an Apify Actor anyone (human or AI agent) can call.

The 7 things AI engines actually check

After auditing dozens of local business sites, the signal for "will an AI cite you" collapses to 7 technical criteria:

Structured data (JSON-LD) — machines read schema.org, not your hero banner
A business schema type — LocalBusiness, Organization, ProfessionalService…
A meta description — the first text an AI reads about you
One clear H1 — confirms the page's subject
Open Graph tags — sharing + entity understanding
A /llms.txt file — the identity card AI engines look for (most sites don't have one)
AI bots allowed in robots.txt — most sites accidentally block GPTBot, ClaudeBot or PerplexityBot via a blanket rule or a "SEO tool" that added it silently

The killer is #7. I've seen sites with perfect schema markup that explicitly tell every AI crawler to go away.

What the Actor returns

One call, one score, exact fixes:

{
  "url": "https://www.codeur.com",
  "scoreLabel": "4/7",
  "checks": {
    "json_ld": false, "schema_type": false, "meta_description": true,
    "h1": true, "open_graph": true, "llms_txt": false, "robots_ai": true
  },
  "topFixes": [
    {"criterion": "Structured data (JSON-LD)", "fix": "Add a <script type=\"application/ld+json\"> block..."},
    {"criterion": "llms.txt file", "fix": "Publish /llms.txt summarizing who you are for AI engines."}
  ]
}

(That's a real result — a major marketplace scores 4/7. Most local businesses score 1–2.)

It can also generate a ready-to-publish llms.txt draft for the audited site, delivered as plain text in the key-value store.

Call it from anything

curl -X POST "https://api.apify.com/v2/acts/travelmonitorlab~aeo-ai-visibility-checker/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-site.com", "generateLlmsTxt": true}'

It's API-first and works through the Apify MCP server, so an LLM agent can audit a website mid-conversation. No browser, no proxy — a plain HTTP audit that runs in seconds and costs nothing. It's free, deliberately: it's my 12th Actor and the first one I give away, because an AEO checker is exactly the kind of tool that should be a utility, not a product.

The bug that taught me something

First deploy: every run returned SUCCEEDED… with an empty dataset and a silent log. The cause wasn't the platform — it was me: I defined async def main() and never called it. The module loaded, defined functions, and exited 0. One missing line:

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

A "successful" run proves nothing. Check the dataset, always.

Try it

Actor (free): https://apify.com/travelmonitorlab/aeo-ai-visibility-checker
I also wrote a plain-language guide for non-devs: Comment être cité par ChatGPT quand on est un commerce local (French, with the same 7 criteria explained)

If you run it on your site, drop your score in the comments — I'm curious what the distribution looks like.

Nature Detective — the offline AI that sends my kids back outside

Jeffrey Turov — Tue, 06 Oct 2026 09:10:54 +0000

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

Last Sunday I watched my kids walk past a hundred fascinating things without seeing a single one.

We live in Mersch, in the middle of Luxembourg — fifteen minutes from forests that have more species per square meter than my phone has apps. And yet the walk was negotiations: five more minutes of screen, then we'll go. The screen is the destination. The forest is the commute.

So for this challenge I built the opposite deal: the screen becomes the reason to go into the forest — and the forest stays the point.

What I Built

Nature Detective is an offline-first nature companion for kids aged 5-10.

A child photographs something alive — a plant, a beetle, a mushroom. An open-weight vision model (Gemma 3 4B, running entirely on local hardware) identifies the find, tells one true fun fact a seven-year-old would love, sets a safety rule, and then does the thing no engagement-optimized app would ever do: it sends the kid back outside.

🎯 "Count how many different colored flowers you can spot before the next corner!"

Every identification comes with a mission — count, find, compare, observe. Missions never involve the screen. The screen is the shortest part of the experience, by design.

Every discovery lands in a field journal on the device, with a detective rank that grows with real outdoor finds (🐣 → 🐾 → 🦊 → 🦉). No account, no ads, no streak anxiety — just a collection of afternoons.

Try the live demo — it runs on my own machine, on Gemma 3, right now.

Demo

The full flow, no signup, works from a phone browser:

Open the live demo
Snap a discovery (or upload any plant/insect photo)
Get the identification, the fact, the safety badge — and your mission
Check the field journal

Fair warning: inference on a 24-core CPU takes ~15-60 seconds depending on load. Slow enough to look at the real thing while you wait — which, honestly, is also the point.

Code

jeffreyturov-dev / nature-detective

🔍 Nature Detective

An offline-first nature companion that gets kids off the screen and into the woods. Built for the Hacktoberfest 2026 DEV Challenge — Week 1: Touch Grass.

Live demo: https://main-michael-stanford-myrtle.trycloudflare.com

A child on a hike photographs a plant, a bug, a mushroom. An open-weight vision model (Gemma 3 4B) running locally identifies the find, tells one true fun fact sets a safety rule, and hands out the next outdoor mission — count, find compare. Every discovery lands in a field journal on the device.

No account. No cloud. No photo, no GPS coordinate, no child's data ever leaves your own hardware. It runs where the forest has no bars — that's the whole point.

Why open matters here

No internet, no problem. Inference runs on a local machine (a laptop, or a Raspberry Pi in a backpack acting as a Wi-Fi hotspot). The forest has no 5G…

View on GitHub

The whole stack, MIT licensed:

Piece	Choice	Why
Vision + reasoning	Gemma 3 4B via Ollama (Q4_K_M)	open-weight, multimodal, runs on CPU
Backend	FastAPI + SQLite	one file, zero infra
Frontend	Vanilla JS PWA, zero external assets	the offline claim has to be true
Cost	€0	no API key, no per-call fee, ever

How I Built It

One model call turns a photo into a strict JSON object: identification, kid fact, safety level, next mission, quiz question. Everything the screen shows, in a single pass — because a children's app in a forest cannot afford round trips, and mine literally has none to afford: it runs where there is no signal.

📱 phone camera ──► FastAPI ──► Gemma 3 (local vision) ──► strict JSON
                                                              │
        field journal (SQLite) ◄── safety net (code) ◄── verifier pass

The interesting part is not the pipeline. It's what the pipeline refuses to do.

The part I'm most proud of: what it refuses to do

During testing, I fed the app an abstract watercolor — green and yellow blur, no living thing in it. A single-pass version of the app answered, with high confidence: "Spiderweb, Araneae."

It was a confident, detailed, completely fabricated answer. The most dangerous kind of wrong — the kind a child would believe, remember, and repeat at school.

An app that teaches nature to kids has one job that outranks every other: never teach a lie. So now every identification goes through a second pass — a verifier, running on the same local model, whose only job is to doubt the first answer. The trick that makes it actually work: the verifier never sees the claim first. It must describe what it objectively sees — "The image is an abstract painting, not a living organism." — and only then decide whether the claim matches its own independent observation. Ask it to judge the claim directly and it politely agrees with everything; make it commit to its own eyes first, and it catches the lie.

The abstract painting now gets the honest answer: "A first guess said this might be a spiderweb, but my double-check disagreed — and a good detective never teaches a maybe as a fact. Ask a grown-up or a field guide!"

Teaching a child that "I don't know" is a respectable answer might be the most valuable feature in the whole app.

Safety works the same way — enforced twice, because prompt rules are suggestions and code rules are guarantees. The model is instructed that mushrooms and berries are always look, don't touch. And then the backend overrides it in code anyway, every time, no matter what the model says. When I tested it with a fly agaric (Amanita muscaria — the red one with white dots, beautiful and toxic), it identified it correctly and refused any interaction with it, twice over.

Why Does Open Innovation Matter?

This project doesn't just use open weights. It only exists because of them.

The forest has no bars. The whole point is a place with no signal. A closed API is a product that stops working exactly where mine starts working. Local inference isn't an optimization here — it's the product.
I will never upload my kids' photos to someone else's server. Not their faces, not their location, not their finds. With Gemma running on my own hardware, nothing ever leaves the device. That's not a privacy policy; it's physics.
€0, forever. No API key, no subscription, no per-call cost — so it can run in a school, a scout group, a nature club with no budget, anywhere in the world.
Ownable and swappable. Any open-weight vision model Ollama can serve drops in with a one-line change. When a better small multimodal model ships next month, every Nature Detective gets smarter for free. Try getting that guarantee from a deprecated API version.

A closed model would have made this easier to demo and impossible to believe in.

Prize Categories

Best Use of Gemma — Gemma 3 4B is the entire brain of the project: species identification, kid-level explanations, mission generation, and the self-verification pass, all running locally through Ollama.

This Sunday we're going back to the forest. My kids already asked if the detective is coming.

He's in my pocket. He knows nothing about engagement metrics. And his favorite sentence, by far, is: "Now go look for yourself." 🌿

I Put 6,522 Birds in My Backpack: Offline Bird Call ID on a Laptop, Zero Internet

Jeffrey Turov — Tue, 06 Oct 2026 08:11:43 +0000

The problem with birding apps

The best birding happens exactly where your phone becomes a brick: deep forest, mountain trails, that marsh 40 minutes from the nearest cell tower. The moment a call you don't recognize echoes through the trees, the usual flow is: record it, hope you remember it later, upload it when you get home, wait for the cloud.

I wanted the whole loop to close on the trail. So I built trail-bird-id: point it at an audio file, get the species. No internet. No account. No API key. No per-call cost. Just a laptop (or a Raspberry Pi) and an open-weight model.

$ python identify.py trail_recording_07h42.mp3

Analyzing trail_recording_07h42.mp3 (fully offline, BirdNET V2.4, 6,522 species)...

  1. Black-capped Sparrow (Arremon abeillei)      conf=0.99  @ 0.0-3.0s
  2. Streaked Saltator (Saltator striatipectus)   conf=0.86  @ 3.0-6.0s

The build: embarrassingly little code

The heavy lifting is BirdNET — an open-source audio classifier from the Cornell Lab of Ornithology and Chemnitz University of Technology (CC BY-SA 4.0), trained on 6,522 species. It ships as a ~50 MB TFLite/TensorFlow model inside the pip package, which is the whole trick: installing the library means installing the brain.

My contribution is a ~60-line wrapper, identify.py, that runs the model in 3-second windows over any wav/mp3/ogg file and aggregates to the best-confidence detection per species:

uv venv --python 3.11 .venv
uv pip install --python .venv/bin/python birdnet-analyzer
.venv/bin/python identify.py your_recording.mp3 --top 5

That's the entire setup. No Docker, no GPU, no cloud credentials.

Does it actually work? Verified against ground truth

I don't trust demos that only show one cherry-picked clip, so I tested against four field recordings from Wikimedia Commons where the species is known from the recording metadata (xeno-canto / iNaturalist sourced):

Recording	Expected species	Top-1 prediction	Confidence
Black-capped Sparrow XC250490 (Niels Krabbe, CC BY-SA)	Arremon abeillei	✅ Black-capped Sparrow	0.99
Australian Magpie song (CC BY-SA)	Gymnorhina tibicen	✅ Australian Magpie	0.99
Brown Hawk-Owl, South Bengal (CC BY)	Ninox scutulata	✅ Brown Boobook (same bird, name updated by taxonomists — the model is more current than the file title)	1.00
Guira Cuckoo (CC0)	Guira guira	✅ Guira Cuckoo	0.95

4/4 top-1 correct, across four continents and four very different vocalizations (sparrow song, magpie caroling, an owl's hoot, cuckoo chatter). Runtime: ~6.7 seconds wall-clock for a 40-second recording, on a plain CPU.

Proving "offline" isn't marketing

"Works offline" is easy to claim. So I re-ran identification with all egress blocked — every proxy environment variable pointed at a dead localhost port, so any HTTP call from the Python stack would fail instantly:

$ env HTTPS_PROXY=http://127.0.0.1:9 HTTP_PROXY=http://127.0.0.1:9 \
      ALL_PROXY=socks5://127.0.0.1:9 NO_PROXY= \
      .venv/bin/python identify.py audio/australian_magpie.ogg

  1. Australian Magpie (Gymnorhina tibicen)   conf=0.99  @ 9.0-12.0s

Still works, because there is no network code to fail. The weights live in site-packages/birdnet_analyzer/checkpoints/. The trail is the deployment target, and the trail has no SLA.

Why open innovation matters here

This is where the open approach doesn't just match the closed one — it wins:

It works where the closed apps can't. Zero-connectivity is the core use case, not an edge case. A cloud API is a non-starter on a ridgeline.
Nothing leaves your device. Field recordings often capture more than birds — your voice, your location, your hiking companions. With a local model, that data never touches a server you don't control.
You can actually own it. Pin the model version, tune the confidence threshold for your region, swap in a species list for your local patch (--lat/--lon filters to species plausible for your coordinates), or fine-tune on your own recordings. Try doing that with a closed mobile app.
Cost at scale is zero. A citizen-science project processing 10,000 hours of soundscape pays nothing per call — because there are no calls.

Honest limitations

BirdNET needs a reasonably clean recording; heavy wind or overlapping dawn-chorus can drop confidence. The 3-second windowing means very short calls can be missed.
My test set is 4 recordings, not 4,000 — it's a smoke test with known ground truth, not a benchmark. (BirdNET's own peer-reviewed evaluations cover the rigorous part.)
I built and validated this on real field recordings made by others; the full "take it outside" bonus round happens this weekend on my local trails — I'll update the repo with what it hears.

A Voz dos Meus — my father waited with flowers. I built a memory that never forgets

Jeffrey Turov — Sun, 04 Oct 2026 19:16:01 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend — and for the **Best Use of Gemma* category.*

In 1996, a six-year-old boy got on a bus in Amares, near Braga, for a long ride north with other Portuguese families. He doesn't remember any other children on that bus — emigration was mostly parents back then. When the bus finally reached Luxembourg, his father was standing there, waiting for them, holding a bunch of flowers for his mother.

That boy was me. The man with the flowers is my father.

And today I'm a father myself — two kids who know Luxembourg as home, who speak French at school, whose Portuguese is a work in progress, and who have never seen their grandfather wait for anyone with flowers. We film our children growing up. Nobody films our parents growing old. My father carried his whole life to Luxembourg and lets the story out only in pieces, at the table, when something reminds him — and if you ask directly, he shrugs: "Não é nada." It's nothing.

It's not nothing. So for this challenge I built the person I love most a memory the family can keep talking to — and the very first voice I put in it was my own, telling the story where he's the hero. Because my memories belong to my two kids now, too: one day they'll want to know who their father was at six, and their grandfather with the flowers.

A Voz dos Meus — The Voice of the Ones We Love

The concept fits in one sentence, and it isn't really about my father:
the people we love most are the ones we record least — so capture their voices, and let the family ask their memory questions. Forever.

Father, grandmother, aunt, the friend who's like family — pai, avó, tia — the concept is the same, which is why the app is called A Voz dos Meus, "the voice of my people". My father is simply the reason it exists.

Three screens, because he's not a user, he's my father:

Contar história — one big red button. Press it, talk as long as you want, press it again. That's the entire interface. (There is no step 2.)
Histórias — every story transcribed, with the original audio underneath, so the grandchildren hear his voice, not a synthesizer's.
Perguntar — the family asks: "Pai, como é que nós viemos para o Luxemburgo?" — and the memory answers in warm, simple European Portuguese. Read it instantly with Ouvir 🔊, translate it for the grandkids with Traduire 🇫🇷 — or press the button that still gives me goosebumps:

Na voz dele 🧡 — the answer is synthesized in his own cloned voice, by an open-source model running in my home.

Full honesty: today it comes out with a slight Brazilian accent — the open model's Portuguese was trained mostly on Brazilian data, and his is from Amares. A closed service would hide that kind of rough edge behind a polished voice you can't inspect. Here, we can see the limitation, name it, and swap the component the day a better European-Portuguese voice model ships — without asking anyone's permission. That's the point of building on open pieces: the roadmap belongs to us.

Here's the full flow in motion — question, grounded answer, the story library, the one-button recorder:

Live demo: https://tariff-ventures-income-insights.trycloudflare.com — a temporary tunnel to the same home box my family uses; it's a kitchen appliance, not a datacenter, so be patient with it (voice cloning on a CPU takes ~2 minutes — real time for real love).
Source: github.com/jeffreyturov-dev/avozdosmeus (MIT — take it, build it for someone you love).

The part that matters most: what it refuses to do

The first version of the "ask" feature did something that looked like a success and was actually a betrayal.

I asked it: "Pai, qual era o teu prato preferido quando eras pequeno?" — what was your favorite dish as a kid? I (the Pai of this archive) have never told that story. The model, eager to please, invented one — grilled sardines with potatoes and kale, warm and plausible and completely false. A memory machine that hallucinates isn't a memory machine. It's a fiction machine wearing a father's voice.

For a product, that's a bug. For a family archive, it's a moral failure. If my children ask this thing a question in twenty years, I need to trust the answer the way I'd trust their grandfather.

So I rebuilt the answer path around a refusal, in three layers:

Retrieval — the question is embedded and matched against story chunks (open embeddings, local SQLite).
A strict classifier — before any prose is generated, a separate pass asks: "Do these stories explicitly contain the answer? Reply only SIM or NÃO." If NÃO, the generative model is never called. A model cannot hallucinate what it never sees.
No-invention rules — when the stories do contain the answer, the answering prompt runs under absolute rules: no invented people, places, dates or details. Not even to complete a sentence nicely.

Today, that same trap question gets this answer — every time, deterministically:

"O Pai ainda não contou essa história. Pergunta-lhe na próxima visita — e se ele contar, grava-a aqui. 🧡"

"Your father hasn't told that story yet. Ask him on the next visit — and if he tells it, record it here."

It admits the gap, and — my favorite detail — it sends the family back to him. The app knows its job is not to replace my father. Its job is to make sure he gets asked while he can still answer.

How it works (everything open, everything local)

 his voice ─▶ faster-whisper ─▶ story text ─▶ chunks ─▶ embeddings ─▶ SQLite
                                                         │
 a question ─▶ embed ─▶ retrieve ─▶ strict classifier ─▶ Gemma 3 (local,
              "never invent" rules) ─▶ answer ─▶ read aloud ─▶ or cloned
              in HIS voice by XTTS v2 — all of it inside my home

faster-whisper (large-v3-turbo, int8) transcribes the stories on a plain CPU — no GPU anywhere in this project.
nomic-embed-text vectors in a humble SQLite file. His whole memory is a folder you can copy to a USB stick.
Gemma 3 (4B) via Ollama is the brain: the honesty classifier, the grounded answering, story titling, and the Portuguese→French translation for the grandchildren.
XTTS v2 (open-source voice cloning) reads answers in his voice — synthesized locally, from one minute of his real audio.
Browser SpeechSynthesis handles the instant read-aloud — so even that works with the router unplugged.

The backend is a single Flask file. The frontend is one HTML page. No Docker, no accounts, no API keys, no build step. An old laptop on the home Wi-Fi is the entire infrastructure — which is precisely the point.

Why open-source wasn't a choice here — it was the requirement

Every "why open matters" section talks philosophy. Mine is simpler: I was not going to put my father's voice on a stranger's server.

His stories are among the most private data my family owns. Where he came from, who he waited for with flowers. A closed API would mean shipping that intimacy to a datacenter I can't see, under terms I can't negotiate. With open-weight models running in my home, his voice — and its digital double — physically never leaves the house. The threat model is my Wi-Fi password.
Voice cloning makes this non-negotiable. I'm creating a model of a real person's voice. If that capability lived in a cloud account, the consent conversation gets murky fast. Local and open means his voiceprint belongs to him, full stop — I can show him exactly where it lives, and delete it by deleting a folder.
It has to work in a kitchen, not in a demo. No internet? Everything above still runs. Closed models turn into a blank screen the moment the connection drops — his memory doesn't.
It has to cost €0 forever. A subscription is a thing that gets cancelled. This is meant to outlive my father, and ideally me. Open models don't send invoices to my children.
It has to be ownable by the next family. Every component — Whisper, the embeddings, Gemma, XTTS, the UI — is open and swappable. When a better open Portuguese model appears, his memory upgrades without asking anyone's permission.

That's what "open innovation" means when the person is someone you love: not a license badge, but a promise you can actually keep — your voice stays yours.

What happens next Sunday

The roadmap writes itself, and it isn't mine anymore — it's the family's: one archive per person (Pai today, Avó next, the tia who tells the scandalous ones after that), WhatsApp voice-message import, a printed family book for Christmas.

But none of that is the point. The point is that next Sunday, at the table, when he lets out one of those pieces and shrugs "não é nada" — I'll press a red button. And one day, when my two kids ask this memory who their father was at six, and who their grandfather was with the flowers, it will answer — carefully, honestly, in our voice.

It will be something. Forever. In his own voice.

Built with

Gemma 3 (open-weight, via Ollama) — the brain: honesty classifier, grounded answering, titling, translation. Entered in **Best Use of Gemma.
faster-whisper — open-source speech-to-text, CPU-only.
XTTS v2 — open-source voice cloning (CPML, non-commercial) so answers can sound like him.
nomic-embed-text — open embeddings for memory retrieval.
Python + Flask + SQLite + one HTML page. Repo: github.com/jeffreyturov-dev/avozdosmeus (MIT).

If you have someone whose voice you'd miss — fork it. This weekend is long enough to save it.

I turned my mother-in-law's voice memos into a recipe book — 100% local open-source AI

Jeffrey Turov — Sun, 04 Oct 2026 08:34:18 +0000

Posted during Hacktoberfest 2026 — a weekend build celebrating open-source AI.

Who it's for

Odilia is my mother-in-law, and her cooking lives in voice memos. Decades of family recipes — including her Luxembourgish Gromperekichelcher (crispy potato fritters) — exist only as rambling WhatsApp audios she sends when one of us asks "how do you make that again?". Nobody ever scrolls back to find them, and nobody writes them down.

So this weekend I built her voice-recipe-book: drop a voice memo in, get a clean recipe card out. One real person, one real problem.

What it does

voice memo (.mp3/.m4a/.wav)
   │
   ├─ transcribe.py        faster-whisper (open-weight Whisper, int8 CPU) → raw text
   └─ structure_recipe.py  Qwen2.5-3B-Instruct (open-weight LLM, local CPU) → Markdown card
                              title · servings/times · ingredients · steps · "the secret"

Everything runs locally. No cloud, no API key, €0 per recipe.

👉 Repo: https://github.com/jeffreyturov-dev/voice-recipe-book

Demo (real run)

The demo memo is TTS-synthesized because I won't publish a real family recording — the pipeline is identical either way. Whisper (small, CPU) transcribed the 40-second French memo at confidence 1.00. One honest failure: Gromperekichelcher came out as "grands-pèreux qui chèrent" — regional dish names are exactly the words a speech model has never seen, so the app accepts an explicit title (a feature, not a bug).

Then Qwen2.5-3B-Instruct, running on the same CPU, structured the raw transcript — hesitations and all — into this card (actual output, unedited except the title):

# Gromperekichelcher d'Odilia
**Portions :** 8 | **Préparation :** 30 min | **Cuisson :** 15 min

## Ingrédients
- 1 kg de pommes de terre farineuses
- 1 oignon
- 2 œufs
- 2 cuillères à soupe de farine
- Sel, poivre, noix de muscade
- Persil haché (non précisé)

## Étapes
1. Râpez les pommes de terre farineuses et essorez-les bien dans un torchon.
2. Mélangez avec l'oignon râpé, les œufs, la farine, le sel, le poivre et la muscade.
3. Chauffez de l'huile dans une poêle à feu moyen.
4. Formez des galettes et aplatissez-les.
5. Faites frire 3 à 4 minutes de chaque côté jusqu'à ce qu'elles soient croustillantes.
6. Servez chaud avec une compote de pommes.

## Le secret
> Essorer bien les pommes de terre pour éviter qu'elles détrempe.

It even extracted "the secret" — squeeze the potatoes dry — the one line of grandma-wisdom that makes the dish.

Why open innovation matters here

Privacy: family voice memos never leave the laptop. No third-party server ever hears Odilia's voice. With a cloud speech API, that's simply not true.
Cost: €0 per recipe, forever, vs ~€0.02–0.10 per memo with a cloud speech+LLM stack. A whole family book costs nothing.
Offline: after a one-time model download, it works in a kitchen with no internet.
Hackable: every layer is an open weight — swap Whisper sizes, swap the LLM, fine-tune on her dialect, change the card template. A closed API gives you none of that.

The stack: Whisper (MIT, via faster-whisper/CTranslate2) + Qwen2.5-3B-Instruct (Apache 2.0) on plain CPU. Total new code: ~150 lines of Python, written this weekend — the open models do the heavy lifting.

Try it

git clone https://github.com/jeffreyturov-dev/voice-recipe-book
cd voice-recipe-book && pip install -r requirements.txt
python3 app.py memo.m4a "Grandma's apple pie"

Next for Odilia: a weekly cron that pulls her memos and prints the growing book for Christmas. She doesn't need to know what an LLM is. She just needs her recipes to outlive the chat history.

A 3B model that beats a 7B: failure-driven orchestration on uncontaminated knowledge

Jeffrey Turov — Thu, 01 Oct 2026 19:53:32 +0000

How a fully sovereign QA stack — local Wikipedia index, distilled Qwen2.5-3B reader, and crutches built only from measured failures — went from 33% to 52% on facts no LLM can have memorized, and matched a zero-shot 7B more than twice its size.

TL;DR

Configuration	Post-cutoff-150 accuracy
3B naked (no retrieval)	0.0% [0–2.5]
7B naked	0.0% (by construction — see below)
3B + sovereign chain (start, Sep 29)	33.3%
3B + sovereign chain (final, Oct 1)	52.0% [44.1–59.8]
7B zero-shot, same chain	50.0% [42.1–57.9]

Every number comes from a deterministic gate with Wilson 95% CIs. Every rollback is published below, not just the wins. The benchmark is public on Kaggle (post-cutoff-150).

1. Why "post-cutoff": most retrieval benchmarks measure memory, not retrieval

HotpotQA (2018) sits inside the training data of every 2024 model. We measured it: our naked 3B scores 30.5% on HotpotQA — from pure memorization. On such a benchmark, injecting retrieved evidence can only hurt: the "does retrieval help?" question is rigged from the start.

So we built post-cutoff-150: 150 questions generated from local Wikipedia pages whose lead paragraphs cite 2025–2026 facts, with answers that are exact spans of the source text. The contamination filter is deterministic and brutal: if the naked 3B can answer a question without context, the question is rejected. Final control: naked model = 0.0% [0–2.5]. Whatever the pipeline scores from there is net retrieval value — nothing else.

2. The sovereign stack

Index: 7.2M Wikipedia pages + 11.4M redirects, FTS5, 49 GB, fully local (crash-proof indexer, resumable to infinity).
Reader: Qwen2.5-3B-Instruct + LoRA stack trained inside the harness (SFT on noisy evidence, then DPO — the only technique that ever broke a plateau, twice).
Orchestrator: deterministic arms chained as a superset — anchor extraction → lead fetch → gated joint reading → deterministic bridge hop (n-grams certified against the 7.2M titles) → full-text search retry → Wikipedia tables arm (wikitext parsing with rowspan inheritance) → semantic lens → live full-text search.
Gate discipline: a challenger is PROMOTED only if it beats the champion on the same 150 questions, through the same matcher, with Wilson CIs reported. Otherwise ROLLBACK — and a rollback is a success of the system, not a failure to hide.

Two infrastructure rules that cost us bugs before they became rules: never evaluate a model in memory right after training (post-train state measures 0% on a perfectly healthy model — save, reload from disk, then gate), and all extraction LLM calls at temperature 0 (temp 0.1 anchoring injected ±4–6 points of run-to-run variance into every gate we ever ran).

3. The campaign: 33.3% → 52.0% in four days

Step	Mechanism	Score	Verdict
Baseline pipeline	anchors → lens → joint read	33.3%	—
+ fullpool	show the reader the whole pool, not just top sentences	34.7%	kept (reserve)
+ FTS-retry	full-text enrichment when reading fails	39.3%	kept
+ entropy-gated routing	accept a read only if token entropy ≤ 0.6	42.0%	PROMOTE
+ SLOTS	2-slot "preuve → réponse" prompt with deterministic verification	43.3%	PROMOTE
+ deterministic anchors fix, echo-retry, FR meta-strip	—	46.0%	kept (reserve)
+ FR→EN translation arm	French meta-questions translated once, read in English	48.0%	PROMOTE
+ Wikipedia tables arm	wikitext tables → "header: cell" lines → lens	48.7%	PROMOTE
+ semantic lens	12B judges sentence relevance instead of token overlap	52.0%	PROMOTE

What did not work — measured, gated, published:

Self-consistency ×5: null. The literature assumes random errors that voting smooths; ours are systematic (wrong page → same wrong answer 5 times).
Best-of-N by confidence, inter-path consensus: null, same reason — independent paths converge to the same errors.
IRCoT (academic interleaved retrieval-CoT): 10% naive, 25% hybrid — our sequential pipeline beats it by 17+ points. For a 3B, anchoring by exact titles beats conversational retrieval.
Query planner (typed decomposition): rollback both directions — deterministic decomposition doesn't convert hard failures; they're hard for rules too.
SpanLift (generation-free QA: enumerate spans, judge by evidence lift): 1.3% — catastrophic. The candidate enumerator produced sentence fragments, and the scorer missed even when the truth was a candidate. Paradigm abandoned on 3B.
GRPO (both reader and GSM8K): gradient desert is structural (frac_reward_zero_std = 0.8). We fixed the mechanism (dense rewards → 0.2, reward flowing) — and transfer to the target distribution was still null. Two independent adapters scored identically to the champion.
Deep plaintext retrieval (full pages beyond the lead) and live Wikipedia full-text search: both net zero — every win overlapped an existing arm's rescue.

4. The capstone: 3B trained + orchestrated vs 7B zero-shot

Same chain, same questions, same matcher, same deterministic gates. The only variable swapped: the reader (Qwen2.5-7B-Instruct, 4-bit, no LoRA, no tuning).

Arm wins	3B (78/150 = 52.0%)	7B (75/150 = 50.0%)
Primary reader arm	50	66
Crutch arms (semantic lens, tables, fallbacks)	+28	+9

Raw capacity wins the primary arm (+16 for the 7B). But the crutches — each one built on a measured 3B failure mode (echo killed by SLOTS, entropy calibrated at 0.05–0.21 for correct vs 1.0+ for guessing, deterministic proof verification) — add 28 points to the 3B and only 9 to the 7B. The 7B has no echo to fix and its entropy sits near 0.002, making the calibrated gate useless. The crutches don't transfer because they were never generic — they were prosthetics fitted to a specific patient's limp.

Honest caveats: the confidence intervals overlap (we claim "ties or beats", not "beats"); the 7B is 4-bit quantized and zero-shot — a tuned 7B would do better, and that's a fine next experiment.

5. What we actually learned (the publishable part)

Contamination decides what a benchmark measures. On memorized knowledge, retrieval adds nothing; on post-cutoff knowledge, a sovereign pipeline turns 0% into 52%.
Small-model errors are systematic, not random. Everything built on smoothing randomness (voting, consensus, best-of-n) failed four independent times. Everything built on diagnosing the systematic class worked.
Entropy is a calibrated confidence signal nobody was reading. Correct answers: 0.05–0.21. Echoes/guesses: 1.0–2.27. One threshold, zero training, +2 points.
SLOTS = externalized working memory. Force the model to first copy the proof sentence, then copy the answer from inside the proof, and verify both deterministically at receipt. The meta-question echo class (24 questions) died (3 left).
Context quality beats context coverage. The semantic lens won 8 net questions — 4× its coverage diagnosis — because a relevance-filtered context reads better, not just finds more. Measure arms in-chain, not by detection rate.
Deterministic gates catch the bugs that fake results. In-memory post-training evals, a urllib import swallowed by try/except (the "reader" we benchmarked for days was the fallback), a wedged CUDA process serving empty answers, ±6-point anchoring noise — every one of these would have become a false claim without the discipline.
DPO is the only training move that ever broke a plateau (GSM8K 60→67, reader 42→45, twice confirmed). SFT saturates; GRPO's gradient desert is structural.

6. Reproducibility

Benchmark: post-cutoff-150, public on Kaggle, with the contamination filter (naked = 0% verified).
All scores from deterministic gates (Wilson 95% CI), same matcher everywhere (a lower bound, consistently applied — comparisons valid).
6 promotions, 6 rollbacks — all archived with per-question outputs.
Hardware: one RTX 5090. No API calls to any frontier model for the answers — the 12B orchestration LLM and the 3B reader are both fully local.

7. Limitations

150 questions is honest but small; we report CIs and refuse to claim deltas inside the noise. The matcher (containment + token subset) undercounts morphological variants — scores are lower bounds. The 7B comparison is zero-shot/4-bit by design (we isolated the orchestration variable, not the best possible 7B). The residual 72 failures split between evidence absent from every source we can reach (obscure entities, join-queries) and pure 3B reading capacity — that ceiling is documented, not hidden.

Built by an autonomous harness that diagnoses its own failures, trains only through deterministic gates, and publishes its rollbacks. The rollbacks taught us more than the wins.

DEV Community: Jeffrey Turov

Memoria: Keeping Family Voices Alive with Local Whisper + Gemma

What I Built

Demo

Code

How I Built It

The Moment It Landed

Verified Results

Why Open Innovation Matters

Limitations

Prize Categories

Slow and Steady: An Agent That Runs My Apify Side Business While I Sleep

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Sloth Digest 🦥 — a local Gemma 3 agent that does my inbox triage so I don't have to

What I Built

Demo

Code

jeffreyturov-dev / sloth-digest

Local AI agent that triages your Gmail overnight into a morning digest — Gemma 3 4B, 100% offline, privacy-first

🦥 Sloth Digest

Why local?

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

I Let an AI Agent Run Parts of My Real Businesses for a Year. Here Are the Receipts.

What "running a business with an AI agent" actually means

The receipts

What the agent does alone vs. what I validate

The failures are the best part

The series

I built an MCP server that lets AI agents book real hotel rooms (no OTA commission)

The architecture

The payment hand-off is a feature

What I learned writing tool descriptions

Distribution

Live links

I built an offline review-reply concierge for my family's hotel — €0 per reply, five languages, no cloud

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My First User

Prize Categories

I built a free AEO checker — is your website visible to ChatGPT, Perplexity and Google AI?

The 7 things AI engines actually check

What the Actor returns

Call it from anything

The bug that taught me something

Try it

Nature Detective — the offline AI that sends my kids back outside

What I Built

Demo

Code

jeffreyturov-dev / nature-detective

🔍 Nature Detective

Why open matters here

How I Built It

The part I'm most proud of: what it refuses to do

Why Does Open Innovation Matter?

Prize Categories

I Put 6,522 Birds in My Backpack: Offline Bird Call ID on a Laptop, Zero Internet

The problem with birding apps

The build: embarrassingly little code

Does it actually work? Verified against ground truth

Proving "offline" isn't marketing

Why open innovation matters here

Honest limitations

Links

A Voz dos Meus — my father waited with flowers. I built a memory that never forgets

A Voz dos Meus — The Voice of the Ones We Love

The part that matters most: what it refuses to do

How it works (everything open, everything local)

Why open-source wasn't a choice here — it was the requirement