A plan lapsing, end to end
A lapse stops spending, not access. Sends and mail ingestion refuse with a plan reason; the work that was refused is held rather than discarded; and everything already stored stays readable and searchable. No feature is removed, no screen disappears and no record is deleted. Settling the plan releases the same queue that was waiting, so nothing has to be recreated by hand afterwards.
The distinction the whole flow rests on#
A plan decides how much a workspace may do in a day and how many of certain things it may keep. It never decides what it may do. There is no plan tier that hides Needs You, removes the Assistant or takes away a channel, because the feature set is one implementation shared by both audiences — the operator's own workspace runs the same code with no plan and no allowances at all.
So a lapse is a spending event. reserve_daily_usage refuses with a coded reason (plan_inactive when the entitlement is not active or trialing, trial_expired when a dated plan has passed its end), and every path that spends goes through that one reservation. Reading, searching, exporting, changing settings and signing in are not reservations, which is why they keep working.
What stops and what carries on#
| Activity | During a lapse | Why |
|---|---|---|
| Sending an email or a message | Refused, with a plan reason on the attempt | Every send reserves against the daily counter first |
| Ingesting new mail | Stops after the refusal, and the read position is not moved | Ingestion is metered; advancing past refused mail would lose it |
| Inbound customer messages already delivered | Kept and counted, never refused | Discarding a real customer's message to enforce a quota protects nothing |
| Reading conversations, calls, files, the Data grid | Unchanged | None of it spends anything |
| Signing in | Unchanged | Sign-in resolves a workspace; it does not reserve |
| Approving a held draft | Recorded, and the send waits | The approval is a decision; the send is the spend |
Stage by stage#
- Trigger — the entitlement stops being active: a dated plan reaches its end, or the workspace's plan status moves out of active and trialing.
- User or external event — usually nothing a person did. The first sign is work that stops going out, not a screen that changes.
- Authentication and workspace resolution — unaffected. A lapse changes the entitlement, not the workspace's status, so sessions still resolve and every screen still opens.
- Ingest or request — the next metered request arrives: a send, or the mail sync's next batch.
- Canonical record — the entitlement row is read for the plan facts; today's usage row is read for what has been spent. Neither is written by a refusal.
- Reasoning — none is spent. The refusal happens before the model is asked, which is deliberate: paying to draft a reply that cannot be sent is the worst of both outcomes.
- Knowledge, memory and rules — untouched. A lapse teaches Connect nothing and changes no standing instruction.
- Autonomy and approval — unchanged. A workspace on
autonomousis still onautonomous; it simply cannot spend, so its outbound work waits like a held draft. - Action through a provider — none. Nothing is handed to Gmail, a carrier or a messaging provider, so there is no half-sent state to reconcile later.
- Result — a coded refusal (
plan_inactiveortrial_expired) attached to the attempt, and the item stays where it was. - Relationship, timeline and memory — the conversation is not marked as answered, because it was not. A refused send never becomes a sent one in the record.
- Audit, usage and Needs You — the refusal is recorded as a decision with its reason, no allowance is consumed, and the blockage surfaces for a person rather than sitting in a log.
Why the mail cursor stays put#
Mail ingestion is metered, and a refusal in the middle of a sync is the one place where a plan limit can destroy data rather than delay it. The sync walks a provider's history from a stored position. If that position moved forward over a window whose messages were refused, the next sync would start after them and never look back — the messages would not be late, they would be gone.
So the position advances only over mail that was actually stored. When a reservation fails the sync stops, records that the quota was reached, and leaves the cursor behind the refused message. The next run — after a reset or after the plan is settled — picks up exactly there. The cost of that choice is a sync that returns fewer messages than the provider had; the benefit is that nothing silently disappears.
Coming back#
Settle the plan. The entitlement returns to an active status and its daily limits are restored.
Result The next reservation succeeds instead of refusing, with no restart and no cache to clear.
Let the mail sync run.
Result It resumes from the held position, so the messages refused during the lapse are ingested in order rather than skipped.
Work the queue of held outbound items.
Result Approved-but-unsent replies go out through the same send boundary they would have used, and each one gets provider evidence before it is called sent.
Questions#
Does a lapse delete anything?
No. Conversations, calls, files, knowledge, memory and relationships are all still there and still readable, and nothing is pruned on a schedule tied to the plan. A lapse withdraws the ability to spend; it is not a retention event.
Can I still sign in while a plan is lapsed?
Yes. Sign-in resolves a workspace from your membership and checks that the workspace itself is active — a different thing from the entitlement. A lapse leaves the workspace active, so every screen opens and shows real data.
Does the Owner's workspace ever lapse?
No. The operator's workspace has no plan and no gates, which is why a limit that misbehaves is often invisible there and obvious to a customer. Any allowance question has to be checked as a customer session to mean anything.