Limits

• Go: 132 PC / 5h and 528 PC / 7d.
• Pro: 400 PC / 5h and 1,600 PC / 7d.
• Pro Max: 2,000 PC / 5h and 8,000 PC / 7d.
• Team Standard: 800 PC per seat / 5h and 3,200 PC per seat / 7d.
• Team Premium: 2,000 PC per seat / 5h and 8,000 PC per seat / 7d.
• Enterprise: 4,000 PC per seat baseline / 5h and 16,000 PC per seat baseline / 7d, pooled/configurable.
• Everything else keeps working — hitting the limit is never a hard stop for the rest of the app.
• You're offered three real options: upgrade your plan, buy additional Paw Compute directly, or draw down an existing Paw Credits balance if you have one.

Product disclosure

This disclosure is part of the PawOS documentation for Limits. 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.

Limit outcomes

• If a request is entitlement-restricted, upgrading the tier may be required before the action can run.
• If a request is usage-restricted, the user may need to wait for the rolling window to recover or upgrade if the product supports that path.
• If a request is balance-restricted for Autonomous Work, adding subscription compute alone does not fund ticket completions.
• If a request is connector-restricted, billing changes do not replace provider authorization or organization policy.