Costs and quotas

Watcher is designed to run at zero recurring cost for personal use. That only holds if you understand what each run consumes.

What one run costs

Outcome	Model calls	Search credits
nothing-new	0	1 per search source
not-triggered	1 or more (one per chunk of new items)	1 per search source
notified	1+ evaluation, plus 1 second opinion, plus 1 embedding	1 per search source
already-notified / semantic-duplicate	1+ evaluation, plus dedup work	1 per search source
Redelivery of a queued alert	0	0

Quiet runs are nearly free

Content deduplication happens before the model is called, so a watch on an unchanged page costs one fetch and nothing else. This is the single most important cost property of the design: most runs are nothing-new.

The expensive combination is a busy source with frequent genuinely-new content — each new batch is at least one model call.

What runs out first

Roughly in the order people hit them:

1. Model requests per minute. Free tiers cap requests per minute and per day. Watcher processes watches sequentially by default precisely to stay under those caps. Symptom: cooldowns and rotation in the key status screen.

2. Search credits. Every search source spends a credit per run, whether or not anything is found. Ten search sources checked hourly is 7,200 credits a month — easily more than a free tier allows. Symptom: search sources start failing.

3. CI minutes. A run that installs dependencies and executes costs a couple of minutes. Hourly is roughly 1,500 minutes a month.

4. Database storage. Run history and seen-content lists grow indefinitely. Slow, but it never shrinks by itself.

Reducing consumption

Lever	Effect
Slow the schedule	Linear reduction in everything
Prefer rss and page over search	Removes search credits entirely
Fewer sources per watch	Fewer fetches and less content to evaluate
Merge overlapping watches	Two watches on one subject cost twice
Disable watches you no longer read	The commonest source of waste
Add a second key	Does not reduce usage, but raises the ceiling through rotation

Watching your usage

GET /admin/keys shows, per key: live status, today’s requests against the slot’s configured limit, and a 30-day series.

Note

These are Watcher’s own counts of the calls it made — an estimate, not a provider bill. They are the right tool for “which pool is under pressure”, not for accounting.

Storage growth

Collection	Behaviour
key_usage	Expires automatically after about 90 days
run_history	No automatic retention — grows with every run
run_state	Seen-content lists are append-only

For a handful of watches this is negligible for years. If you run many watches at high frequency, plan to prune old run history periodically.

When a limit is hit

Watcher degrades rather than breaking:

• A rate-limited key cools down and the pool rotates.
• If the primary model is exhausted, the second-opinion model can produce the verdict — capped at the weak tier.
• A search failure is a source failure: the watch continues with its other sources.
• Only when a pool is entirely exhausted does the run fail, loudly.

See Model and quota errors.