Credits and token packs
RaceTagger runs on tokens, not a subscription: you buy a token pack and spend tokens to analyze photos — no monthly fee, and a balance never expires. A standard photo analysis costs 1 token; enabling Visual Tagging on a batch adds +0.5 token per image (1.5 total). Before a batch starts, the app reserves the tokens it expects to need; when the batch ends it settles the reservation to the tokens actually used and refunds the rest. Your balance is always visible in the app.
How to use it
- 1Your remaining balance is shown in the header, in the token balance widget (🪙 icon, "images remaining"), and on the…: Settings page under Account & Profile → Analyses Remaining.
- 2Start an analysis as usual: The app calculates the tokens the batch needs (image count, plus +0.5/image if Visual Tagging is on) and reserves them before processing begins.
- 3If the balance is not enough, the batch does not start and you see an "Insufficient tokens" message with how many you…: have and how many the batch needs.
- 4When the batch finishes (or is cancelled), the reservation is settled: tokens are consumed for what was actually…: processed and any unused reservation is refunded automatically.
- 5To buy more tokens, click Buy more (Settings) or Buy more analyses (header widget), or View Pricing & Buy Tokens → on…: the pricing screen — these open racetagger.cloud/pricing in your browser for checkout. See racetagger.cloud/pricing for current pack sizes and prices.
Limits and known behaviour
- A device flagged on the admin blacklist is refused a reservation regardless of balance ("This device has been blocked from running analyses…"); this is a separate check from having enough tokens.
- Folder organization and metadata writing do not consume tokens (per the public pricing page on racetagger.cloud).
- A reservation has a TTL decided server-side (returned by the
pre_authorize_tokensRPC). If a batch is still running when its reservation lapses (e.g. the laptop slept through it), a server-side cron auto-finalizes the reservation on the partial count already logged — the app does not treat reservation expiry as proof the run is dead, since a genuinely live run can outlive its own TTL. - If the app cannot prove locally that a run was interrupted (different device, reinstall, deleted local log), it does not touch that run's DB status from a stale reservation; it is only ever shown as "Interrupted" in the UI, never force-failed from reservation state.