Credits

Credits are the shared balance your organization uses for metered workloads on Dreadnode SaaS. A hosted model call, a running sandbox, or another metered service deducts from the same balance.

What consumes credits

Workload	How usage is measured
Dreadnode-hosted inference (dn/*)	Successful model calls, using their input and output token rates
Sandboxes	Runtime while a sandbox is active
Hosted web search	Successful search calls
Telemetry	Ingested spans and stored telemetry data

Models that use your own provider key (BYOK), such as openai/* or anthropic/*, do not use Dreadnode credits. The provider bills those calls to your account instead.

Calculate an inference call

Each dn/* model has separate rates for input and output tokens. Rates are quoted per 1 million tokens. Convert both token counts to their dollar cost, add them together, then convert the total at 1,000 credits per $1 of inference cost:

input cost  = input tokens  / 1,000,000 × input rate
output cost = output tokens / 1,000,000 × output rate
credits     = round up((input cost + output cost) × 1,000)

Every successful hosted inference call costs at least 1 credit.

For example, dn/claude-sonnet-4-6 is priced at $3 per 1M input tokens and $15 per 1M output tokens. A call using 2,000 input tokens and 500 output tokens costs:

input:   2,000 / 1,000,000 × $3  = $0.0060
output:    500 / 1,000,000 × $15 = $0.0075
total:                                $0.0135
credits: round up($0.0135 × 1,000) = 14 credits

Use the rate shown for your selected model rather than treating the example rates as a price list. Hosted inference is charged after a successful call, using its actual input and output token counts. Failed and zero-cost calls do not consume inference credits.

Find rates and usage

Use the product surfaces for current rates and recorded usage:

• Open Account Settings → Chat Models to compare model input and output rates in dollars per 1 million tokens.
• Press Ctrl+K or run /models in the TUI. dn/* rows show input/output rates in credits per 1 million tokens; BYOK rows show provider rates in dollars.
• Open Settings → Billing to see your remaining organization balance and low-balance warning.
• In Inference Usage, choose a date range to see requests, input tokens, output tokens, credits, and cost by model. Organization owners can also inspect each member’s usage.
• Use Transaction History for credit purchases, allocations, auto-refills, refunds, and other balance changes. The Billing page also summarizes sandbox and hosted web search usage.

The Billing page displays the current sandbox runtime rate. At the default SaaS rate, 1,000 credits is about 5 hours of sandbox runtime.

Keep the organization funded

Your organization has one credit balance shared by every member. Purchases and signup allocations add to that balance; metered workloads deduct from it. Purchased credits do not expire.

Signup credits depend on your account’s signup eligibility. An account under review remains active and can sign in, view billing, and purchase credits, but it receives no signup allocation and cannot start or restart metered work. Approval or a successful credit purchase makes the account eligible and claims the current signup allocation once. This restriction applies to the person who starts the work, so another eligible member can still use the organization’s shared balance.

Organization owners can set one Org-level member credit cap under Settings → Billing. The lifetime cap applies automatically to every current and future non-owner member across sandbox runtime, hosted inference, and hosted web search. The member usage table shows consumed credits and the remaining allowance. Owners are exempt.

When a cap applies, each capped member sees their own remaining allowance on their Settings → Billing page alongside the shared organization balance, so they know how much of the cap is left without owner access.

Removing the cap restores access to the shared organization balance without resetting recorded member usage. Re-enabling the cap resumes from that usage, including when a member leaves and later rejoins. Usage that would exceed the cap is rejected, and the affected member’s running sandboxes pause without blocking other members.

Control credit defaults

Platform administrators can change the signup allocation that eligible SaaS users claim under Platform Admin → Billing. Enter a non-negative whole number and a reason, then confirm the change. Set the allocation to 0 to stop new claims immediately without changing existing balances or transactions.

Each eligible account can claim this allocation once for its personal organization. Later allocation changes affect only accounts that have not completed a claim; they do not change existing balances.

The page shows whether the active value comes from deployment configuration or an administrator override. It also shows the last change, including the administrator, reason, previous value, and new value. The configured CREDITS_SIGNUP_ALLOCATION value applies until the first override is saved; later changes take effect across API instances without a restart.

Platform administrators can also change the low-balance warning threshold from the same page. The configured CREDITS_LOW_BALANCE_THRESHOLD value applies until the first override is saved. Enter a non-negative whole number and reason, then confirm the change. New balance checks use the updated threshold across API instances without a restart; existing balances do not change.

Control signup abuse decisions

Platform administrators can edit the active signup abuse policy under Platform Admin → Security → Signup Abuse Policy. The editor controls score thresholds, local signal rules, Account Defender mappings, fail-safe actions, and the master soft-enforcement switch.

Disabling soft enforcement stops policy-driven scoring and actions. Independent hard blocks, such as explicit network denies and invalid challenge tokens, continue to apply.

Enter a publication reason and confirm the complete policy before publishing it. Each successful publication creates an immutable version and audit entry. If another administrator publishes first, reload the active policy and review it before applying your changes again; the editor never overwrites a newer version automatically.

The signup abuse policy editor is available only on Dreadnode SaaS. Enterprise deployments do not show or apply this policy.

Auto-refill

Enable auto-refill under Settings → Billing to add credits when the balance falls below a chosen threshold. Organization owners choose the threshold, refill quantity, and monthly cap. Auto-refill requires a saved payment method from an earlier purchase.

If a refill payment fails, auto-refill turns off. Update the payment method and enable it again from the Billing page.

When credits run out

A zero balance stops new dn/* inference requests and prevents sandboxes from starting or resuming. Running durable sandboxes pause so you can resume them after adding credits; running ephemeral sandboxes stop. Telemetry ingestion and package uploads also remain blocked until the balance is positive.

Because the platform calculates hosted inference usage from the completed response, the final call can cost more credits than remained before it started. The organization balance still stops at zero.

Enterprise deployments

Dreadnode credits apply only to SaaS. Enterprise deployments do not meter workloads against a Dreadnode credit balance. BYOK providers still bill calls made with your provider keys.