Skip to main content
HUD bills in prepaid credits, in US dollars. Runs draw on the team’s credit balance as they use environment runtime and models. Team admins manage billing in Settings → Billing.

​
Plans

Upgrade to Pro starts the subscription, and Manage billing opens the payment portal for cards and invoices. Cancelling keeps Pro until the end of the paid month; Keep Pro undoes the cancellation before then. If a subscription payment fails, the team has Pay as you go limits until the payment succeeds.

​
Credits

  • Add credits buys credits with a card. They are added once the payment completes.
  • Promo code redeems a code for credits, added immediately.
  • Auto top-up charges your saved card for a set amount, at least $10, whenever the balance falls below a threshold you choose. Add a payment method first. If a charge fails, the page shows the error, and work needs credit to start, as without auto top-up, until a later top-up succeeds.
Payment history lists purchases, grants, promo codes, and subscription credits.

​
What costs credits

Environment runtime is billed at the rate in effect when the environment started. EC2 sizes are billed for at least five minutes, then by the minute. Modal sandboxes are billed by the second for the CPU cores, memory, and GPUs they request; see hosted compute. Model calls are billed by the tokens the provider reports:
  • A call you cancel mid-response costs the tokens used so far, at the provider’s price, without the fee.
  • A call that fails on the provider’s side or HUD’s side costs nothing.
  • If the provider streams a response but reports no token counts, HUD charges its estimate for the call, at the provider’s price.

​
Usage

Settings → Usage charts the team’s spend on models and environment runtime over the last 7, 30, or 90 days. Group the breakdown by Model, API key, Provider credential, Member, or Route, and filter by API key and provider credential. Admins can also filter by member. For one job, the job’s Usage tab shows the cost of each trace. Each API key shows what it spent this month, and the REST API returns usage for scripts.

​
Spend limits

A spend limit caps or watches spending over a week or a month. Create them in Settings → Limits: Each limit has an amount of up to $1,000,000 and an action:
  • Alert emails the team’s admins, and the member when the limit is on a member or their key, once spending reaches the amount. A team limit can also alert at a percentage of its amount, such as 80%.
  • Block stops new work once spending reaches the amount. New environments don’t start, and model calls are refused, including the next call of a run already in progress. Refused requests return 403 with spend_limit_exceeded and the time the window ends.
Spending counts model calls and environment runtime. Windows follow the UTC calendar: a week starts Monday at 00:00 UTC, and a month on the 1st. When several blocking limits apply to a request, the first one reached stops it. Reset spend window on a blocking limit starts counting again from zero for the rest of the period. Limits can be paused, edited, or deleted, but their scope and interval are fixed once created.

​
When work can start

Before QA and most other work starts, and before every model call through HUD’s gateway, HUD checks:
  1. Blocking spend limits on the team, the member, and the API key.
  2. Credit balance. On Pay as you go, the balance must be above zero. On Pro, it can go down to $50 below zero. Enterprise has no credit check, and auto top-up skips it while it is working.
Work that fails the check is refused with 403 and a message saying why; add credits or raise the limit and try again. Starting an evaluation is not checked: its environments start and are billed, and its model calls are refused once the check fails. An environment that is already running keeps running and is billed when it stops, but its model calls are checked one by one. Each model call also reserves its estimated cost until it finishes, so many calls at once can’t spend past the balance or a blocking limit.