Credits and Billing

Chab supports all 21 tools with paid credits or free credits. A start goes ahead when the tool is available right now, your credential is authorized for it and you have enough credits.

Paid plans and credit packs are available on the pricing page: Starter $29 a month (1,000 credits), Pro $99 a month (5,000 credits) and Scale $299 a month (20,000 credits), or yearly with two months free. One-time credit packs cost $39, $179 and $329. On a plan they give 1,000, 5,000 and 10,000 credits. Without a plan (free / pay as you go) they give half: 500, 2,500 and 5,000 credits. Payments are processed by Paddle, our Merchant of Record. If the API returns billing_action_required, its action_url leads to the credit-purchase page. Free credits keep working alongside paid credits.

Plans and API Access

Paid /v1 operation endpoints require an eligible plan, a healthy subscription, the operation family in the plan, the required token scope, and enough credits. A verified free account can also start the documented verified-free operations when promotional funding is enabled and the account has signup-bonus free credits available. Guests can use their trial credits without a subscription. Free credits can pause for a while when Chab's daily free-use limit is reached; work paid with your own credits is never affected by that limit.

The current paid operation-family entitlement matrix is below. An included family is a plan permission, not a promise that every operation in that family is currently ready. Each operation also needs a ready provider and must not be paused before it can start; see Service Health. Preview contracts can evolve. Research's comprehensive mode remains Scale-only; quick and standard support every paid tier. Mail and Drive require separately authorized customer connections and their configured entitlements; they are not part of anonymous access.

Starter supports viewport screenshots, 25 MiB conversion sources, 8,192-token LLM input and research source budgets up to three. Its monthly start limits are 1,000 each for screenshots, conversion and LLM, and 25 for research. Rates, concurrency, credits and current availability still apply. These allowances are limits, not additional included credits or promises that a provider is ready.

Monthly plan credits refresh with the subscription cycle. Unused subscription credits can roll over up to three times the plan's monthly credit amount: 3,000 for Starter, 15,000 for Pro, and 60,000 for Scale.

Free Promotional Funding

When Chab offers a free promotional allowance for an operation, that request runs on free credits only. If free funding, risk checks, market availability, verification, or the operation allowlist blocks the request, Chab returns a free-mode error and does not automatically reserve paid credits.

Promotional credits are stored as free-credit lots for the eligible beneficiary. Each lot has its own grant program, redemption key, issued amount, remaining amount, expiry, and market-policy provenance. Free-credit lots are separate from the team's paid credit balance and from purchased credit packages. They do not increase Team.credits, are not returned as purchased packages, and cannot trigger auto-recharge or credit debt. Free promotional credits are one-off grants and do not refresh monthly.

Browser-trial credits and signup-bonus credits are separate promotional grant programs. If a visitor creates an account from the same browser while an active trial is still eligible, Chab claims the guest identity into the new personal team before email verification. Eligible unspent browser-trial value transfers to the account, accepted guest operations become visible in signed-in history, and active guest holds continue to settle or release against their original reservations. Released unused held value returns to the claimed account when it is still unexpired. The claimed guest cookie cannot start new trial work or read guest-scoped results after the claim.

Balance surfaces keep the two balances separate. GET /v1/credits, GET /api/credits/balance, the dashboard header, the credits page, and team billing settings expose free_credits with available, held, issued, remaining, and ISO 8601 next_expiry_at fields. API balance responses also include free_operations so clients can display the exact free allowlist, credit_source so clients can distinguish signup_bonus from guest_trial, free_credit_policy.monthly_refresh: false, and free_remediation with the balance, transaction, package, purchase, or guest credential endpoints a client can offer when a free request is exhausted or unsupported.

Guest trial API credentials read the same /v1/credits endpoint, but their response is scoped to the guest trial instead of a team. Guest responses report spendable_balance: 0, credit_source: "guest_trial", the guest free_credits summary, the guest operation allowlist, and guest remediation. They do not expose paid team balance, purchased credit packages, team debt, billing settings, or team credit transactions.

