Why Audit Before Claiming

Most people, after getting free quota on an aggregator, immediately fire a few requests to burn it down. Two weeks later the bill shows a list of model names and numbers, and nobody can say which quota came from which upstream, which key can still be renewed, or which has already expired.

The value of an aggregator is not "one more free entry point" — it is that it collapses multiple upstream quotas into one set of keys and one billing surface. That lets you do something an official console cannot: fingerprint each quota and keep a ledger.

Steps

Step 1: Build a quota ledger

Create a table (Notion, Airtable, or a local CSV) with fixed columns:

  • Source: upstream vendor name (aggregator's built-in free model pool, platform trial credit, forwarded official free tier)
  • Model ID: the model identifier you actually call on the gateway, not the upstream's original name
  • Rate-limit fingerprint: RPM / TPM / concurrency cap / daily cap, measured, not as written on the page
  • Expiry condition: time-based, usage-based, or account-state-based
  • Renewability: can it be renewed via check-in, referral, or periodic reset
  • Current balance: read from the gateway's usage page

This table drives every later decision. Build it before you call anything.

Step 2: Probe the rate-limit fingerprint

Documented limits often differ from real ones, especially when the aggregator applies a second layer of throttling. Do this:

  1. Send a small batch of tiny requests (e.g. 10 requests of a few dozen tokens each) and record where 429 appears;
  2. Increase gradually until throttling triggers, note the requests-per-minute at that point;
  3. Wait a minute and retry to determine whether the window is sliding or fixed;
  4. Write the measured values into the fingerprint column.

This costs a few dozen tiny calls — negligible — but determines whether you can schedule the quota into automation later.

Step 3: Check model mappings for "same name, different source"

Aggregators often use aliases to pool same-named models from multiple upstreams. One alias may route to different upstreams at different times, with different billing and limits.

Audit method: read the upstream identifier from the response (most gateways include a provider field in headers or body), sample a few dozen calls, and see how many sources sit behind the alias and in what proportion. Record the alias-to-upstream mapping in the ledger's Model ID column.

Step 4: Sort quotas into three tiers by renewability

  • Keep alive: periodic reset or stable free pool — bind to daily light tasks (summaries, classification, embeddings);
  • Burn once: trial credits that expire — schedule for batch offline jobs and run to completion;
  • Watch: unstable fingerprints or frequently switching upstreams — keep out of automation, manual testing only.

Step 5: Monthly expiry patrol

Pick a fixed date (e.g. the 1st) and walk the ledger row by row: balance, expiry condition, whether the upstream still exists. Aggregator upstreams change; a free pool can silently disappear, and an unaudited ledger drifts out of truth.

Caveats

  • Don't stress-test with probes: the goal is recording fingerprints, not maxing out quota. Heavy concurrent probing can trigger account risk controls.
  • Don't log numbers only: "how much is left" is meaningless without source and limits — you can't reuse it.
  • Alias mappings drift: after a routing change, old fingerprints may be invalid; re-sample during patrol.
  • Distinguish platform grants from forwarded upstream free tiers: the former follows platform rules, the latter upstream rules — different expiry logic.
  • Don't turn the audit script into high-frequency polling: low-frequency, small-batch sampling is enough.

When this fits

  • Indie developers with several aggregator accounts and mixed quota sources;
  • Small teams wanting to schedule free quota into cron jobs (daily summaries, content classification, batch embeddings);
  • Technical evaluation stages deciding whether a gateway's free pool is worth long-term reliance;
  • Anyone who has been burned by "quota vanished and nobody knows why" and wants traceability.

How this differs from other routes

This route does not chase one more claim — it makes what you already have legible. Once the audit is done, signup credits, fallback routing, or periodic claiming all become more targeted, because you know which quota is worth renewing and which to drop.