Your account

Everything you can do as a buyer is managed from the account page: balance, deposits and ledger; keys; organizations and workspaces; and usage activity. This is the tour, top to bottom. The concepts behind accounts, workspaces and keys are in Organizations, workspaces & keys; this page is about the surface.

The account switcher#

If you belong to organizations, a switcher at the top sets which account the page shows — your personal account or an organization's. Credits, keys and activity all follow the selection; organization money is visible to organization admins only.

Overview#

Who you are (sign-in identity, member-since, sign out) plus the money view of the current account: the balance strip and, for a personal account, your workspaces. An organization adds its members, workspaces and a link to the organization's management page — members, per-workspace membership, and the account-level spend limit live there.

Credits#

The five balance figures#

"Available looks fine but requests return 402" is almost always holds or a spend limit: the spendable figure is the truth a request sees.

Deposits#

Deposits are stablecoin transfers: $1 of stablecoin becomes $1 of credits, with no deposit fee. The flow is a stepper — network, coin, amount, send — driven by your connected browser wallet, which shows the balances you actually hold on the selected network. The first deposit from a wallet asks for a one-time, free signature that binds the wallet to your account; the binding is how later transfers from it credit you automatically. No browser wallet? Send manually instead gives the receiving address, per-network contract details and a QR code for hardware wallets and CLIs. The whole story — coins, networks, exchange withdrawals, recovery — is in Deposits.

Deposit history is one list covering every deposit on the account, whichever rail took the money. Each row names its method — the network and transaction for a transfer, Card for a Stripe Checkout payment — alongside the amount, the sending address where there is one, the status and the credited USD. Five statuses appear: Credited, Awaiting payment (a checkout is open and no payment has been confirmed), Failed (a card payment that did not settle), Expired (a checkout nobody paid) and Refused (money received and deliberately not credited). Credited USD is blank wherever nothing was credited, never $0.00.

On hold#

Above the ledger, the money reserved for requests that are running right now: an estimate is taken before a request and released or charged when it ends, so a balance can read lower than the ledger explains for as long as one is in flight. Each hold names the request holding it. Nothing is shown when there are none.

The ledger#