{
  "data": {
    "spendable_balance": 0,
    "free_credits": {
      "available": 50,
      "held": 0,
      "issued": 50,
      "remaining": 50,
      "next_expiry_at": "2026-10-14T10:00:00+00:00"
    },
    "free_operations": [
      {"operation_key": "search.web", "scope": "api:search:read"},
      {"operation_key": "contacts.email_verify", "scope": "api:contact:write"}
    ],
    "free_credit_policy": {
      "grant_model": "one_off_promotional_lot",
      "monthly_refresh": false,
      "description": "Free promotional credits are one-off grants and do not refresh monthly."
    },
    "credit_source": "guest_trial",
    "debt": 0
  }
}

When signup bonus funding is available, eligible accounts receive it after email verification completes. The bonus is attached to the user's personal team, appears as promotional credit rather than paid team balance, can be redeemed only once, and expires 30 days after issuance. Creating or switching teams, making API tokens, using device credentials, changing email address, or re-registering with the same normalized email does not create another signup bonus. If account approval, current policy acceptance, the daily signup-bonus limit, market availability, or fraud-prevention checks are not ready, email verification can still complete and the bonus decision remains pending for automatic retry. Disposable email addresses and markets with a zero-value promotional policy do not receive a spendable signup bonus.

When a free-funded operation is accepted, Chab reserves eligible free-credit lots for that beneficiary, using the earliest expiring lot first. One reservation can span multiple free-credit lots, but it never mixes free and paid sources. Settlement, cancellation, estimate updates, and stale-hold cleanup use the exact lots pinned at reservation time instead of choosing a new source later.

Verified-free accounts and guest credentials support all tools, subject to current availability, their scopes, free credits, free resource limits and the daily free-use limit. Free API keys and CLI device tokens share the same signup-bonus free-credit balance; creating multiple credentials does not create multiple balances. Guest trial API credentials are limited to those tools and share the same guest trial free-credit balance as the browser trial. Once a free balance is exhausted, Chab returns free_credits_exhausted. Guest trial credits cannot be refilled by issuing a new credential. Create a free account to keep going: verifying your email adds bonus credits. After that, choose a plan or buy a credit pack. A claimed browser-trial balance does not duplicate the verified signup bonus, and the signup bonus is still issued at most once when email verification completes.

Credit transaction APIs include customer-safe free-credit lifecycle rows. free_credits_issued, free_credits_expired, and free_credits_exhausted have kind: "free_credit" in /v1/credits/transactions and use zero paid-credit amount because they do not change spendable paid balance. Their explicit fields include free_credits_issued, free_credits_expired, required_credits, available_credits, and remediation where applicable. Operation reservation, settlement, and release rows continue to expose funding_mode, credit_source, free_credits_reserved, free_credits_used, and free_credits_released. Public transaction payloads do not expose internal lot IDs, grant redemption keys, market-policy details, risk signals, IP hashes, provider names, or raw principal IDs.

Accepted holds remain valid even if their pinned free-credit lot expires before the operation settles. If an unused free hold is released before lot expiry, the unused amount becomes available again. If it is released after expiry, the unused value is not restored.

Free-mode denials are listed in Free-Mode Operation Errors. Use a paid plan or a paid-only operation start when you want paid credits to be eligible for reservation.

Estimates

Billable operations include an estimated credit cost before expensive work starts. Chab checks the API key budget first, then the team's available credits. If the team does not have enough credits for the estimate, Chab returns insufficient_credits before starting work and no credits are held or charged.

Teams also have an operation spend threshold. Chab compares the current active reserved operation credits plus the new estimate against the team's configured threshold, or the plan default when no team override is set. If the estimate would exceed that threshold, Chab returns spend_threshold_exceeded before creating a hold. Lower the request budget, raise the threshold from the credits usage page, or move to a larger plan before retrying.

