Skip to content
PawOS Docs

Paw Compute

The single usage meter every runtime consumes.

Paw Compute is a single, weighted usage meter — every runtime (Conversation, Coding, Browser, Office, and others) reports through the same pipeline, so you see one number, never a per-feature limit.

It replaces a flat "one credit per turn" model with a weighted calculation reflecting real backend cost, computed server-side.

Implemented

The current implementation enforces both a 5-hour rolling window and a 7-day rolling window through PawComputeCapacityStore and RollingUsageGate. Enterprise is pooled/configurable rather than a personal local cap.

Warning

PawOS documentation describes Paw Compute as a product-level meter. Users do not need to configure or understand the underlying model-provider billing details.

Product disclosure

Implemented

This page documents the current PawOS behavior for Paw Compute. It is intended to disclose what users can see and use, what permissions are required, what evidence is recorded, and what limitations remain.

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

Warning

PawOS can assist with planning, coding, automation, connectors, billing flows, and system operations, but the user remains responsible for reviewing plans, confirmations, diffs, command effects, connector side effects, billing actions, and final outputs before relying on them.