Plans & Entitlements

Keel uses three public commercial tiers. Each tier determines dashboard limits, retention, included allowed actions, and access to advanced features.

Generated entitlement snapshot

This table is generated from the public-safe plan entitlement artifact that keel-api produces from its plan definitions. The table below it states the same values in words; neither adds an entitlement the other omits.

Plan tiers

On Enterprise the dashboard shows the organization, its members and their roles; teams are managed through the API.

These values come from Keel’s plan definitions. They do not mean every entitlement is separately enforced on every route. Starter checkpoint views show status only, with no timestamp receipt.

Routing fallback is what a request may configure: how many fallback targets and whether they may use another provider. Cross-provider targets also need routing.allow_cross_provider_fallback: true. Keel moves to the next target only after an eligible execution failure, such as a provider 5xx, a 429 or a timeout, so a configured fallback does not guarantee that a second provider serves the request. See Routing.

• Allowed actions. An allowed action is an allow decision, plus a managed execution that completes as billable. Requests Keel denies or throttles do not count, and a request held for review does not count unless it is later allowed. When a project has used its allowance for the billing period, further requests are refused with budget.plan_quota_exceeded until the next period. There is no metered overage on any plan.
• Human review. On Starter and Production a review gate binds to the project owner: a require_human_review rule, or require_attestation with attestor: "project_owner". Typed approval_requirement rules require Enterprise. See Approver Groups.
• Decision snapshots. Keel writes a governance decision snapshot for every permit evaluation on every plan. Reading them through an export requires Production or Enterprise.
• Timestamp providers. Keel requests RFC 3161 receipts from the providers your plan includes only where timestamping is enabled, and each request is best effort. Customer-selected timestamp authorities are not available on hosted Keel. See Trust and Integrity for what checkpoints and their receipts cover.
• Organizations. SSO, SAML, and SCIM are not available on any plan, and identity-provider group mappings are not evaluated. See Approver Groups.

Canonical governance events, Permits, attestations, and accounting evidence are outside ordinary dashboard-log cleanup. The 30/180/365-day windows are not deletion deadlines for signed evidence. See Data Handling.

Platform limits

Keel’s default configuration applies the same platform limits to every project on every plan:

A managed execution or proxy request that would exceed one of these limits is refused before provider dispatch with HTTP 429 and error code rate_limited. Permit creation is limited to 60 Permits per project per minute; above that, POST /v1/permits returns HTTP 403 with decision deny and reason rate_limited. None of these refusals carries a Retry-After header. The minute limits reset at the start of the next UTC minute, and the cost limit at 00:00 UTC. These limits block; they do not meter or bill overage, and they are not configurable per project. Separate per-agent rate limits are not enforced.

Policy rules such as deny_if_rate_exceeds, throttle_if_rate_exceeds, and deny_if_cost_exceeds add project-specific limits on top of these; see Policy Reference.

Checkout and plan activation

Checkout payment and entitlement reconciliation happen asynchronously. A browser redirect containing checkout_success does not grant a paid entitlement. Refresh your signed-in dashboard billing status, or use GET /v1/billing/status with your owner JWT and the documented request freshness headers. For the effective allowance of a project, use GET /v1/billing/status?project_id=<your_project_id> and inspect plan, status, included_requests, usage_window_start and usage_window_end. The account-only status response does not contain a project’s usage allowance.

A signed out-of-order billing event whose subscription/account association is not yet available is refused rather than granting access to an unrelated account. A non-2xx response is not successful reconciliation. Stripe can retry the event once the required association exists; refresh public status to confirm activation. Keel does not guarantee immediate activation when the checkout page closes.

Stripe’s automatic retry policy  currently provides live-mode retries for up to three days with backoff, and three sandbox retries over a few hours. These are provider delivery windows, not a Keel activation SLA. If retries exhaust or public status remains wrong, contact Keel with the checkout or event identifier for bounded operator investigation. Stripe operators can use its documented event-delivery readbacks and resend facilities; do not treat a resend as proof of entitlement until Keel’s public status confirms reconciliation.

Checking your plan

Keel’s authenticated dashboard and billing surfaces expose the caller’s current plan tier and core entitlements. A typical response includes:

{
  "plan": "production",
  "project_limit": null,
  "log_retention_days": 180
}

A project_limit of null means the plan has no project limit.