Longer or variable-size operation families may update the estimate while work is running. If a higher estimate would exceed the caller's budget or the team's available credits, Chab stops safely and settles only the work already incurred.

Expensive operation families may also support estimate-only calls before starting work.

Some operation families use conditional estimates instead of a single flat price. The accepted operation response always shows the estimate Chab reserved for that specific request.

API key spending policies

Each API key has an independent spending mode. New keys start at none and return token_spending_disabled for billable starts or downloads. all allows spending subject to team controls. capped uses one non-renewing allowance: accepted work is held against that allowance, actual charges settle it, and unused holds are released. GET /v1/me reports the current allowance and all active reservations for the key.

The shared key policy revision and the allowance version are different counters. Changing the current cap advances the policy revision but retains that allowance's held and settled usage. Starting a new allowance is an explicit replenishment action: it closes the old allowance, opens the next version, and resets only current capacity. Work accepted under an older version still settles or releases against that original allowance.

Entering capped mode creates a new allowance and attaches current holds; the limit cannot be below that exposure. Leaving capped mode does not move old holds. none blocks new billable starts and estimate growth but keeps nonbillable endpoints and already-paid results available. all removes only the key ceiling; team balance, request budgets, plan quotas, spend thresholds, and recharge limits still apply. Returning to capped mode opens a new version.

active_reserved_credits is the key-wide held total across current and older allowances. The allowance's held_credits is only the active version's held amount. Remaining capacity is limit_credits - settled_credits - held_credits. token_budget_exceeded means an estimate, increase, or authorized download maximum is greater than that capacity.

An accepted idempotency-key replay returns its original operation and hold even if the key policy was tightened later. Budget denials are permanent for that request key: after changing the policy or request cost, use a new idempotency key. Usage control order is rate, quota, concurrency, key spending, team spend threshold, team credits, then provider throttling. A key-budget denial therefore cannot trigger auto-recharge.

Chab authorizes streamed downloads before sending bytes. The authorization reserves the maximum charge derived from trusted artifact size, no output chunk may cross that ceiling, and final settlement uses actual bytes. Provider-hosted redirects transfer zero Chab-served bytes and therefore settle at zero. A partial stream settles only emitted bytes and releases the remainder. Closed allowances, source-linked allocations, and delivery intents retain the key's public identifier and accounting facts after credential deletion so duplicate settlement or recovery cannot charge twice.

Search Pricing

Search operation prices follow the documented request caps:

The accepted operation reserves the full estimate. A successful search.web settles on the unique results returned (never above the reservation); a successful search.serp settles at the reserved amount. If no chargeable work starts, cancellation or failure releases the hold. If chargeable work partially starts, Chab may charge the actual partial amount up to the active hold and release the remainder.

Scrape Pricing

Scrape operation pricing depends on the rendering mode Chab may need:

Starter requests reserve 2 credits for direct and auto rendering, and 10 credits for explicit browser rendering. Pro and Scale requests reserve 10 credits when browser rendering is requested or when auto rendering is eligible to fall back to browser rendering. If a Pro or Scale auto request succeeds with direct fetch, Chab settles the actual 2-credit direct cost and releases the unused 8 credits.

Target URL validation failures are not charged. A timeout after target fetch or rendering work starts can be charged. Extraction failures after Chab has retrieved page content are charged at the rendering mode that incurred the work.

Screenshot Pricing

Screenshot operation pricing depends on capture mode:

Viewport and element captures reserve 10 credits. Full-page captures reserve 15 credits. Successful captures settle the reserved amount. URL-safety failures before browser work are not charged. selector_not_found, capture_timeout, and capture_failed are charged because browser capture work started. artifact_creation_failed releases the hold because Chab could not make the captured image available as an artifact.

File Conversion Pricing

File conversion pricing depends on Chab's trusted source category:

Unsupported file types, unsupported conversion pairs, validation failures, and unreadable or expired sources are not charged because conversion work does not start. A PDF that has no extractable text fails with unsupported_file_content and releases the hold. Converter timeouts or failures can be charged only after conversion work starts, capped at the reserved estimate.

