# Usage and allowances Usage comes in two shapes: daily counters that reset at midnight UTC, and ceilings on how many of a thing may exist at once. A daily counter is reserved before the work happens and inside the same transaction, which is what makes a limit hold when several requests arrive together. Some events are counted and never refused — an inbound customer message is one of them. - **Status:** Available - **Audience:** both - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/account/usage/ ## Counters and ceilings A daily counter answers *how many times today*; a ceiling answers *how many at once*. They are enforced in different places and they recover differently — a counter frees itself at midnight, a ceiling frees only when you remove something. | Shape | Resets | Counts things like | |---|---|---| | Daily counter | Midnight UTC, which is 05:30 IST | Outbound emails, inbound mail ingested, model calls made for the workspace, WhatsApp messages by category | | Resource ceiling | Never on its own; it frees when you disconnect or delete | Connected mailboxes, personal Gmail slots, business-domain mailbox slots | WhatsApp is metered as three separate counters rather than one, because the provider prices a free-form reply inside the service window, a utility template and a marketing template as different things. One combined allowance would either waste the cheap category or starve it to protect the expensive one. ## Reserved before, not counted after The reservation happens first, in the same database transaction as the work, and any call to a provider happens only after that reservation is durable. The increment itself is a conditional update that succeeds only while the new total stays inside the limit, so two requests arriving at the same moment cannot both be told they are the fifth send of the day. 1. The work is prepared — a reply drafted, a message ready to hand over. - Result: Nothing has been counted and nothing has left the building yet. 2. Today's counter is claimed if it does not exist, then incremented conditionally. - Result: If the increment would cross the limit it matches nothing, and the answer is that today's allowance is spent and resets at midnight UTC. 3. The transaction commits, and only then is the provider called. - Result: A crash between the two costs one unit of allowance, never a duplicate message. That is the trade this ordering makes on purpose. 4. Work that could not proceed is held. - Result: It appears in Needs You as a refusal rather than disappearing. For mail, the read cursor deliberately does not advance either. > **Careful** A refusal on an allowance must never advance a read cursor. Advancing it is how a mail agent loses messages permanently: the allowance returns tomorrow, but the mail it skipped does not come round again. ## Counted but never refused Not every dimension is a gate. An inbound WhatsApp message from a customer is counted for reporting and then processed regardless of the number, because the message costs nothing at the provider and dropping it would lose a real person's enquiry to protect nothing. The registry records that decision against the dimension, with the reason, rather than leaving it as an accident of where the check happened to be written. The same registry marks dimensions nothing can consume yet. If a usage view shows a row that never moves, check its status before treating it as a fault — [Entitlements and runtime choice](/docs/account/entitlements/) lists the three. ## Reading your own usage - Usage is per workspace and per day, keyed by dimension: what was used, and what the limit was at the time it was used. - The limit is stored beside the count, so a plan change part-way through a day does not rewrite the history of what was allowed earlier. - The Owner workspace is marked unlimited: counts are still recorded, but no limit is applied to them. - A reservation that is later abandoned is released, so a failed hand-off does not quietly eat the day's allowance. What usage does **not** tell you is model spend. Money-side control for AI work is a separate budget with its own guard; usage answers *how many*, the budget answers *how much*. ## When the number looks wrong **The count jumped by more than you sent** — One action can consume more than one unit — a reply to several recipients, or a retry after an uncertain hand-off that later resolved. **The count is lower than the messages you can see** — Inbound and outbound are different dimensions, and a message Connect only drafted was never sent, so nothing was counted for it. **The limit changed mid-day** — A plan change takes effect immediately. Earlier rows keep the limit that applied when they were written. **Everything stops at once, across channels** — That is the plan gate rather than a single counter. See [When a plan lapses](/docs/account/lapsed-plan/). ## Questions ### When exactly does a daily allowance reset? At midnight UTC, which is 05:30 in India. The date used for counting is the UTC date, so a workspace working late in IST crosses into a fresh allowance in the early morning rather than at local midnight. ### If a send fails, do I lose the allowance? A reservation that is abandoned is released back. What you can lose is one unit in the narrow window where the reservation committed and the process stopped before the provider was called — that ordering is chosen deliberately, because the alternative risks sending the same message twice. ### Are inbound messages counted against me? Inbound mail that is ingested is a counted, enforced dimension. Inbound WhatsApp is counted for reporting only and is never refused. The registry states which is which, and the reason, rather than leaving it to be inferred. ## Related - [Entitlements and runtime choice](https://connectbyjbrh.com/docs/account/entitlements/) - [Your plan](https://connectbyjbrh.com/docs/account/plan/) - [The allowance is spent](https://connectbyjbrh.com/docs/troubleshooting/allowance-reached/) - [Metering usage, end to end](https://connectbyjbrh.com/docs/workflows/usage-metering/) - [Allowance](https://connectbyjbrh.com/docs/glossary/allowance/) - [Autonomy and spend](https://connectbyjbrh.com/docs/autonomy/spend-context/) ## What this page is based on - `backend/app/metering.py` — the dimension registry, kinds and statuses - `backend/app/tenant_entitlements.py` — reservation, release and the reset rule - docs-source/sources/CHANNELS.md section 1 — the daily allowance and the read cursor - Connect capability registry (docs-source/facts.py)