DEV Community: Jeffrey Turov

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

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

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.

I benchmarked what frontier models actually know about 2026 — most of it, they don't

Jeffrey Turov — Thu, 01 Oct 2026 14:03:21 +0000

Benchmark: https://www.kaggle.com/benchmarks/tasks/jeffreyturov/post-cutoff-150
Dataset: https://www.kaggle.com/datasets/jeffreyturov/post-cutoff-knowledge-150

The itch

Every LLM leaderboard tells you how models score on knowledge from their training data.
I wanted the opposite: what do models know about things that happened AFTER their
training cutoff? Not retrieval-augmented answers — raw parametric knowledge of
2025-2026 facts.

The benchmark: Post-Cutoff Knowledge 150

150 factual questions built from a 7.2M-page web index, restricted to pages citing
2025-2026 events. Two construction guarantees make contamination impossible:

Span-verified: each gold answer is an EXACT span of the source page's lead (deterministic string check, no LLM judge).
Contamination-filtered: every candidate question is asked to a 2024-cutoff 3B model with NO context. If the small model can answer it from memory, the question is REJECTED (~4% of candidates were). Kept questions are provably outside 2024 training data: the 3B control scores 0/150.

Scoring: case-insensitive, token-boundary containment of the gold span — a lower
bound (morphological variants of a correct answer can be missed). Prompts demand
a bare fact, no sentence.

What I ran it against

9 frontier models, 150 questions each, single run, no retries on the scored attempt
(prompt: "answer with just the requested fact, no sentence"). k = correct answers
out of 150; CI = Wilson 95%.

Model	Accuracy	k/150	Wilson 95% CI
Gemini 3.7 Flash	24.0%	36	[17.9%, 31.4%]
DeepSeek-R1 (0528)	20.0%	30	[14.4%, 27.1%]
Gemini 2.5 Pro	16.0%	24	[11.1%, 22.4%]
GPT-5.4	11.3%	17	[7.2%, 17.4%]
Gemini 3.5 Flash-Lite	8.7%	13	[5.1%, 14.3%]
Gemini 2.5 Flash	7.3%	11	[4.1%, 12.7%]
Gemma 4 31B (open weights)	6.0%	9	[3.2%, 11.0%]
Claude Haiku 4.5	5.3%	8	[2.7%, 10.2%]
GPT-5.4 nano	3.3%	5	[1.4%, 7.6%]

Claude Sonnet 4.5 was scheduled three times and never started (infrastructure-side,
not a scoring failure) — it is excluded rather than reported as zero. Gemma 4 31B
hit per-question timeouts on 5 of 150 items (slow open-weights serving); the
unanswered items are counted as wrong, standard practice — 9/150 = 6.0%.

What surprised me

The best model still fails 3 questions out of 4. Gemini 3.7 Flash leads at
24% — meaning even the freshest frontier model has no parametric trace of most
2025-2026 facts. Anyone building on "the model probably knows" is wrong 76% of
the time.
Reasoning does not rescue knowledge. DeepSeek-R1 (20.0%) scores second and
beats several newer generalist models — but its long chains cannot invent a fact
that was never in training. Reasoning moves the needle on problems, not on
missing data.
Size and price do not order the ranking. GPT-5.4 (11.3%) sits below
DeepSeek-R1 and far below Gemini 3.7 Flash; Gemini 2.5 Pro (16.0%) beats its own
family's newer Flash-Lite (8.7%). Freshness of training data matters more than
benchmark muscle.
The honest-control design works: the 2024-cutoff 3B control scores exactly
0/150 — by construction — which makes every point above zero a genuine
post-cutoff signal, not contamination.

Honest limits

Questions are single-hop by construction (generated from one page lead). This benchmark does not test multi-hop reasoning.
The "3B fails" filter makes the control ≈0 BY DESIGN — the number that matters is each frontier model's absolute score, not the gap to control.
Span containment is a lower bound on true accuracy.
150 items → Wilson CI ≈ ±8 points. Direction is reliable, fine ranking is not.

What's next

Extend to 500 questions to tighten CIs.
Multi-hop variant: questions whose answer requires joining TWO 2025-2026 pages.
RAG arm: same questions WITH the source page as context, to measure the retrieval uplift per model (preliminary local data on a 3B pipeline: 0% → 33.3%).

Built with the kaggle-benchmarks library. Task source is public on the
benchmark page — fork it and run your own lineup.

I built 11 pay-per-use data APIs that AI agents can call directly (Google Maps, TikTok, LinkedIn, review monitoring) — here's what I learned

Jeffrey Turov — Tue, 29 Sep 2026 15:13:34 +0000

A few months ago I published a set of Actors on Apify Store. Today they're all AI-agent ready: any LLM agent (Claude, GPT, Cursor, LangChain, n8n) can discover and call them through the Apify MCP server — no custom integration code needed.

This post is the full playbook: what the tools do, how pay-per-event monetization works (including the pricing trap that made me lose money on every sale), the bugs I hit, and how AI agents actually consume the tools.

The toolbox

Actor	What it extracts	Price (pay-per-event)
Google Maps Business Scraper	Names, phones, websites, ratings, reviews, GPS	$1.00 / run + $0.03 / business
TikTok Profile & Video Scraper	Followers, likes, bio, per-video stats	$0.01 / profile + $0.002 / video
Instagram Profile Scraper	Followers, bio, verified, engagement	$0.01 / profile
YouTube Video & Channel Scraper	Views, likes, subscribers, search results	$0.002 / video
LinkedIn Profile Scraper	Headlines, companies, skills, experience	$0.02 / profile
RAG Web Browser	Clean Markdown from any URL + Google search	$0.003 / page
Fuel Prices France API	Real-time prices, 9,800 stations, GPS	$0.20 / run + $0.01 / 1k stations
Hotel Rate Monitoring	Competitor rates, parity checks	fractions of a cent per item
API Breaking-Change Radar	Diffs OpenAPI specs, classifies changelogs, alerts	$0.50 / run + $0.50 / breaking change
Review Radar	New Google reviews for a business, Slack alerts	$0.25 / run + $0.01 / new review
Review Pitch Generator	Worst reviews → ready-to-send sales report	$0.25 / run + $0.10 / pitch