Translation Pricing

Translation uses dynamic token pricing under the public pricing class translation-standard:

max(5, ceil(input_tokens * 2 / 1000 + output_tokens * 8 / 1000))

The reservation estimate is deterministic and bounds the whole operation: source tokens, prompt and response overhead, glossary and placeholder instructions, the selected style, both passes for idiomatic, and up to two repair attempts. max_output_characters controls inline result placement only; it is not a token cap.

Settlement uses actual input and output usage across translation, refinement, and repair attempts, capped at the reserved hold. Unsupported formats, oversized sources, artifact-source failures, scope or plan denials, budget denials, insufficient-credit denials, and provider-readiness denials before work starts are not charged. Structure, placeholder, or repair failures after translation work starts can charge the actual incurred usage, capped at the hold.

Research Pricing

Research uses explicit customer budgets. Every research.deep request must include source_budget and max_credit_budget; Chab does not choose defaults. The accepted operation reserves the full max_credit_budget, then final settlement uses normalized actual usage and retained cited source count, capped at that reservation.

For paid research, the accepted hold must also cover Chab's bounded provider work. Initial two-search minimum holds are 210 credits for quick, 2,070 for standard, and 4,130 for Scale-only comprehensive. A lower hold may qualify for one-search execution; otherwise Chab returns research_budget_exhausted before provider dispatch. These are reservation thresholds, not fixed charges. Free and guest research instead runs on free credits within the daily free-use limit.

source_budget is the number of unique cited source URLs Chab may retain, show, count in sources_analyzed, and bill against. It is not a guarantee about how many sources the backing research system may browse while working.

Minimum accepted max budgets are 25 credits for quick, 75 for standard, and 250 for comprehensive. Quick accepts source_budget 1-10, standard accepts 1-25, and comprehensive accepts 1-100. Comprehensive mode is available only on Scale.

If work completes below the accepted max budget, Chab releases the unused reserved credits. If the accepted budget is exhausted and a usable cited report exists, the operation can succeed with partial_results and budget.exhausted=true. If no usable cited report can be produced, the operation fails with research_budget_exhausted, which is chargeable up to the accepted budget. Cancellation after research work starts may charge recorded actual work up to the active hold.

Keyword Research Pricing

Keyword research operation prices are fixed for the documented request caps:

Pricing is flat per accepted operation regardless of batch size or requested metric family count within the documented caps. SEO keyword operations are available on Pro and Scale plans.

Domain Data Pricing

Domain data operation prices follow the documented request caps:

Each accepted operation has one price, set by its request. Chab-streamed artifact downloads may create a separate bandwidth egress charge; see Bandwidth and Egress.

Business Data Pricing

Business data operation prices are fixed for the documented request caps:

Pricing is flat per accepted operation. Business data operations are available on Pro and Scale plans.

Contact Pricing

Contact operation prices are fixed for the documented request caps, and email verification is priced per address:

Domain search and email finder are flat per accepted operation. Contact operations are available on Pro and Scale plans. Validation failures, missing scope, plan denials, insufficient-credit denials, and readiness failures before work starts are not charged. A provider failure releases the full contact-operation hold only when Chab can verify that no billable provider work occurred or waives a Chab-caused failure. An ambiguous started request remains held for cost review; a verifier request confirmed counted can incur its fixed price without a usable result. Once provider work returns a successful result, a no-result domain search or email finder still settles at the fixed price.

LLM Pricing

LLM generation uses dynamic token pricing. Chab estimates the initial hold from estimated input tokens, requested maximum output tokens, and any requested reasoning token cap. Settlement uses reported model usage when available; otherwise Chab uses the deterministic estimate. Generation pricing is computed as one summed decimal token-rate expression, then one final ceil() is applied to the total instead of rounding each token bucket separately.

Embedding pricing uses the reservation-time estimated input-token count and settles from the same deterministic estimate because embedding provider usage is not reported:

