Usage and credits
Use Usage to understand model requests attributed to a project. Use Credits to manage the selected account's balance. Project activity and account funding are related, but they are different views.
Inspect a project's activity
- Select the intended account and project in the workspace switcher.
- Open Usage.
- Choose 7 days, 30 days, 90 days, all time, or a custom date range.
- Inspect the request, token, and cost totals, then the daily and model breakdowns.
- Filter by model or follow an Agent's usage view to investigate a particular configuration.
The summary reflects the selected window and filters. The recent request list is a bounded set of events, so do not add the visible rows and assume they equal every request in a long date range.
Read a request
A request record can include the model, provider, prompt and completion tokens, latency, price, key attribution, and available Agent or Trace references. Inspect the actual values returned for the event; a missing value is not automatically zero.
One Trial can make several model requests. A Benchmark Job can contain many Trials. Verifier model calls can add further activity when they are routed through the gateway. Job count, Trial count, and request count therefore need not match.
Usage is the gateway's recorded activity. It is not a universal measurement of every sandbox, external provider bill, or local process involved in an experiment.
Local execution and gateway usage
plural run ... --offline keeps Job orchestration and its store local. It does not block network access. A locally orchestrated Agent calling the Plural gateway can still produce gateway usage, while one calling a model provider directly may be billed by that provider without appearing in this project's Usage view.
A hosted Trial can be associated with usage when the request carries the relevant attribution. Do not assume that every custom Harness request has a complete Job-to-Trace-to-usage link; inspect the recorded identifiers.
Manage credits
Open Credits under the intended account to see the remaining balance, add credits, and inspect available billing history. Follow the amount limits and checkout details displayed in the application rather than relying on a fixed amount in documentation.
A completed payment and its reflected balance may not appear at exactly the same instant. If the balance is delayed, inspect the payment state before starting another purchase.
Where available, auto-reload charges the saved payment method when remaining credits fall to the configured threshold. Set both the threshold and reload amount, review the selected account, and explicitly enable the setting. You can disable it from the same section.
Credit balance is not a per-Job budget. Control experiment size through Task selection, Agents, attempts, and concurrency. Environment execution limits and project policy provide separate controls, with enforcement depending on the selected runtime and Harness.
Attribute access correctly
Project keys attribute permitted work to their project. Account credentials need the appropriate project context and account permissions. A key does not grant access to projects outside its scope.
Use People and organizations to manage who can inspect project activity or run additional work. Keep billing permissions and collaboration roles aligned with the work someone actually needs to do.
Investigate an unexpected total
Confirm the account, project, date window, model filters, and any Agent filter first. Inspect request details for the recorded provider and model, then follow available trace references. Check repeated attempts, retries, judge requests, and concurrent Jobs when request volume is higher than expected.
For direct-provider requests, compare with that provider's records. For missing project rows, confirm that calls used the Plural gateway and carried the intended project attribution. Avoid interpreting a blank usage chart as proof that an offline Job incurred no external cost.