The last three are a different breed: not scrapers but monitors — they keep state between runs and only bill when they find something.

Why "AI-agent ready" changes everything

The old model: a human finds your scraper on the store, reads the docs, clicks buttons.

The new model: an AI agent gets a task ("find me 50 plumbers in Austin with their phone numbers"), searches the Apify Store via MCP, reads the actor's README and input schema, and calls it — end to end, no human.

For that to work, three things must be true:

Your README is written for an LLM, not just humans. Mine now all start with a "Use this tool when..." section — that's what the agent pattern-matches against the user's request.
Your input schema has a description on every field. The agent constructs the JSON input from those descriptions. No description = hallucinated parameters = failed runs = no revenue.
Your output is documented field by field. The agent needs to know what it gets back to reason over it.

Here's the actual flow with the Apify MCP server (https://mcp.apify.com — add it to Claude Desktop or Cursor in 30 seconds):

User: "Get me the follower counts of these 5 TikTok creators"
Agent: → search-actors("tiktok profile")
       → fetch-actor-details (reads README + input schema)
       → call-actor(travelmonitorlab/tiktok-scraper,
                    {"profiles": [...], "maxVideosPerProfile": 0})
       → returns structured JSON

Or skip MCP entirely — every actor is a single synchronous HTTP call:

curl -X POST "https://api.apify.com/v2/acts/travelmonitorlab~google-maps-scraper/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"queries": ["plumbers Austin TX"], "maxResults": 50}'

Monetization: pay-per-event (and the trap that cost me real money)

Apify offers several pricing models. For new actors, PRICE_PER_DATASET_ITEM is rejected — you must use PAY_PER_EVENT. The model is better anyway: you define events and charge explicitly in code:

await Actor.charge(event_name="business-scraped")
await Actor.push_data(item)

Trap #1 — the vanishing charge: put the charge AFTER crawler.run() and your event loop may already be closed — the charge silently vanishes, you deliver data for free. Charge inside the handler, right before pushing data. Always verify with chargedEventCounts in the run object after a test run.

Trap #2 — pricing below your compute cost (this one actually bit me): on Apify's free plan, the actor owner pays the user's compute. My Google Maps actor was priced at $0.005/business. A customer scraped 16 businesses → I earned $0.08, and paid $1.23 in Playwright + residential proxy costs. Margin: −1436%. Every sale lost money. The structural fix: a flat run-started event that covers fixed costs (browser launch, proxy session) plus a per-result event with real margin:

await Actor.charge(event_name="run-started")   # first line of main()

That same 16-business run now bills $1.48 instead of $0.08. If you build browser-based actors, do this from day one.

Setting pricing is pure API — and pricingInfos is append-only: you can't edit a tier in place, you append a new one:

PUT /v2/acts/{actorId}
{"pricingInfos": [existing_tier_verbatim, {
  "pricingModel": "PAY_PER_EVENT",
  "reasonForChange": "Flat run fee to cover compute",
  "pricingPerEvent": {"actorChargeEvents": {
    "run-started": {"eventTitle": "Run started", "eventDescription": "...", "eventPriceUsd": 1.0},
    "business-scraped": {"eventTitle": "Business scraped", "eventDescription": "...", "eventPriceUsd": 0.03}
  }}}]}

Apify takes 20%. Compute is paid by the user (on paid plans); you pocket the event fees.

Trap #3 — self-billing: running your own PPE actor bills your own account. Build a dryRun input flag that wraps every Actor.charge() and skips it — you can then integration-test the full pipeline for free and only flip billing on for real runs.

The QA gauntlet (or: your actor must survive an empty input)

Apify automatically runs every store actor with the schema's prefilled input and expects success within 5 minutes — three failures and your actor gets flagged "Under maintenance", then deprecated. Two lessons learned the hard way:

Never raise on empty input. If the user (or the QA bot) provides no target, fall back to a small built-in demo (2 results, dry-run forced) and exit 0. An actor that raises RuntimeError("no target") is an actor on the deprecation list.
Keep the prefill tiny. The QA run is baked into your build: a heavy prefill (20 Playwright results through residential proxies) blows the 5-minute budget and flags you. Prefill = 2 results max, dry-run on.

