← Files OrbitARCHIVED FILE

skills/orbit-person-research/references/credits.md

6 KB · Oct 8, 2026 · 06:28 UTC

↓ Download file

# Credit usage

## One pricing and billing authority

The Orbit API owns operation pricing, the credit ledger, and billing decisions
for the connected Orbit account or organization. ChatGPT is an adapter, not a
separate billing system. A ChatGPT subscription does not imply unlimited Orbit
usage.

- Read the [public pricing catalog](https://api.orbitsearch.com/v2/developer/pricing)
  for current operation rates and units. This is a public, read-only lookup;
  never ask for an API key or bypass app tools with authenticated REST calls.
- Use the [billing dashboard](https://developer.orbitsearch.com/dashboard/billing)
  for account-specific balances, purchases, and plan details.
- For the connected account's usage, call `get_credit_usage` and report the
  returned available/reserved credits, usage, request count, and period. Preserve
  the response's scope: connection-level usage is not necessarily the entire
  organization's usage. Do not infer missing totals.
- Do not copy fixed prices into this skill, invent dollar conversions, or assume
  signup credits, monthly resets, bonuses, or a particular remaining balance.
  State an allowance only when the current account or plan evidence confirms it.
- If the catalog cannot be read or an operation is missing, say its current
  price could not be verified. Do not substitute remembered or pending PR prices.

## What consumes credits

Use the deployed catalog and returned billing metadata as the authority. The
centralized billing model distinguishes these operations:

| Operation | How to explain usage |
| --- | --- |
| Cached search | Charged in blocks of unique cached profiles returned, rounded up using the catalog's block unit. An empty cached result set has no cached-result charge. Candidate Discovery results are excluded from that count. |
| Candidate Discovery | Charged for unique profiles returned. Generation within the same operation replaces the discovery tier rather than stacking discovery and generation fees. |
| Profile generation | Partial and full generation use their respective catalog rates. Full generation includes intermediate partial work. A later explicit upgrade is a new operation. A profile already at the requested depth does not incur a new generation fee unless regeneration is requested. |
| Explicit profile read | `get_profile` uses the profile-read rate, including for an already-generated profile. It retrieves existing data without generating, refreshing, or repairing it; request enrichment separately when needed. Search can embed identity fields, contact fields, and generated sections such as bio, jobs, and education; the complete profile includes image galleries and source links where available. |
| Watchers | Completed runs and updates use their respective catalog rates. Recurring activity can consume credits after the initial request; insufficient credits can pause a watcher. |

Do not infer that unlisted management actions are free. Generation depth,
profile reads, and discovery are different operations, not interchangeable
names for the same charge. Polling an existing operation does not repeatedly
charge already-settled results, but newly completed work can still settle.

For an estimate, use current rates and units with the requested scope. Label
unknown result counts as estimates, not a guaranteed total. Avoid opening every
search result automatically: read the profiles needed for the user's requested
answer, reusing sufficient profiles already read in the conversation. Do not
omit the full read needed to support substantive claims just to conceal its cost.
Confirm unclear bulk scope or recurring watcher activity before starting it;
do not add repetitive confirmation prompts to ordinary requested lookups.

## Insufficient credits and topping up

Treat HTTP 402 or `developer_api_credits_insufficient`, including an equivalent
error returned by an app tool, as a billing failure:

1. Stop additional paid work. Preserve any usable partial results and explain
   which requested work did not complete. Never represent the error as no
   matching people or claim the unfinished task succeeded.
2. Show `requiredCredits` and `remainingCredits` only if returned by the service.
   Otherwise explain that more credits are needed without guessing an amount.
3. Link to the [Orbit billing dashboard](https://developer.orbitsearch.com/dashboard/billing).
   Ask the user to use the same Orbit account connected to ChatGPT and, where
   applicable, the same organization. An organization billing administrator may
   need to help. Do not promise that signing into ChatGPT also signs them into
   the Orbit website, or claim a purchase happened before confirmation.
4. Do not automatically buy credits, switch billing accounts, loop retries,
   or silently replace the unfinished research with web search or memory.
5. After the user confirms credits are available, resume only the necessary
   unfinished work. For a paused watcher, inspect its state before offering to
   resume it; topping up alone is not proof it has restarted.

Example: "Orbit needs more credits to finish this search. You can add credits
in [Orbit billing](https://developer.orbitsearch.com/dashboard/billing) using
the Orbit account connected here. Then we can continue."

## Retries, holds, and partial work

Preserve existing resource IDs and any supported request/idempotency key when
retrying the same request with unchanged inputs. Use only fields exposed by
the app tool; do not invent an idempotency parameter. Check the existing search
or enrichment status after an ambiguous timeout instead of launching duplicate
paid work. A genuinely new operation is not a retry of an earlier one.

Async work may return partial results and per-result failures. Report these
accurately. Temporary reservations or holds are not settled consumption, and
releasing unused credits is not a purchase. Rely on API-reported balances and
settlement rather than computing a second ledger from tool calls. Distinguish
rate limits (HTTP 429) from insufficient credits (HTTP 402); do not recommend
topping up merely because a request was rate-limited.

SHA-256: 5640de93252a6c85547c4967527c921837b7b9d747a0620d0f54f526b0ebd009