How Usage is Calculated

Each billable request is admitted by an atomic check-and-increment: the plan limit and your current usage are evaluated together, in one indivisible step, before the request is allowed to run.

• Concurrency-safe. Two requests arriving simultaneously at the limit boundary are serialized. Exactly one will be admitted; the other will be silently degraded.
• No over-counting. The counter only advances when a request is actually admitted. Over-quota requests do not consume a slot.
• Deterministic outcome. The decision is final at admission time — downstream processing never has to second-guess whether the request was allowed.

The rule is simple: only successful, externally-initiated API calls increment the counter. Everything the system does internally on your behalf is free.

Both usage counters (add requests and retrieval requests) reset to zero in exactly four scenarios:

• Cycle rollover. When the billing cycle ends and a new one begins, both counters reset automatically.
• Successful payment. When a payment is processed (upgrade or renewal), counters reset as part of the transition. You start every paid cycle with a clean slate.
• Applied scheduled downgrade. When a scheduled downgrade takes effect at rollover, counters reset. You get the full allowance of your new plan.
• Applied cancellation. When a pending cancellation takes effect and the plan reverts to Free, counters reset.

Counters never reset mid-cycle unless a payment or plan transition triggers it. There is no manual reset path.

The billing cycle is a calendar-month window anchored to your subscription start date:

• Calendar-month anchoring. If you subscribe on May 9, your cycle runs May 9 → June 9 → July 9. The cycle end is always the same day of the next month.
• Short-month clamping. If your anchor day is the 31st and the next month has fewer days, it clamps: Jan 31 → Feb 28 (or Feb 29 in a leap year).
• UTC boundaries. Cycle boundaries are computed in UTC. You can choose a display timezone in the dashboard, but the actual boundary is UTC.
• Concurrency-safe rollover. When the cycle boundary is crossed, only one rollover ever runs — concurrent traffic does not double-rollover or skip a cycle.
• No drift. Each new cycle starts exactly where the previous one ended. If rollover happens slightly after the boundary, the new window is still anchored to the previous end — cycles do not drift forward.

The usage dashboard shows a delta comparing current usage to the previous billing cycle:

• Delta calculation. Percentage change is computed as (current − previous) ÷ previous × 100. If the previous cycle had zero usage, the delta is shown as 0% (never infinity).
• Period resolution. The previous cycle is the one immediately before the current one. Year boundaries are handled correctly (January compares against December of the previous year).
• Per-metric deltas. Each metric gets its own delta. You might see add requests up 30% while retrievals are down 10% — each is independent.

Use the delta to monitor trends. A steadily increasing delta suggests you may need to upgrade before hitting your limit.

Plan limits are enforced verbatim — there is no hidden safety buffer:

• Exact enforcement. The enforced limit equals the published limit. If your plan says 10,000 adds, you get exactly 10,000 adds — no hidden buffer above or below.
• Enterprise plans. Enterprise accounts have unlimited add and retrieval volumes. Usage is still tracked for analytics and billing visibility on the dashboard, but no quota cap is applied.

When a request would exceed your plan limit, MemorySync uses silent degradation:

• Add requests return 200 OK with the canonical success body. No memory is stored.
• Query requests return 200 OK with an empty memories array, as if no relevant results were found.
• No error surfaced. Your application sees a normal response, so billing pressure cannot crash an LLM pipeline mid-conversation.
• How to detect it. The billing dashboard shows when a metric reaches 100% of its limit. Watch the dashboard or set up usage alerts to notice silent degradation before it impacts your application.