CH·02CLI reference

deeprelay billing subscription

Show your subscription status and quota usage

Synopsis

Answers the question a plan customer asks before a long run: how much of my monthly quota is left?

Without it, the first sign that a quota is spent is a 429 in the middle of a batch. deeprelay billing subscription reports the same five meters the server enforces on every request, so you can see a limit coming.

Input tokens — weighted input tokens used this billing period, against the monthly input allowance.
Output tokens — weighted output tokens used this period, against the monthly output allowance. Reasoning tokens are output tokens.
Weekly input — weighted input tokens over a rolling 7-day window, against the weekly input cap. It does not reset with the billing period; it slides.
Weekly output — weighted output tokens over the same rolling 7-day window, against the weekly output cap. The two weekly caps are independent.
Metered usage — list-price cost of this period's plan traffic, against the per-period backstop.

"Weighted" is the part worth knowing: a model's usage factor multiplies what its tokens cost you against quota. At factor 2, a million served tokens spend two million of the allowance. Per-model factors are on the included-model list in the console.

Cached input counts in full. A prompt-cache hit is still an input token, at the model's factor. Coding agents resend their whole conversation every turn, so on a high-factor model most of what a meter shows is cached context: 7M input tokens on a ×24 model is 168M of allowance even when 6M of them were cache reads.

Below the meters, a By model table shows where each window's weighted tokens came from: raw input (and how much of it was cached), the factor, and the weighted figure, then the same for output. One table covers this period and one the rolling 7 days, each printed only when the plan was used in that window. Each model's weighted figure rounds down on its own, so the rows can sum to a hair under the meter above, which stays authoritative.

When a meter is exhausted the request does not fail outright — it falls back to pay-as-you-go against your credit balance, at list rates. It only fails (429) when the balance is also empty. So the companion command to this one is deeprelay billing balance.

The allowances shown are those of the plan you are on — Base and Plus have different numbers, and the table always reports yours. When a bigger plan is on offer the last line says so, with its price:

Upgrade to Plus ($4.99 / month) with `deeprelay billing upgrade --plan plus`.

Paying from balance

The table also shows whether your renewal is paid from deposited balance (Renews from balance, for a subscribed org) and how your balance splits for paying a plan: what deposited funds can pay now, free credit (which never pays a plan) and card/UPI deposits still inside their 24-hour wait. deeprelay billing renew-from-balance changes the renewal setting.

Not subscribed?

The command still works and still prints the Base allowances, with Plan: not subscribed — it doubles as "what would the plan give me". There is no error path for an org without a subscription. deeprelay billing plans lists every plan.

Examples

# Where am I against the plan?
deeprelay billing subscription

# Which model is eating the weekly input cap?
deeprelay billing subscription --output json | jq -r '
  .usage.weekly_by_model[]? | "\(.model)  \(.weighted_input_tokens)"'

# Am I subscribed at all, for a script?
deeprelay billing subscription --output json | jq -e .subscribed >/dev/null

# Refuse to start a batch with under 10% of the monthly input quota left.
deeprelay billing subscription --output json | jq -e '
  .usage != null
  and (1 - .usage.weighted_input_tokens / .quota.input_tokens_monthly) >= 0.10
' >/dev/null || { echo "input quota nearly spent"; exit 1; }

Output

Plan            Base — $0.99 / month
Status          subscribed (active)
Period          2026-09-03 → 2026-10-03 (UTC)
Input tokens    12.4M of 500M used (2.5%) — 487.6M left this period
Output tokens   1.8M of 50M used (3.6%) — 48.2M left this period
Weekly input    4.2M of 125M used (3.4%) — 120.8M left (rolling 7 days)
Weekly output   1.1M of 12.5M used (8.8%) — 11.4M left (rolling 7 days)
Metered usage   $3.10 of $100.00 used (3.1%) — $96.90 left this period

By model, this period (cached input counts in full):
MODEL                          FACTOR  INPUT  CACHED  WEIGHTED IN  OUTPUT  WEIGHTED OUT
deeprelay/glm-5.3              ×12     1M     820K    12M          150K    1.8M
deeprelay/deepseek-v4.1-flash  ×1      400K   120K    400K         20K     20K

By model, rolling 7 days (cached input counts in full):
MODEL              FACTOR  INPUT  CACHED  WEIGHTED IN  OUTPUT  WEIGHTED OUT
deeprelay/glm-5.3  ×12     350K   300K    4.2M         90K     1.08M

JSON mode returns the API response unchanged: subscribed, status, cancel_at_period_end, the period bounds, the plan you are on, its quota, a plans array of every plan on offer, and — for an entitled subscription whose meter could be read — a usage object. usage.by_model and usage.weekly_by_model carry the per-model breakdown (input_tokens, cached_input_tokens, output_tokens, usage_factor_milli, weighted_input_tokens, weighted_output_tokens); they are absent when unknown or empty. renew_via_checkout is true on a plan that was billed through our previous payment account: it ends with its current period and can't be resumed or upgraded. deeprelay billing subscribe renews it, and on the same plan nothing is charged until the current period ends. renew_from_balance is whether the renewal is paid from deposited balance, and balance_payment splits the balance: balance_cents, spendable_cents (what can pay a plan now), free_credit_cents, pending_deposit_cents and, when something is pending, pending_until. balance_payment is absent when the server could not read it, which is not "nothing to spend".

Two rules for scripts:

Read subscribed, not status. status carries Stripe's vocabulary, and the two can disagree: an active subscription just past its period end still entitles for a short grace window, while past_due cuts access immediately.
A null usage never means "nothing used". It means either not subscribed (check subscribed) or the meter could not be read. Treating it as zero would report a full quota to an org that has none left.

You want	Command
Quota left on the plan	`deeprelay billing subscription`
What the plans include	`deeprelay billing plans`
More allowance	`deeprelay billing upgrade`
Pay renewals from balance	`deeprelay billing renew-from-balance`
Credit left for pay-as-you-go	`deeprelay billing balance`
Past consumption, broken down	`deeprelay usage`
Which models the plan covers	`deeprelay models list` (`plan_covered`)

deeprelay billing subscription [flags]

Options

  -h, --help   help for subscription

Options inherited from parent commands

      --api-base string   API base URL (override with DEEPRELAY_API_BASE env) (default "https://api.deeprelay.ai/v1")
      --debug             Enable debug logging to stderr
      --no-preflight      Skip the plan/credit check before inference requests (override with DEEPRELAY_NO_PREFLIGHT env)
  -o, --output string     Output format: table|json (default table on TTY, json otherwise) (default "table")