Usage

Your account shows Paw Compute used in rolling windows, not a fixed monthly reset bucket. Normal conversation turns and tool continuations count; background/system usage and Fable are tracked separately from the rolling allowance.

• Fresh input, cached input, output, and thinking tokens are normalized server-side into Paw Compute.
• The renderer submits provider-reported usage; the main process and billing engine compute the charge.
• Usage events are append-only and use run/session identifiers where the implementation supplies them.
• Rolling windows restore capacity naturally as older usage ages out; there is no midnight reset button.

Product disclosure

This disclosure is part of the PawOS documentation for Usage. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.

What users see

• Users see subscription plan, tier entitlement, Paw Compute usage, rolling limits, Autonomous Work Credit balance, checkout/payment status, and blocked-state messages when a request exceeds entitlement or balance.
• Billing docs should distinguish subscription usage from ticket-completion credits and should identify which runtime or action class consumes which meter.
• Upgrade, payment, and limit pages should describe what changes immediately in the app and what remains subject to confirmation or connector setup.

What PawOS does

• Paw Compute meters ordinary runtime usage according to the configured plan and rolling-window limits.
• Autonomous Work Credits are a separate dollar-denominated wallet used for eligible autonomous ticket completions.
• Entitlement checks run before execution-class work and before connector activation/restore where a connector is tier-gated.

Permissions and boundaries

• Buying credits does not upgrade subscription entitlements, and upgrading a subscription does not add Autonomous Work Credits unless a separate credit purchase or included allowance says so.
• Billing permission does not equal action permission. A paid tier can still be blocked by confirmation, connector scope, local system permission, or organization policy.
• Failed, blocked, or unverified autonomous work should not be charged as completed work.

Evidence and records

• Usage and charge records should identify source, amount, period/window, balance where applicable, and whether the event came from subscription usage or autonomous ticket completion.
• A billing block should explain whether the block is entitlement-restricted, usage-restricted, balance-restricted, or connector-restricted.

Limitations and user responsibility

• Exact plan limits and payment availability depend on current pricing configuration and payment-provider setup.
• Refunds, invoices, taxes, failed payments, and subscription cancellation are governed by the live billing provider flow and any applicable legal policy pages.