max(1, ceil(input_tokens * 0.2 / 1000))

llm.generate, llm.embeddings, and translate.text_or_document support max_credit_budget. If the estimated cost is higher than the supplied budget, Chab returns max_budget_exceeded before creating operation rows or credit holds. research.deep requires max_credit_budget and reserves it up front; runtime budget exhaustion maps to partial_results or research_budget_exhausted, not max_budget_exceeded.

Max Credit Budgets

Some dynamic operation families let the request include max_credit_budget. This is a per-request ceiling, separate from team spend thresholds and API-key budgets. A request denied by max_budget_exceeded is not charged and does not create an operation.

Reservations and Releases

When a billable operation is accepted, Chab reserves credits for the estimated cost. Reserved credits are held for that operation; they are not charged yet and the team's stored credit balance is not reduced until final settlement.

Idempotent retries with the same Idempotency-Key and byte-identical request body return the original operation and do not create a second hold. If a request is denied for insufficient credits, top up or reduce the operation size and use a new idempotency key.

If work never starts, fails before chargeable work happens, or is cancelled with no chargeable work, Chab releases the hold. Released credits become available for new operations again.

If Chab has already sent a billable start to a provider, cancellation, token or connection revocation, a worker timeout, and stale-hold cleanup do not prove that the provider charged nothing. Chab keeps the reserved credits unavailable until the actual provider cost is verified. The hold is not itself a charge. For a started search task, Chab can continue reading that exact provider task for cost reconciliation even after access is revoked; it never starts a new task. Automatic checks stop after 24 hours or 120 polls, whichever comes first, and the case moves to operator review. Other unknown outcomes can require manual review immediately. There is no promised automatic resolution time. Support can review the provider's records and explain or correct a long-lived hold; Chab will not guess a charge or release it as zero solely because a worker stopped or a customer cancelled. For search.web in provider task mode, the provider charges when it accepts the task; cancelling or revoking access after that point may settle the fixed reserved price even when no result is delivered. contacts.email_verify also has a fixed price when its request is confirmed counted. Chab waives its own verified failures rather than passing their cost to the customer. If an email-verification request remains genuinely unprovable, an operator can release its hold as an audited write-off only after the 24-hour review window; that does not claim the provider charged nothing.

For free promotional holds, release restores unused value only when the pinned lot has not expired. Released value from an expired free-credit lot is not made available again.

Settlement

Final credit usage is recorded when an operation reaches a terminal state. Successful operations charge the final amount from the reserved credits. By default, the final charge is capped at the reserved amount unless the operation family has already increased the estimate and reserved the additional credits.

Cancelled, timed-out, or partially successful operations follow the documented policy for that operation family. A cancellation or timeout after chargeable work may settle a partial amount up to the active hold, then release the unused remainder. A failed or cancelled operation with provider-confirmed no chargeable work releases the hold with no charge. If provider cost is still unknown, the operation remains non-terminal with its reservation held pending review.

Provider retries, provider terminal failures, timeouts, and cancellations still produce exactly one settlement for the operation. One-off operation callbacks include the operation settlement summary when a settlement exists, but callback delivery success or failure never changes billing.

Token Budgets

API keys can have their own capped budget. For capped keys, Chab checks both the token budget and team credits before work starts.

Credit Packages

Credit packages are one-time purchases for $39, $179 and $329. On a plan they give 1,000, 5,000 and 10,000 credits. Without a plan you can still buy them (free / pay as you go) and get half: 500, 2,500 and 5,000 credits. The size is fixed when the checkout starts and appears on the Paddle receipt. Purchased credits stack with subscription credits and expire after 12 months.

While a team without a plan has bought credits left, it counts as pay as you go: it spends those credits, has Starter's tools and limits, and can use the tools that free credits don't cover, such as research. Its existing API keys are allowed to spend after the first pack. Keys that lack a tool's permission need a new sign-in. When the bought credits run out or expire, the team is free again and its remaining free credits work as before. If the team has debt, new purchased credits reduce that debt first; any remainder becomes spendable balance. Completed package fulfillments appear as explicit credit ledger entries. Payment confirmation adds credits once, including when the same confirmation arrives more than once. A purchase can briefly remain pending after credits appear while its payment reference is linked. Retry status checks with the original purchase identity; do not start another purchase to resolve a pending one.