Battle scars (so you don't get them)

Crawlee 1.8 breaking changes: purge_on_start and navigation_timeout_secs are no longer valid kwargs — use page.set_default_navigation_timeout() in a pre_navigation_hook.
Google Maps never fires load: analytics keep streaming forever, so navigation always times out. Fix: abort images/fonts/media via page.route() (the handler must be a coroutine, not a lambda).
Residential proxies are mandatory for Google Maps, and you must pass actor_proxy_input= as a named argument to Actor.create_proxy_configuration().
French number formats will crash your floats: "4,8" → replace comma; "1 234" reviews can use \xa0 or \u202f as thousand separator.
A "SUCCEEDED" run can contain zero useful data. Always check itemCount + sample the dataset + read the end of the log.
Don't run 7 queries × 25 results in one run. Split into parallel runs of ≤5 queries × 15 results; retry failed ones sequentially (residential proxy tunnels occasionally die).
Pin your dependencies. apify>=3.2,<4 + crawlee>=1.7,<2 is a proven combo; open ranges break within weeks as PyPI drifts.

The distribution strategy

Publishing on the store is step 0. What actually moves the needle:

README written for LLMs — agents choose tools whose docs they can parse. Clear "use when", typed inputs, example I/O. The MCP server's own system prompt tells agents to read your README before calling — it's your storefront.
Niche SEO titles — "Google Maps Scraper" is saturated (the official one has 500k+ users); "Fuel Prices France API" has zero competition on the store.
Monitors > scrapers — a scraper competes with everyone; a stateful monitor (breaking changes, new reviews) with Slack alerts answers a recurring pain and justifies a per-run flat fee.
Dogfooding — I use my own Google Maps actor to build lead lists I sell elsewhere. Every sale is also a demo.

Try them

All 11 actors are live on Apify Store. If you build agents, add https://mcp.apify.com to your MCP client and just ask for the data — the agent will find the tools.

Feedback, bugs, feature requests: open an issue on any actor page, I answer fast.

Lux Stay Agent — a hotel travel agent that only works because its content is structured

Jeffrey Turov — Fri, 18 Sep 2026 21:24:36 +0000

I run a real 3-star hotel next to Luxembourg's central station. For the Sanity Challenge, instead of building a demo on fake data, I pointed a production AI agent at a Sanity Knowledge Base filled with the hotel's actual operational content — live room prices, the real 54-dish snack menu, transport facts, multilingual FAQs. The result: Lux Stay Agent, a travel assistant that answers travelers' questions (FR/EN/DE) with exact figures it cannot afford to get wrong, and that would be completely useless without structured content.

Live demo (real recorded sessions): https://yasha.phoenix--ai.com/agent/
Sanity project ID: vxozr96i (dataset production)

The problem: answers a hotel can't get wrong

"How much is a double room?" sounds trivial until you realize the price changes daily (our rates sync with Booking.com every night). "How do I get from the airport?" has one correct answer (bus 29, free — Luxembourg made all public transport free in 2020). "What's on the menu?" is 54 items with individual prices living in the hotel's production ordering system.

A keyword search over a website gets you approximate, stale, or wrong answers. An LLM without grounding gets you confident nonsense. What works is an agent that queries structured content — exact fields, exact numbers — through a scoped, read-only window.

The Knowledge Base: 78 real documents

I modeled the hotel's world as six Sanity document types:

Type	Content	Why it must be structured
`hotel`	Address, phone, check-in/out times, distances (100 m to station, 400 m to center)	Exact facts, zero tolerance for approximation
`room`	3 types, capacity, bed, size, basePriceEur + price-sync note	A price is a number field, not prose
`menuItem`	54 dishes, category, priceEur, availability, ordering note	Pulled from the live ordering system (RoomEats)
`guide`	Airport/station/transport guides with `facts[]` arrays	Bus lines, durations, the free-transport rule
`faq`	FR/EN/DE questions & answers	The agent answers in the user's language
`attraction`	Sights with walkingMinutesFromHotel, UNESCO flags	"What can I visit on foot?" is a numeric query

Every document traces back to a real system: the booking engine I built for the hotel (rates synced nightly from Booking.com), the production QR-ordering database for the menu, and verified local transport facts.

Architecture: agent → Sanity Context MCP → Content Lake

Traveler question (FR/EN/DE)
        │
        ▼
Lux Stay Agent (Python, OpenAI-compatible LLM, function calling)
        │  1. fetches /initial-context over HTTP → schema-aware system prompt
        ▼
Sanity Context MCP endpoint
https://api.sanity.io/v2026-03-03/context/mcp/vxozr96i/production?embeddings=true
        │  tools: schema_explorer, groq_query, array_field_reader
        ▼
Sanity Content Lake — 78 real documents, embeddings enabled
        (semantic search via text::semanticSimilarity)

The agent loop is deliberately boring — that's the point. The intelligence lives in the content model:

def run_agent(question):
    tools = get_tools()  # MCP tools/list -> OpenAI function schemas
    messages = [
        {"role": "system", "content": SYSTEM.replace("{ctx}", initial_context_http())},
        {"role": "user", "content": question},
    ]
    for _ in range(MAX_ROUNDS):
        msg = llm(messages, tools)
        if not msg.get("tool_calls"):
            return msg["content"]           # grounded final answer
        for call in msg["tool_calls"]:
            result = mcp_tool(call["function"]["name"],
                              json.loads(call["function"]["arguments"]))
            messages.append({"role": "tool", "tool_call_id": call["id"],
                             "content": result})

The system prompt is strict: exact figures only via groq_query, never from memory; cite the source document type; if the base doesn't know, say so and hand over to the hotel's phone/email; answer in the user's language.

It only works because the content is structured

Three moments from real sessions:

"Combien coûte une nuit en chambre double et à quelle distance de la gare ?"
The agent fires one groq_query on room (basePriceEur: 95) and one on hotel (distanceToStationM: 100). A keyword search would find a page mentioning "double room" and "station" — it would not reliably bind 95 € to this room type on this date.

"Quels plats avec du kebab, et à quel prix ?"
The menu is 54 menuItem documents with name and priceEur as queryable fields. The agent answers with the exact list and prices — and surfaces the pricing contradiction honestly: each item carries the Wolt delivery price and the note that ordering in-room via QR is 15–25% cheaper. Both claims, with their sources, side by side — exactly what structured content enables.

"Was kostet ein Einzelzimmer und wie komme ich vom Flughafen zum Hotel?"
German question → German answer, because the FAQ documents are tagged language: "de", while the room price still comes from the language-neutral numeric field. Translation happens at the LLM layer; facts stay exact at the content layer.

Rigor: I tested the base before trusting the agent

Before writing the agent, I ran a 15-assertion QA battery against the Context MCP endpoint itself: schema visibility for all 6 types, exact price queries, reference resolution (room.hotel->name), document counts (54 menu items), guide facts, semantic search with embeddings, and multilingual retrieval. 15/15. Then a 5-question battery against the full agent loop (German, menu prices, UNESCO sights, English, free transport) asserting exact figures in the answers and actual tool usage. 5/5. The demo page replays these unedited sessions.

What I learned

/initial-context over HTTP is a real optimization: injecting the compressed schema into the system prompt saved a tool call per conversation and visibly improved the agent's GROQ accuracy on the first try.
Embeddings were one flag (embeddings=true) but needed enabling per-dataset (sanity datasets embeddings enable) — the error message was clear, the fix took a minute with the CLI once I had a token with the right grant (deploy-studio role for hosting, developer for embeddings).
Scope by default: the read-only token plus the Context endpoint's design meant I could point an agent at production hospitality data without ever risking a write. For a business dataset, that's the difference between "fun demo" and "deployable".
The hard part was never the agent — it was deciding what deserved to be a field. walkingMinutesFromHotel as a number turns "what can I visit?" into a sortable query. That modeling decision is the whole game.

Try it, read it, reuse it

Live demo with real session replays: https://yasha.phoenix--ai.com/agent/
The hotel's real booking site (the content source): https://yasha.phoenix--ai.com/
Sanity Studio: https://lux-stay-agent.sanity.studio/ (project vxozr96i)
Sanity Context docs: https://www.sanity.io/docs/ai/sanity-context

If you have content an agent can't afford to get wrong — prices, inventory, schedules, errata — structure it, scope it, and let the MCP endpoint do the rest. The agent is the easy part.

Your Actor should never see my credentials: the security case for MCP connectors

Jeffrey Turov — Thu, 17 Sep 2026 22:34:36 +0000

Every automation platform has the same dirty secret: the easiest way to connect a third-party service is to paste a token into an input field. It works on the first try. It is also how credentials end up in places nobody intended.

I learned this building lead-generation Actors on Apify. My first working version took a GitHub token as an Actor input. It shipped fast, and it was wrong. This piece is about the threat model behind that mistake, and how MCP connectors invert it: the Actor I run never sees a credential at all.

Everything below comes from real builds and real run logs, including the failures.

The threat model nobody writes down

Passing a service token as an Actor input creates three leak paths, and all three are boring:

Run logs. Inputs are echoed, logged, and retained. Anyone with whom you share a run (a teammate, a support ticket, a screenshot in a bug report) potentially shares the token with it.
Shared input JSON. Actors get cloned, forked, and re-run from saved inputs. A token inside an input object travels with every copy.
Third-party Actor code. The moment you run code you did not write (a Store Actor, a fork, a colleague's experiment), any credential you hand it is only as safe as that code's worst console.log.

Notice what these have in common: none of them require an attacker. The leak vector is the architecture itself. The token is simply in more places than it needs to be.

The inversion: credentials live with the connector, not the code

Apify's MCP connectors restructure where the secret sits:

You authorize the third-party service (GitHub, Notion, Slack) once, in Apify Console under Settings, Integrations. The OAuth credential is stored with the connector, on the platform side.
At run time, the Actor receives a connector ID: an opaque string like ebw4ThD4cQbEKzC2l. It is not a token, and it is useless outside the platform.
The Actor talks to the Apify MCP proxy at ${ACTOR_MCP_CONNECTOR_BASE_URL}/<connectorId>, authenticating with the run's own APIFY_TOKEN.
The proxy enforces the tool permissions the Actor declared in its input schema.

The practical consequence: you can publish the Actor's source, share its runs, and paste its input JSON into a forum. There is nothing in any of those artifacts worth stealing.

Least privilege is declared, not hoped for

The second half of the model is the mcpServers rule in the input schema. This is where the Actor states which tools it needs:

"githubConnector": {
  "title": "GitHub connector",
  "type": "string",
  "resourceType": "mcpConnector",
  "mcpServers": [
    {
      "url": "*",
      "tools": {
        "required": ["create_*", "push_*", "update_*", "write_*", "commit_*", "get_*"],
        "readOnly": false
      }
    }
  ]
}

Two layers constrain what the Actor can do: what the connector exposed at authorization time, and what the schema declares. The intersection is enforced by the proxy at run time, not by documentation.

Verified in a real run log. My Actor's schema used the declaration above. When it called list_tools() through the proxy, it saw exactly 7 tools: create_branch, create_or_update_file, create_pull_request, create_repository, push_files, update_pull_request, update_pull_request_branch. Nothing else existed as far as the Actor could tell. The constraint layer is not a promise on a marketing page; it is observable behavior.

The honest limits

A security argument that only lists strengths is marketing. Three limits I hit or verified:

1. The connector's tool set is frozen at authorization time. When you authorize a connector, the platform discovers the available tools once. If the upstream server later adds tools you want, you re-authorize. The set does not refresh itself. I lost time to this before reading it properly in the docs: it is "Layer 1" of their two-layer model, and it is by design (a silent expansion of your Actor's powers would be a security hole, not a feature).

2. The run still authenticates with a token: the starter's APIFY_TOKEN. The proxy trusts whoever started the run. That means access control moves to who can start your Actor with your connector, which is an Apify permissions question, not a code question. For Actors you share or publish, treat connector-enabled inputs as capability grants and review who can run what.

3. Connectors do not sanitize your payloads. The proxy enforces which tools the Actor calls, not what data flows through them. An Actor scraping personal data and pushing it to your repo is still your compliance problem. The connector solves credential custody, not data governance.

Pitfalls from real runs

Three failures I actually hit while building on this model, because they cost me runs:

SDK drift. The MCP Python SDK docs show streamable_http_client unpacking into three values (read, write, _). The version my Docker image installed yields two. ValueError: not enough values to unpack. Indexing the tuple (streams[0], streams[1]) works across versions. Same class of issue: the tool result error flag is result.is_error (snake_case), not the isError casing the TypeScript-flavored docs suggest.

Default branch assumptions. create_or_update_file failed with Branch main not found: my repo's default is master. The tool does not fall back to the repository default; it fails loudly, which is the correct behavior for a security boundary. Detect and retry with the other common name, or pass the branch explicitly.

Write-only connectors and the SHA problem. Updating an existing file on GitHub requires its current blob SHA. My write-scoped connector exposed no get_file_contents to fetch it. Rather than widening permissions, I switched the pipeline to immutable, timestamped snapshots: each run writes a new dated file, and Git itself becomes the history. The least-privilege constraint pushed me to a better design, which is what least privilege is supposed to do.

When to use what

Situation	Token as input	MCP connector
Local throwaway script, one run, you watch it	Fine	Overkill
Actor you will run on a schedule for weeks	Leak path	Right answer
Actor you publish or share	Irresponsible	Right answer
Running someone else's Actor with your services	Never	The only sane option

The last row is the one that convinced me. If you consume third-party Actors, connectors are the only way to grant access to your services where a sloppy or malicious print() cannot exfiltrate your credentials.

The takeaway

Security models for automation are usually about adding vigilance: rotate tokens, restrict scopes, audit logs. MCP connectors remove the attack surface instead: the credential never enters the Actor's world, so it cannot leak from it. You trade a small amount of convenience (one authorization step in Console, a frozen tool set) for the ability to share runs, publish source, and run untrusted code without a knot in your stomach.

The working example this article is drawn from is public: maps-to-stack on GitHub, and the build walkthrough with the scraping pitfalls is on dev.to. Connector documentation: docs.apify.com/integrations/mcp-connectors.

Build log details verified against run logs from August 2026: tool filtering (7 tools), branch fallback, SDK unpacking, and the immutable-snapshot pattern all occurred in real runs of the maps-to-stack Actor.

Your scraper forgets everything between runs. Here's a review monitor that doesn't.

Jeffrey Turov — Tue, 01 Sep 2026 17:55:54 +0000

Your scraper forgets everything between runs. Here's a review monitor that doesn't.

A scraper that pulls Google Maps reviews once is a toy. What businesses actually pay for is a monitor: "tell me the moment a bad review lands." The difference between the two is one unglamorous feature — remembering what you've already seen.

I built Review Radar, an Apify Actor that watches a list of Google Maps places, scrapes recent reviews on a schedule, and posts a Slack alert the moment a new review at or below your star threshold appears. The Slack side uses Apify's MCP connectors, so the Actor never touches a token. Everything below comes from real runs — including the two state bugs that almost shipped.

What we're building

Review Radar:

takes a list of Google Maps place URLs (or a search query),
scrapes the latest reviews of each place with Playwright,
diffs them against a persistent store of already-seen review IDs,
pushes only genuinely new reviews to the dataset, flagged isNew: true, and
posts a Slack alert for each new review at or below your threshold — via an MCP connector, so no Slack token ever enters the Actor's code.

Why Google Maps reviews? Because for hotels, restaurants, and local agencies, a 1-star review answered within an hour is recoverable; the same review discovered three weeks later is a lost customer. Review monitoring is a product businesses already pay monthly for — and the official Google Business API only covers businesses you own, not your competitors or your clients' portfolios.

The three parts that actually matter

Scraping the reviews panel

On a Maps place page, reviews live behind the "Avis"/"Reviews" tab. The extraction selectors that survived contact with production:

Review blocks: div[data-review-id] — with a trap I detail below
Author: div.d4r55
Rating: span.kvMYJc[role="img"] — parse the number from the aria-label ("4 étoiles" / "4 stars")
Text: span.wiI7pd
Relative date: span.rsqaWe

If no review block is visible on load, click the tab first: button[aria-label*="Avis"] or button[aria-label*="Reviews"]. Then scroll the panel (div.m6QErb.DxyBCb.kA9KIf.dS8AEf) until you have enough blocks. Google Maps requires a residential proxy — datacenter IPs get consent-walled or blocked outright.

State: the difference between a scraper and a monitor

The Actor keeps a named key-value store (review-radar-state) with one record per place: the set of review IDs already seen. Each run:

hashes each review to a stable ID (the native data-review-id when present, otherwise a SHA-1 of author+date+text),
flags isNew: true only for IDs not in the store,
persists the updated set at the end.

Proof from two consecutive real runs on the same restaurant. First run:

Cindy P. | 5★ | isNew=True
Raquel G. Urbano | 4★ | isNew=True
Chri Cou1967 | 5★ | isNew=True

Second run, minutes later, identical reviews:

Cindy P. | 5★ | isNew=False
Raquel G. Urbano | 4★ | isNew=False
Chri Cou1967 | 5★ | isNew=False

That False is the entire product. A scheduled run now only surfaces what changed.

Slack alerts without a token in sight

Same connector model as my previous build: the user authorizes Slack once in Apify Console → Settings → Integrations. The Actor declares the connector in its input schema and receives a connector ID at runtime — never a token:

"slackConnector": {
  "title": "Slack connector (optional)",
  "type": "string",
  "resourceType": "mcpConnector",
  "mcpServers": [
    { "url": "*", "tools": { "required": ["*message*", "*chat*", "*post*", "*send*"], "readOnly": false } }
  ]
}

The mcpServers declaration does double duty: it filters which connectors the picker offers, and the proxy refuses any tool call outside that list. At runtime the Actor lists the connector's actual tools and picks the first one matching post/chat/message/send, then formats the alert:

🚨 Nouvel avis 2★ sur *La Maison Lefèvre* (J. Dupont, il y a 2 jours)
Service décevant, attente de 40 minutes...
https://google.com/maps/place/...

Making the connector input optional ("required": []) was deliberate: without it, the Actor still produces the full dataset — which also makes the Actor testable without touching your Slack workspace.

The two bugs that almost shipped

Bug 1 — key-value store key charset. I keyed place records by the Maps feature ID (0x45d3f1...:0x...). Apify record keys only allow a-zA-Z0-9!-_.'() — the colon is illegal. The Actor scraped everything perfectly, then crashed on the very last line of the run. One regex fixed it, but it's exactly the class of bug that only appears after a full successful scrape:

place_key = re.sub(r"[^a-zA-Z0-9!\-_.'()]", "_", place_key)

Bug 2 — duplicated review blocks. Querying both div[data-review-id] and the legacy div.jftiEf.fontBodyMedium selector returns overlapping containers — the same review twice. My first test dataset had Cindy P. duplicated. Fix: dedupe by review ID inside the scrape loop, before anything reaches the dataset.

What I'd do differently at scale

Relative dates ("il y a 2 semaines") don't sort. For precise alerting windows, resolve them against the run date.
The Slack tool argument names vary by connector (text, message, content). I inspect the tool's input schema and map fields — brittle but workable until connector schemas stabilize.
Photos in reviews aren't extracted yet — for hospitality clients, a photo of a dirty room matters more than the text.

Try it

The Actor is review-radar on my Apify account. Inputs: place URLs (or a search query), reviews per place, star threshold, optional Slack connector. First run reports the existing batch as new; every run after that reports only what changed. Point a daily schedule at it and you have a review monitoring product for the cost of a few compute units.

A note on terms: Google Maps scraping sits uneasily with Google's ToS. Keep volumes polite (a handful of places, daily cadence), use a residential proxy, weigh the risk for production use, and prefer official sources where they cover your need — the Business Profile API works fine for businesses you own, it just can't watch anyone else's.

From scraper to stack: pushing Google Maps leads straight into GitHub with MCP connectors

Jeffrey Turov — Mon, 31 Aug 2026 23:39:38 +0000

From scraper to stack: pushing Google Maps leads straight into GitHub with MCP connectors
Every lead-generation pipeline I build ends the same way: a dataset full of freshly scraped businesses… that I then have to export, transform, and commit somewhere by hand. The scrape is automated; the last mile never is.
When Apify launched MCP connectors - a new kind of Actor input that lets Actors securely call third-party services like GitHub, Notion, or Slack during a run - I rebuilt that last mile. This article walks through a working Actor that scrapes businesses from Google Maps and commits the results straight into a GitHub repository, without the Actor code ever seeing a credential.
Everything below comes from a real build: the pitfalls are ones I actually hit, and the fixes are what actually solved them.

Full source code: Codeberg repository (canonical mirror, readable without an account). Also available as a source ZIP. The GitHub original at github.com/jeffreyturov-dev/apify-scraping-toolbox is currently unreachable for logged-out viewers (account-level restriction, under review with GitHub Trust & Safety) - use the mirror.
What we're building
Maps to Stack: an Actor that

takes a Google Maps search query (e.g. restaurants Esch-sur-Alzette),
scrapes each place page with Playwright (name, address, phone, website, rating, GPS),
pushes the results to the dataset, and
writes a JSON snapshot into your GitHub repo via an MCP connector - one commit per run, versioned by Git. Why GitHub as the destination? Because for lead-gen pipelines, a repo is a free CRM: versioned, diffable, and already wired into everything else (CI, dashboards, git-based CMSs). The same pattern works identically for Notion or Slack - only the connector changes. Prerequisites
An Apify account (the free plan works for testing this)
A GitHub account with a repository to write into, authorized as an MCP connector in Apify Console → Settings → Integrations (one OAuth flow, two clicks)
A residential proxy for the Google Maps scraping half - Maps blocks datacenter IPs outright. A note on terms: routing around Google's consent wall and IP blocks sits uneasily with Google Maps' Terms of Service. For production use you should weigh that risk, keep request volumes polite, and consider official sources such as the Places API where they cover your need; the residential proxy here is what makes the unoffical path technically reliable, not legally bulletproof.
Five minutes to read the Actor source top to bottom; it's intentionally small The security model that makes this interesting The classic way to do this is to pass a GitHub token as an Actor input. That means every run log, every shared input JSON, and every fork of your Actor is one leak away from a compromised token. MCP connectors invert this:
You authorize GitHub once in Apify Console → Settings → Integrations. The credential lives with the connector, not with your code.
At run time, the Actor receives a connector ID (a string like ebw4ThD4cQbEKzC2l) - not a token.
The Actor talks to the Apify MCP proxy at ${ACTOR_MCP_CONNECTOR_BASE_URL}/, authenticating with the run's own APIFY_TOKEN.
The proxy enforces the tool permissions your Actor declared in its input schema. The Actor physically cannot call tools outside its declaration. Declaring the connector input In .actor/INPUT_SCHEMA.json, set resourceType: "mcpConnector". The mcpServers rule list both filters which connectors the picker offers and caps which tools the proxy will let the Actor call: "githubConnector": { "title": "GitHub connector", "description": "MCP connector to your GitHub account. The Actor only sees a connector ID.", "type": "string", "resourceType": "mcpConnector", "mcpServers": [ { "url": "", "tools": { "required": ["create_", "push_", "update_", "write_", "commit_", "get_*"], "readOnly": false } } ] }

At run time the input value is just the connector ID string.
Verified in the run log: the proxy filtered the connector's tool list down to exactly what matched my declaration. My run saw 7 tools - create_branch, create_or_update_file, create_pull_request, create_repository, push_files, update_pull_request, update_pull_request_branch - and nothing else. The constraint layer works.
Connecting from the Actor (Python)
Two environment variables are injected into every run: ACTOR_MCP_CONNECTOR_BASE_URL (the proxy) and APIFY_TOKEN (the starter's token). You use the standard MCP Python SDK - nothing Apify-specific:
import os
import httpx
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client

base_url = os.environ["ACTOR_MCP_CONNECTOR_BASE_URL"]
token = os.environ["APIFY_TOKEN"]
proxy_url = f"{base_url}/{connector_id}"

async with httpx.AsyncClient(
headers={"Authorization": f"Bearer {token}"}
) as http:
async with streamable_http_client(proxy_url, http_client=http) as streams:
read, write = streams[0], streams[1]
async with ClientSession(read, write) as session:
await session.initialize()
tools = (await session.list_tools()).tools

(Import verified against the installed SDK: mcp.client.streamable_http exposes both streamable_http_client and the alias streamablehttp_client, so the line above runs as pasted; the docs showcase the alias, which is worth knowing given the drift discussed below.)
Pitfall #1 - SDK drift. The docs unpack streamable_http_client into three values (read, write, _), but the mcp version my image installed yields two. ValueError: not enough values to unpack (expected 3, got 2). Indexing the tuple (streams[0], streams[1]) works across versions. Same story for the result object: the error flag is result.is_error (snake_case), not isError - the docs' TypeScript casing leaks into expectations.
Writing the file - and surviving reality
With the session up, pick the file-writing tool from whatever the connector actually exposes (don't hard-code - the tool list is filtered by your schema and by what the server advertised at authorization time):
patterns = ["create_or_update_file", "push_files", "create_file", "update_file", "write_file"]
tool = next((t for p in patterns for t in tools if p in t.name), None)

owner, _, repo_name = actor_input["repo"].partition("/")
args = {
"owner": owner,
"repo": repo_name,
"path": actor_input.get("path", "leads/output.json"),
"content": payload_json,
"message": f"leads: {query} ({date.today()})",
"branch": actor_input.get("branch", "main"),
}
result = await session.call_tool(tool.name, arguments=args)

Two failures hit me immediately in real runs - both easy to fix once you see them:
Pitfall #2 - Branch main not found. My repo's default branch is master, not main. The MCP tool doesn't fall back to the repo's default; it fails loudly. Cheap robust fix: detect the failure and retry once with the other common branch name.
Pitfall #3 - File already exists… provide the current file's SHA. The second run collided with the first run's file. The GitHub API wants the blob SHA for updates - but the connector I authorized only exposes write tools (no get_file_contents to fetch the SHA). Instead of fighting it, I leaned into a better pattern for pipelines: immutable, timestamped snapshots. Every run writes a new dated file; Git itself becomes the history. If a read tool is available, the code uses the SHA path instead:
text = "".join(getattr(c, "text", "") for c in (result.content or []))
if "already exists" in text.lower():
get_tool = next((t for t in tools if "get_file_contents" in t.name), None)
if get_tool:
... # fetch sha, retry with args["sha"] = sha
else:
stamp = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ")
args["path"] = re.sub(r".json$", f"-{stamp}.json", args["path"])
result = await session.call_tool(tool.name, arguments=args)

Worth knowing: the connector's tool set is fixed at authorization time ("Layer 1" in the docs). If you authorize a connector and later wish it exposed more tools, re-authorize it - the discovered set doesn't refresh on its own.
The scraping side, briefly
The Maps half of the Actor uses Crawlee's PlaywrightCrawler with a residential proxy (Google blocks datacenter IPs outright). Three details that make it reliable, all learned the hard way on earlier Actors:

Kill the consent wall first. consent.google.com intercepts the first navigation; click "Accept" before waiting for any results selector.
Block heavy resources in a pre-navigation hook. The load event never fires on Maps (continuous analytics), so route-abort images/fonts/media, or every navigation times out.
Don't trust a green run. A SUCCEEDED run can still hold zero useful items - always assert on dataset item count and log per-item progress.
The first two are a few lines each, and they are the difference between an Actor that works and one that silently dies on every third navigation:
@crawler.pre_navigation_hook
async def optimize(context: PlaywrightCrawlingContext):
page = context.page
page.set_default_navigation_timeout(120_000)

async def _abort(route):
await route.abort()

The load event never fires on Maps (continuous analytics).

Without this, every navigation hits the navigation timeout.

await page.route(
"*/.{png,jpg,jpeg,gif,webp,svg,ico,woff,woff2,ttf,mp4,webm,avi}",
_abort,
)

@crawler.router.default_handler
async def search_handler(context: PlaywrightCrawlingContext):
page = context.page

# consent.google.com intercepts the first navigation.
# Click "Accept" before waiting for any results selector.
if "consent.google" in page.url:
    for sel in ('button[aria-label*="Accept"]',
                'button[aria-label*="Tout accepter"]',
                'button[aria-label*="Accepter"]',
                'form[action*="consent"] button'):
        btn = await page.query_selector(sel)
        if btn:
            await btn.click()
            await page.wait_for_timeout(2000)
            break

await page.wait_for_selector('div[role="feed"]', timeout=15000)

The full scraper is ~150 lines; the dataset holds one item per business with name, category, address, phone, website, rating, coordinates, and the Maps URL.
What a real run looks like
Input:
{
"query": "restaurants Esch-sur-Alzette",
"maxResults": 3,
"githubConnector": "ebw4ThD4cQbEKzC2l",
"repo": "jeffreyturov-dev/apify-scraping-toolbox",
"path": "leads/esch-restaurants.json"
}

Run log (abridged):
Scraped 3 businesses
Connector exposes 7 tools: ['create_branch', 'create_or_update_file', ...]
Using tool: create_or_update_file
Branch 'main' not found - retrying 'master'
Timestamped snapshot: leads/esch-restaurants-20260903T220554Z.json
Done - create_or_update_file wrote 3 leads

And the commit lands in GitHub with the full JSON: 3 businesses, ratings, phone numbers, coordinates - queryable, diffable, and already where the rest of my tooling lives.

Where this pattern earns its keep

Lead-gen pipelines: scrape on a schedule, each run commits a dated snapshot; a git log is your change history of who opened/closed in a neighborhood.
Any-to-any delivery: swap the connector for Notion (a database row per business) or Slack (a summary message) - the Actor code changes by a dozen lines; the security model stays identical.
Untrusted Actor code: if you consume third-party Actors, connectors are the only sane way to give them access to your services - the schema's tool constraints and the proxy's enforcement mean a malicious or sloppy Actor can't exceed its brief. Why the connector model is the only sane way to share access That last point deserves its own paragraph, because it generalizes beyond Apify. Every integration platform faces the same dilemma: users want automations that touch their GitHub, their CRM, their Slack - but handing a raw token to third-party code is an unacceptable blast radius. The connector pattern resolves it with three properties that are hard to get simultaneously any other way. First, mediation: every call passes through a proxy that authenticates the caller and authorizes the tool, so the credential is never exposed to the code that uses it. Second, declared least privilege: the input schema caps what the Actor may do, and the cap is enforced outside the Actor, where the Actor cannot rewrite it. Third, auditability: because calls flow through one chokepoint, every tool invocation is attributable to a specific run. Tokens in code give you none of these; connectors give you all three for the price of one OAuth flow. If you build or consume automations that touch shared services, this is the shape the access layer should have. Try it The Actor source (schema, scraper, connector logic) is intentionally small - read it top to bottom in five minutes. The moving parts that matter:
resourceType: "mcpConnector" in the input schema, with mcpServers tool constraints.
${ACTOR_MCP_CONNECTOR_BASE_URL}/ + APIFY_TOKEN bearer, via the stock MCP SDK.
Defensive write logic: branch fallback, SHA-if-available, timestamped snapshot otherwise. The connector model removes the part of pipeline building I liked least - sprinkling credentials through code - and replaces it with one authorization, one ID, and a proxy that keeps everyone honest.

Useful links: the Apify input schema reference, the pay-per-event monetization docs, the Apify MCP integration docs, and the Apify MCP server page.

I built 8 pay-per-use scraping APIs that AI agents can call directly (Google Maps, TikTok, Instagram, YouTube, LinkedIn) — here's what I learned

Jeffrey Turov — Tue, 28 Jul 2026 09:28:47 +0000

A few weeks ago I published a set of Actors on Apify Store. Today they're all AI-agent ready: any LLM agent (Claude, GPT, Cursor, LangChain, n8n) can discover and call them through the Apify MCP server — no custom integration code needed.

This post is the full playbook: what the tools do, how the pay-per-event monetization works, the bugs I hit, and how AI agents actually consume them.

The toolbox

Actor	What it extracts	Price (pay-per-event)
Google Maps Business Scraper	Names, phones, websites, ratings, reviews, GPS	$0.005 / business
TikTok Profile & Video Scraper	Followers, likes, bio, per-video stats	$0.01 / profile
Instagram Profile Scraper	Followers, bio, verified, engagement	$0.01 / profile
YouTube Video & Channel Scraper	Views, likes, subscribers, search results	$0.002 / video
LinkedIn Profile Scraper	Headlines, companies, skills, experience	$0.02 / profile
RAG Web Browser	Clean Markdown from any URL + Google search	$0.003 / page
Fuel Prices France API	Real-time prices, 9,800 stations, GPS	FREE
Hotel Rate Monitoring	Competitor rates, parity checks	FREE

The two free ones are deliberate lead magnets — more on that below.

Why "AI-agent ready" changes everything

The old model: a human finds your scraper on the store, reads the docs, clicks buttons.

For that to work, three things must be true:

Your README is written for an LLM, not just humans. Mine now all start with a "Use this tool when..." section — that's what the agent pattern-matches against the user's request.
Your input schema has a description on every field. The agent constructs the JSON input from those descriptions. No description = hallucinated parameters = failed runs = no revenue.
Your output is documented field by field. The agent needs to know what it gets back to reason over it.

Here's the actual flow with the Apify MCP server (https://mcp.apify.com — add it to Claude Desktop or Cursor in 30 seconds):

User: "Get me the follower counts of these 5 TikTok creators"
Agent: → search-actors("tiktok profile")
       → fetch-actor-details (reads README + input schema)
       → call-actor(travelmonitorlab/tiktok-scraper,
                    {"profiles": [...], "maxVideosPerProfile": 0})
       → returns structured JSON

Or skip MCP entirely — every actor is a single synchronous HTTP call:

curl -X POST "https://api.apify.com/v2/acts/travelmonitorlab~google-maps-scraper/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"queries": ["plumbers Austin TX"], "maxResults": 50}'

Monetization: pay-per-event (and the trap that cost me hours)

Apify offers several pricing models. For new actors, PRICE_PER_DATASET_ITEM is rejected — you must use PAY_PER_EVENT. The model is better anyway: you define events (e.g. business-scraped at $0.005) and charge explicitly in code:

await Actor.charge(event_name="business-scraped")
await Actor.push_data(item)

The trap: put the charge AFTER crawler.run() and your event loop may already be closed — the charge silently vanishes, you deliver data for free. Charge inside the handler, right before pushing data. Always verify with chargedEventCounts in the run object after a test run.

Setting pricing is pure API:

PUT /v2/acts/{actorId}
{"pricingInfos": [{
  "pricingModel": "PAY_PER_EVENT",
  "reasonForChange": "Launch pricing",
  "pricingPerEvent": {"actorChargeEvents": {
    "business-scraped": {
      "eventTitle": "Business scraped",
      "eventDescription": "One Google Maps business record",
      "eventPriceUsd": 0.005
    }}}}
]}

Apify takes 20%. Compute is paid by the user; you pocket the event fees.

Battle scars (so you don't get them)

Crawlee 1.8 breaking changes: purge_on_start and navigation_timeout_secs are no longer valid kwargs — use page.set_default_navigation_timeout() in a pre_navigation_hook.
Google Maps never fires load: analytics keep streaming forever, so navigation always times out. Fix: abort images/fonts/media via page.route() (the handler must be a coroutine, not a lambda).
Residential proxies are mandatory for Google Maps, and you must pass actor_proxy_input= as a named argument to Actor.create_proxy_configuration().
French number formats will crash your floats: "4,8" → replace comma; "1 234" reviews can use \xa0 or \u202f as thousand separator.
A "SUCCEEDED" run can contain zero useful data. Always check itemCount + sample the dataset + read the end of the log.
Don't run 7 queries × 25 results in one run. Split into parallel runs of ≤5 queries × 15 results; retry failed ones sequentially (residential proxy tunnels occasionally die).

The distribution strategy

Publishing on the store is step 0. What actually moves the needle:

Free lead magnets — the fuel-price and hotel-rate actors are 100% free. Free tools get users, ratings, and store ranking; ranked actors surface in MCP search results; MCP visibility drives paying users to the paid actors.
README written for LLMs — agents choose tools whose docs they can parse. Clear "use when", typed inputs, example I/O.
Niche SEO titles — "Google Maps Scraper" is saturated; "Fuel Prices France API" has zero competition on the store.
Dogfooding — I use my own Google Maps actor to build lead lists I sell elsewhere. Every sale is also a demo.

Try them

All 8 actors are live on Apify Store. If you build agents, add https://mcp.apify.com to your MCP client and just ask for the data — the agent will find the tools.

Feedback, bugs, feature requests: open an issue on any actor page, I answer fast.

DEV Community: Jeffrey Turov

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

What happens next Sunday

Built with

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

Who it's for

What it does

Demo (real run)

Why open innovation matters here

Try it

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

TL;DR

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

2. The sovereign stack

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

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

5. What we actually learned (the publishable part)

6. Reproducibility

7. Limitations

I benchmarked what frontier models actually know about 2026 — most of it, they don't

The itch

The benchmark: Post-Cutoff Knowledge 150

What I ran it against

What surprised me

Honest limits

What's next

I built 11 pay-per-use data APIs that AI agents can call directly (Google Maps, TikTok, LinkedIn, review monitoring) — here's what I learned

The toolbox

Why "AI-agent ready" changes everything

Monetization: pay-per-event (and the trap that cost me real money)

The QA gauntlet (or: your actor must survive an empty input)

Battle scars (so you don't get them)

The distribution strategy

Try them

Lux Stay Agent — a hotel travel agent that only works because its content is structured

The problem: answers a hotel can't get wrong

The Knowledge Base: 78 real documents

Architecture: agent → Sanity Context MCP → Content Lake

It only works because the content is structured

Rigor: I tested the base before trusting the agent

What I learned

Try it, read it, reuse it

Your Actor should never see my credentials: the security case for MCP connectors

The threat model nobody writes down

The inversion: credentials live with the connector, not the code

Least privilege is declared, not hoped for

The honest limits

Pitfalls from real runs

When to use what

The takeaway

Your scraper forgets everything between runs. Here's a review monitor that doesn't.

From scraper to stack: pushing Google Maps leads straight into GitHub with MCP connectors

The load event never fires on Maps (continuous analytics).

Without this, every navigation hits the navigation timeout.

I built 8 pay-per-use scraping APIs that AI agents can call directly (Google Maps, TikTok, Instagram, YouTube, LinkedIn) — here's what I learned

The toolbox

Why "AI-agent ready" changes everything