Zero-Budget AI Apps Work Best as Self-Feeding Sites, Not Open Tools
If you build AI features alone and can’t afford a surprise bill, the model you pick matters less than where it runs and who triggers it. Get those two right and inference costs nothing or close to it. Get them wrong and a free tier runs dry by lunch, or a paid API quietly eats your month.
What follows is the reasoning I’d give any solo builder, worked out the long way: by throwing ideas at the wall and watching most of them fail one test or another.
Five places a model can run
There are five rungs, and each one moves the cost to a different payer.
| Where it runs | Typical model size | Who pays | Good for |
|---|---|---|---|
| The visitor’s browser | Under about 2 billion parameters | The visitor’s device | Detection, OCR, transcription, matching, tagging |
| A local app on the user’s machine (Ollama, LM Studio, llama.cpp) | 7 to 30 billion | The user’s hardware | Real summaries and document reasoning, if they’ll install something |
| Free cloud tiers (Groq, Cloudflare Workers AI) | 8 to 70 billion | The provider, up to a daily cap | Good quality, rate-limited |
| Your own rented GPU | 70 billion and up | You, by the hour | Rarely worth it for a side project |
| Frontier APIs (Claude, GPT) | The largest | You, by the token | Best judgment and writing |
The browser rung is the purest zero-cost option, and I’ve written up the full setup in How to Ship In-Browser AI Apps With No Server and No Inference Bill. A local app is the same idea with ten times the model, at the price of an install. A page can even check for a local runtime and use it when present, falling back to the in-browser model when not.
Why the obvious ideas keep failing
Three filters killed most of what I came up with.
First, the hosted chatbots already do it. A tool that captions a photo, summarizes a PDF or answers a question one upload at a time will always lose to Claude or ChatGPT in a chat window. Your free-tier version is the worse copy.
Second, it’s an integration problem. A pipeline that moves files from cloud storage to a model and back is wiring. Connectors already do that, and wiring isn’t a product.
Third, it’s a dashboard. Fetch a few public APIs, merge, display. Anyone can build it, and nothing on the screen is a finding. Fusing data only becomes interesting when the combination shows something no single source does: a change, a contradiction, an early signal.
What survives all three is narrow: work on inputs people won’t upload, or work that reads large amounts of public data nobody has time to read and pulls out what changed.
The free tier trap and the way out
A public AI tool on a free tier has a structural flaw. The daily allowance is shared by every visitor, so one busy afternoon drains it. You can rate-limit per visitor, add a captcha, fall back to a second provider. You’re still rationing.
Flip it around. Don’t run an open tool at all. Run the model on your own schedule against public data, publish what it finds as static pages, and let unlimited readers read them for free. Compute once, serve many. The free quota is now spent only by you, on a predictable batch.
That’s a self-feeding site. A scheduled job wakes up nightly, fetches new filings, contract awards, patents or official statements, finds what’s new, asks a model to label and explain it, writes posts and commits them to the site’s repo. The static host rebuilds and publishes. Nobody touches it.
The engine for this is a scheduled GitHub Actions workflow, not a Cloudflare Worker. Worker CPU time on the free plan is too tight for parsing long documents. An Actions job can run for hours, it’s free on public repos, and private repos get 2,000 minutes a month.
The model doesn’t run inside Actions in the usual setup. The job calls it over HTTPS like any web API, with the key stored as an encrypted repo secret. The split matters:
- The job is the clock and the hands. It fetches, diffs, writes files and commits.
- The model handles only the judgment step in the middle: read this, label it, explain it in one sentence, answer in JSON.
- Your code is the guard rail. It validates the JSON, checks every quoted string actually exists in the source, and holds back anything that fails.
Groq or Cloudflare for the free model
For long documents, Groq wins. As of mid-2026 its free tier offers larger open models such as Llama 3.3 70B, around 1,000 requests a day, a 128K context window and very fast responses. Cloudflare Workers AI gives about 10,000 “neurons” a day, a compute unit whose value depends on the model, with smaller context on many of its free models. Its strengths are variety (embeddings, speech-to-text, image models) and the fact that it’s already in your Cloudflare account. Use it as the fallback. Free-tier limits change often, so check them before you build.
When the paid API is the cheaper answer
The fear with paid APIs is spiral cost. That fear belongs to open tools, where visitors trigger calls. A self-feeding site processes a fixed volume you choose, so the bill is predictable from day one. Both providers bill against prepaid credit, and both have consoles for tracking and limiting spend.
The numbers are small. Claude’s official API prices per million tokens in October 2026:
| Model | Input | Output |
|---|---|---|
| Opus 5.5 | $4 | $20 |
| Sonnet 5.5 | $2 | $10 |
| Haiku 5.5 (prompts up to 100K tokens) | $0.10 | $0.50 |
Batch processing halves those, and a nightly job doesn’t care about waiting a few hours. A hundred press releases a day through Haiku is roughly 30 million input tokens a year: about $3. Comparing two years of risk factors for 50 public companies is about 3 million tokens a year, a few dollars even on Sonnet.
What you buy with that money is real. A frontier model reads a whole document in one call instead of paragraph pairs, notices a warning softened from “may” to “could”, returns valid JSON far more often and writes something a reader would actually finish. The practical split is a hybrid: free or small models filter and tag the bulk, and the paid model writes up only the handful of findings that become posts.
The closed version with small models only
You can also skip outside services entirely. The same small ONNX models from the browser setup run fine in Node or Python on a GitHub runner, which has about 4 CPU cores and 16 GB of memory and no GPU. No API key, no quota, and if you pin the model version, the same input produces the same output every time.
What changes is the writing. Small models are weak at rephrasing anything longer than a couple of sentences. They change numbers, swap names, lead with boilerplate and slip into the same bland register every time. So in a closed pipeline the model writes almost nothing. Code extracts the facts, small models classify, tag, match and group, and the post is assembled from a template around verbatim quotes and verified fields. The output reads like a structured brief. For data-heavy subjects that’s exactly what readers want.
Take a risk factor tracker for public companies. Downloading filings, cutting out the risk section and diffing paragraphs is plain code. Matching reworded paragraphs is an embeddings job, which small models do well. Topic tagging is a classifier, also fine. Judging whether a warning got stronger or weaker is where a small model gets shaky, and explaining why it matters is beyond it. Yet the most valuable output, the exact new sentences next to last year’s text, needs no model at all.
What small models can write passably
The rule is simple. Code supplies every fact, the model phrases small pieces, and a check confirms every number and name in the output exists in the input.
Inside that rule, small models handle:
- Data briefs from structured fields, the kind of automated earnings or contract story news agencies have run for years
- Event listings built from name, date, venue and host
- Link roundups with one line per item from an RSS feed
- Captions, alt text and tags for images
- Translations of headlines and short summaries
- Extractive summaries and FAQs that reuse the source’s own sentences
- One-line commentary on a chart whose numbers code already computed
They fail at opinion, analysis, reviews, explainers, anything longer than a few paragraphs, anything needing world knowledge they’d have to invent, and anything with a voice.
One more filter applies to all of it. Search engines treat mass-produced pages that add nothing as spam, and a rewritten press release is the textbook case. Every page a self-feeding site publishes has to carry a finding from the data. If a run finds nothing new, it should publish nothing.
That’s the whole approach in one line: pick the rung by who should pay, run the model on your schedule instead of the visitor’s, and let code own the facts.