Why I track every AI quota reset announcement (and why the site has no admin panel)

A developer built Alca, a read-only, anonymous site that compares AI model access, pricing, free quotas and rate limits across providers, with a dated reset log linking each announced quota or limit change back to its original source post. All content lives as typed TypeScript files in a repo — models.ts, offers.ts and codexResets.ts — where edits arrive as pull requests and CI enforces referential integrity before deploy, with no admin panel, CMS or public database. The reset feed regenerates roughly hourly from a public API, and feedback submissions are pulled from a queue by an outbound-only agent using at-least-once delivery.

This month my Codex plan hit 0% for the third time, and each time I found out the reset schedule had quietly moved. I was the kind of person who kept screenshots of the docs in a notes app, but the docs never said when an announced reset actually landed, or which tier was on which clock. So I stopped taking notes and started building a log instead. That log became Alca https://alca-navy.vercel.app/en/models : a read-only, anonymous, no-signup site comparing AI model access, pricing, free quotas and rate limits across providers. The part I use most is the reset log: a dated list of every announced reset and limit change, each entry linked back to the original post. All the content is typed TypeScript files in a repo: models.ts , offers.ts , codexResets.ts . A "content editor" is just a pull request. I edit a file, CI checks referential integrity an offer can't reference a model slug that doesn't exist, every URL must be http/https, slugs are unique , and the change deploys. No admin panel, no database for public data, no CMS. I chose that on purpose. When a row says some provider's free tier gets you X requests a day, I want to be able to point at exactly where that came from. Every row carries a verification status : verified means I checked a source link, and I paste it in. unverified means "this is a placeholder, replace me." Showing the honesty level of the data beats hiding it behind a clean table. The reset feed regenerates about hourly from a public API: fetch, validate, typecheck and test, commit only when the data actually changed, push, and the deploy happens. The upstream blocks datacenter IPs, so it runs on a consumer machine, with a manual workflow as the backup. "Watch" entries — forecasts, not confirmed events — are clearly marked unconfirmed . The site has a feedback form, but I didn't want it pointing at a personal email address. Submissions pass size and rate checks, then sit in a queue that an outbound-only agent I run pulls from: it heartbeats, leases up to 20 items, saves them durably, and acks idempotently. Expired leases get redelivered. In practice: at-least-once delivery, no browser-visible tracking of visitors. Is "linked back to the original post" actually useful to anyone besides me? Do you cross-check a claim against its source, or just trust the table? I keep the links because a stale limit number cost me a week of guessing once. A dated, cited reset log turns a schedule change from a rumor into an event. The site is at https://alca-navy.vercel.app/en/models https://alca-navy.vercel.app/en/models . There's a feedback form, and a public JSON API under /api/v1 if you want the data instead of the pages.