Every movement on the balance, newest first: deposit, usage (one row per generation, referencing its generation id), refund (with the reason it was issued for), adjustment, referral (a day's referral rewards in one row) — filterable by kind, with a running balance column. The ledger is the audit trail; usage rows join to GET /generation when you want the full record behind a charge.

Keys#

Keys are minted in a workspace and shown once — copy the full sk-hd-v1-… into a secret manager on creation, because only a fingerprint is kept afterwards. The create dialog:

• Name — a label for humans (production, ci).
• Workspace — which workspace (and therefore which account) the key spends from.
• Spend limit — an optional USD ceiling, with a reset window: never (lifetime), daily, weekly or monthly, in UTC.
• Expires — an optional date after which the key stops authenticating.
• Assigned member — optionally tie the key to an organization member for attribution and visibility.

Existing keys show last-used time, spend against their limit, and expiry; edit changes name, limit, expiry and assignee; revoke disables a key immediately and permanently — its rows and ledger history keep their attribution. The key-naming and scoping rules are in Authentication and Organizations, workspaces & keys.

Workspaces and routing defaults#

A workspace is a compartment with its own keys and spend limit. Open one and its Routing section stores default routing preferences: a default suffix (:nitro, :floor, :free), a sort order (balanced, price, throughput, time to first token), zdr and data-collection requirements, require_parameters, allow_fallbacks, provider order / only / ignore lists, allowed quantizations, and max prices per unit.

Stored defaults fill the gaps: a request that states a field wins, a model id's suffix beats a stored sort, and everything else comes from the workspace the key belongs to. The exact precedence and field semantics are in Models & routing.

Activity#

The last 30 days for the selected account: request, token and spend totals, requests and spend per day, and a per-model table. Organization activity is admin-only, and the same rollup and log appear on the organization's own page under Organizations. The same data is available to programs at GET /activity, one UTC day at a time.

Reading the charts#

Count and spend charts show zero for idle buckets within retained coverage. Latency and rates have no measurement without relevant requests. Gaps · connect measurements joins observed points; it does not add measurements to the tooltip or data table.

Under More metrics, Requests with tools counts requests offering tools and Tool-call responses counts recorded responses with a tool-call finish reason, including automatic choices. Neither proves that a tool executed successfully. Tool-call response completion measures whether responses that emitted calls finished normally, across automatic, required and named choices. Truncated, interrupted and cancelled emitted-call responses are incomplete. Text-only replies are excluded. The chart shows its emitted-response sample count and the number of requests with an observation; older requests and unavailable observations remain unknown. Request details show call count, choice and completion outcome. Function names, arguments and results are not retained.

Recorded tool-call verdicts keeps the separate demand-compliance measurement and its sample count. Current grading requires a required or named tool choice; automatic choices are excluded. Older verdicts do not retain the original choice and cannot be separated by eligibility. Neither measurement validates arguments or reports whether a caller successfully executed a tool. Completion observations do not affect endpoint health or routing.

The request log#

Underneath the charts, every request the account made, newest first. No prompt, no reply and no part of a request body is stored, here or anywhere — what a request leaves behind is its model, the endpoint that served it, its timings, its token counts and what it cost.

Filter on the model, the provider, the API type, the key or the workspace, and — behind More filters — on whether the request was cancelled or streamed, on the finish reason, on a date range, and on floors for cost and tokens. Three of the filters offer a third answer rather than a yes and a no, because the columns behind them do: a request can have called the tool it was told to, failed to, or never have been asked; its units can have been priced, gone unpriced, or carry no verdict; and its charge can have settled, failed to settle, or have no verdict either.

The key list is grouped: the account's own keys, the coding playground machines that are running, and revoked keys. Every machine holds a key of its own for as long as it runs, so a machine that has ended is left out of the list — its requests are still in the log under every key, and its minutes are in the sandbox sessions table below the log.

The filters travel in the address, so a filtered log is a link that can be shared and reloaded. While one is on, the log stops updating live and says so — the live feed carries the newest requests unfiltered, and counting how many of those match a filter would report a figure that is wrong as soon as a matching request falls outside it.

One request#

Any row opens the request itself: the model asked for beside the one it resolved to, the provider and endpoint, every timing, the token counters, and the charge split into the eight components that make it up. A request belongs to the account that paid for it, so one link works for whoever may read it — an organization's admin included, whose own account is not the one that paid. Below them, Routing lists every endpoint the request was put to in the order they were tried, with what each one answered — which is where a request that took three attempts shows the two that failed first, and which party each failure belongs to.

Attempt records are kept for seven days. Beyond that the routing panel says so rather than showing an empty list: a request whose record was pruned is not a request that was never routed. Everything else on the page is kept for as long as the account is.

Requests are also reachable from the ledger — a usage entry names the request it charged for — and from a hold on the Credits tab.

Referrals#

Every user has an invite link, shown on the Referrals tab as /invite/… with the user's own eight-character code. Opening it marks that browser with the code for three days and shows the visitor the marketplace, so an account created on a later visit within those three days is attributed as well. Where more than one invite link is opened, the one opened last is the one that counts. /login?ref=… is an alias of the same route and marks the browser the same way.

The mark is a cookie in the visitor's own browser and nothing more: opening an invite link writes nothing about the visitor on the server, and the cookie holds the referrer's code and nothing about whoever is carrying it. An account created in a marked browser is attributed to the code's holder, once, at creation — attribution never moves afterwards, and signing in through someone's link with an account that already exists attributes nothing either way.

You earn 3% of what the accounts you invited spend, and 1% of what their own invitees spend. The invitation pays both sides: an account created through a link gets 1% of its own spending back, permanently, delivered as credits. Every reward is computed as a share of the platform fee that spending generates rather than of the spending itself — 30%, 10% and 10% of the fee — so an endpoint whose cut is below the standard 10% pays proportionally less than the headline. Rewards accrue per UTC day and land as one referral ledger entry per day on the beneficiary's personal account; a day whose rewards round to nothing writes no entry.

Referral credits spend like any other credit and are never paid out — there is no way to withdraw a customer balance, referral or otherwise. Spending from organization accounts generates no referral rewards: attribution names a person, and an organization's spend is not one person's. The tab shows your invitees as their display name or a masked email address, what the rewards have earned in total, and — once there is a first signup or reward — rewards and signups per UTC day over the last 90 days, with each reward on the day it was earned for.

Privacy#

Your data rights, always about you personally rather than the selected account: read the record kept about you, download everything the marketplace stores about you as a zip archive, and delete the account behind a 48-hour, cancellable countdown.

Your account history is every change made to the account and the address it was made from — a key created or revoked, a wallet bound, a workspace or an organization changed. It is append-only in the database rather than by convention, so nobody can edit it afterwards. What each contains and costs is spelled out in Data & privacy.

The Provider link#

Serving models is a separate surface under the same account — the link at the end of the tab row opens the provider application and dashboard.