Something slipped into the Gemini API that I don't think enough people clocked: you can run a prompt in the background. You send it, get an interaction ID back in under a second, and the model keeps working server-side while you close your laptop. No held-open connection, no keeping a tab alive.
And on the free tier — gemini-3.1-flash-lite, no billing account, no card — it costs nothing.
That combination is quietly great for one specific thing: research you don't need answered right now. "Summarize this week in AI." "Compare the 2026 EU AI Act timeline against the UK's." "Is anyone actually regretting moving off Postgres?" Questions where you'd happily wait a few minutes, if waiting meant you didn't have to sit there babysitting a terminal.
The problem is the background API hands you the hard half. You get an ID back and now it's yours to manage: remember which prompt it belonged to, poll it, and — the sharp edge — the free tier throws the result away after 24 hours if nothing collects it. Lose the ID or forget to check, and the work is just gone.
So I built the boring client half and called it gemcatch.
npx gemcatch research "compare the 2026 EU AI Act timeline against the UK approach"
# Task 8f3a1c04 submitted. Run: gemcatch get 8f3a1c04 when ready.
# ...close the laptop, come back whenever...
npx gemcatch get 8f3a1c04
It drops every interaction ID into a local SQLite file right next to the prompt that made it, so you never lose the thread. The moment a task finishes, the answer is cached on disk — gemcatch get reads it straight from there, no network, even after the 24-hour server-side expiry.
The part I actually use: batch
One prompt at a time is fine. The reason gemcatch earned a permanent spot in my shell is the batch command. I keep a plain text file of questions and fire the whole thing at once:
$ cat questions.txt
what changed in the EU AI Act in the last month
state of React Server Components adoption in production
is anyone regretting moving off Postgres to a managed KV
$ gemcatch batch questions.txt
Batch batch-7f3a1c: submitted 3 task(s).
$ gemcatch daemon --exit-when-idle # poll until they're all collected
$ gemcatch export --tag batch-7f3a1c > answers.md # every answer, one markdown file
I run that before bed. By morning answers.md is waiting — every prompt and its answer in a single file, ready to read with coffee. And when I want the takeaways instead of the raw pile, gemcatch digest --tag batch-7f3a1c runs them back through the model once and hands me one synthesized summary. It's the closest thing I've got to a research intern who works the night shift for free.
The daemon exists for exactly one reason
That 24-hour expiry is the whole gotcha. Caching a result forever is easy; noticing it landed is the hard part. gemcatch daemon just polls whatever's in flight on a loop and writes each result to SQLite the instant it completes — so nothing gets dropped because you forgot to check back. Kill it, reboot, pull the power; everything it already collected is on disk, and it picks up where it left off.
It's deliberately boring
No dashboard, no account, no telemetry. It's a small pile of Node, a SQLite file, and a handful of commands — research, batch, get, list, watch, daemon, export, digest. Every outbound call is rate-limited and retried so a wide batch stays inside the free tier's limits instead of blowing straight through them. MIT.
npx gemcatch research "your question"
Repo: github.com/Booyaka101/gemcatch
If "ask now, read later, pay nothing" fits how you actually work, I'd love to know what you'd point it at — and what would make the batch flow better. Scheduled/recurring runs are the thing I'm eyeing next.
Top comments (0)