Auto-Recharge

Auto-recharge buys credit packs. Teams may configure auto-recharge where supported. Auto-recharge is opt-in: the team selects a package, a low-balance threshold, and a maximum recharge count per billing period. The period cap is the hard stop for automatic spending, and the dashboard shows the derived maximum period spend for the selected package.

Teams may also set an optional daily burst cap. Auto-recharge requires an active subscription and a usable payment method. If a charge fails, auto-recharge is paused until the failure is cleared. API-key budgets cannot bypass the team auto-recharge cap; any number of token-driven operations still share the same team billing-period counter.

If Chab reserves an auto-recharge attempt but cannot confirm its final outcome, the reservation fails closed and may continue to count against the team's billing-period cap until support resolves it or the billing period changes.

Recharge charge acceptance, fulfillment, cap-reached, and failure events appear in the credit ledger.

Bandwidth and Egress

When Chab serves bytes for downloads, exports, connected-drive operations, or operation artifacts, it may charge credits for transferred bytes. Usage logs show the transferred byte count, pricing version, related operation or artifact reference when available, and a short explanation. Safe provider-hosted artifact redirects do not pass bytes through Chab and do not create an egress charge.

Hosted MCP artifact delivery currently includes a free transfer allowance at zero credits for guest and account connections. Account bytes remain metered with the zero-credit waiver recorded; guest deliveries are recorded on the operation. Hourly transfer and daily byte limits still apply. See Hosted MCP for current limits and download-link lifetime.

Corrections and Refunds

Support-applied credit corrections are append-only ledger entries. Each correction includes a signed credit amount, a customer-safe reason, and a reference. Positive corrections reduce outstanding debt first; any remainder becomes spendable balance. Negative corrections can decrease the team balance and may create debt. Corrections do this without editing or deleting past ledger entries.

Money refunds are tracked separately and are shown as returned only after the payment processor confirms them. Chab permits only one unresolved refund for a transaction and never resends an attempt whose provider outcome is unknown. Partial refunds allocate exact transaction line-item amounts and cannot exceed the original transaction total across confirmed and pending attempts.

For a one-time credit-package refund, fulfilled credits are revoked in the same proportion as the aggregate confirmed refund; a full refund revokes the exact fulfilled package amount. If those credits were already spent, the correction can create debt. If the payment processor later reverses a confirmed refund, Chab restores the corresponding credits with a new append-only ledger entry and updates the confirmed aggregate without rewriting history.

Usage Visibility

Usage views show operation credit activity alongside other credit ledger rows. For operation rows, Chab shows the operation reference, family and key, API key identifier, reservation or settlement state, reason, credit amount, timestamps where available, and a short explanation. Reservation and release rows are informational zero-credit rows; settlement rows show the actual debit.

Free promotional value is exposed only through explicit free-credit fields. GET /v1/credits includes a free_credits object with available, held, issued, remaining, and next-expiry facts. The sibling free_credit_policy field states that free promotional credits do not refresh monthly. available is usable for new free-funded work, held is already reserved for accepted operations, and remaining is their sum. Operation usage rows can include funding_mode, credit_source, free_credits_reserved, free_credits_used, and free_credits_released; GET /v1/credits/transactions exposes the same free-credit usage fields for matching transaction rows. Raw free-credit lot identifiers are not part of customer-facing metadata.

The same ledger also shows package fulfillments, auto-recharge charge acceptance and fulfillment, auto-recharge cap and failure events, egress charges, and credit corrections.

The same page also shows usage limits for included operation families: current rate profile, daily or monthly quota usage, concurrency limit, option caps, and the effective operation spend threshold.