# The allowance is spent

One counter is spent, not all of them. Each metered dimension has its own daily number, so reaching the sending limit stops sending and leaves ingest and everything else alone. The work that could not proceed is held rather than discarded, it appears in Needs You as a refusal, and the counter resets at midnight UTC — 05:30 IST.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/allowance-reached/

## What you see

A message saying today's limit has been reached, naming the reset. On the engine side it is quieter: replies stop leaving, Needs You gains entries explaining why, and a workspace that was busy at ten is still at noon.

It is not an error and it is not a fault. It is the plan doing what the plan says, at the exact moment it was configured to.

## What keeps going

| Activity | State | Why |
|---|---|---|
| Reading, searching, reviewing | Normal | Nothing about reading is metered |
| Fetching new mail | Normal, until its own counter is spent | Ingest is a separate dimension with a separate number |
| Drafting | Normal, until the model-work counter is spent | Model calls made for the workspace are metered in their own right |
| Sending | Stopped | This is the counter that was reached |
| Inbound WhatsApp | Normal | Counted for reporting and never refused — dropping a customer's message would protect nothing |
| Suppression and do-not-contact | Enforced as ever | A limit never relaxes a compliance rule |

This is why the symptom rarely looks like a wall. One thing stops and the rest carries on, which is deliberate: a workspace at its send limit should still be collecting mail, still triaging, and still ready to go the moment it can.

## What Connect completed, and what it did not

**Completed** — Everything reserved before the limit was reached. A reservation succeeds or it does not; there is no partial send.
**Not completed** — The action that was refused. It was held, not dropped — the draft still exists, still attached to the message it answers.
**Not advanced** — The mail read cursor, where the refusal was on ingest. Nothing at the provider was skipped, so the gap is collected on the next successful sync.
**Not lost** — Nothing. A spent allowance costs you time and never a message.

> **Careful** Advancing a read cursor past mail that was refused is how an agent loses messages permanently. Connect does not, and any workaround that involves forcing a sync forward is worth refusing on the same grounds.

## What you can do today

1. Decide what genuinely has to go out today and approve those first. The queue is ranked rather than chronological, so the ranking is already doing some of this for you.
2. Send anything urgent from your own mail client, outside Connect. A person's own send inside Connect goes through the same boundary and the same counter, so it does not sidestep the limit.
3. Wait for the reset. Counters reset at midnight UTC, which is 05:30 in India — early morning rather than local midnight.
4. Change plan if this is a recurring shape rather than one busy day. See [Changing plan](/docs/workflows/plan-change/); the new number applies at the next reservation.

What does not help: pressing send again, which produces the same refusal, and switching the runtime mode, which changes whether work is sent rather than whether it may be.

## For an administrator, and when to escalate

- Identify which dimension is spent before doing anything. They are separate numbers and the fix differs per dimension.
- Check whether one action is consuming several units — a reply to several recipients does.
- Look at the day's usage rows: each stores the limit that applied when it was written, which makes a mid-day plan change readable rather than confusing.
- Consider whether the volume is real. A workspace hitting a send limit daily is either growing or replying to things it should not be replying to.

Escalate when refusals appear while the counter plainly has headroom, or when the same limit is reported for a dimension your plan does not cap. Both are inconsistencies rather than limits, and neither is fixed by waiting for midnight.

## Questions

### Does the allowance reset at my local midnight?

No. Counting uses the UTC date, so the reset lands at 05:30 IST. A workspace working late in India crosses into a fresh allowance early the next morning rather than at local midnight.

### Can I send it myself to get round the limit?

Not from inside Connect — a person's own send uses the same boundary and the same counter, which is what makes the limit meaningful. Sending from your own mail client is outside Connect entirely, and is a perfectly reasonable thing to do for something urgent.

### Do held items send themselves after the reset?

Anything held only by the allowance can proceed once the counter resets, according to the workspace's autonomy. Anything held because a rule says a person decides still waits for that person; a reset is not an approval.

## Related

- [Usage and allowances](https://connectbyjbrh.com/docs/account/usage/)
- [Entitlements and runtime choice](https://connectbyjbrh.com/docs/account/entitlements/)
- [Enforcing an allowance, end to end](https://connectbyjbrh.com/docs/workflows/allowance-enforcement/)
- [Hitting the daily allowance, end to end](https://connectbyjbrh.com/docs/workflows/quota-refusal/)
- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [The plan has lapsed](https://connectbyjbrh.com/docs/troubleshooting/plan-lapsed/)

## What this page is based on

- `backend/app/metering.py` — separate dimensions and their enforcement points
- `backend/app/tenant_entitlements.py` — the refusal message and the reset rule
- docs-source/sources/CHANNELS.md section 1 — held work and the unmoved cursor
- Connect capability registry (docs-source/facts.py)