Misleading "You have run out of credits" when account has credits in another org

[robobryce]

Summary

brev create returns "You have run out of credits visit the settings page to purchase more" even when the user's account has credits available — as long as the credits live in an org that isn't the CLI's currently-active org. The error message doesn't name which org was checked or hint that switching orgs would unblock the operation, so a user with credits in Org B who is unintentionally pinned to Org A (zero balance) reads it as "I'm out of money."

Reproduction

1. Have a brev account in two orgs: one with credits, one without.

2. brev login (lands on either org as "active", depending on the cached state).

3. If the active org is the zero-balance one, brev create <name> --type m8i-flex.2xlarge --min-disk 50 --detached fails immediately with:

   github.com/brevdev/brev-cli/pkg/cmd/gpucreate.(*createContext).createWorkspace
   /go/src/github.com/brevdev/brev-cli/pkg/cmd/gpucreate/gpucreate.go:1008
   : there was issues with your credits You have run out of credits visit the settings page to purchase more
   

4. brev set <other-org-with-credits> followed by the same brev create succeeds.

In my case the account had two orgs: a personal one with $0 and the one I actually wanted (gateroom-dev) with ~$194 in credits. The CLI was pinned to the personal one because brev login had set it as active.

Suggested fix

When the error originates from "active org has no credits":

1. Name the org that was actually checked: "Org <name> (<id>) has insufficient credits."
2. Don't say "You have run out of credits" — that's account-scoped phrasing for an org-scoped condition.
3. If the user's account has any other org, append: "Other orgs on this account: <list>. Switch with brev set <name> if one of those has credits."

The text in the current message points the user at a settings page that won't help them — the settings page for the wrong org shows their actual balance (zero), which confirms the wrong belief.

Why this matters in practice

Manager VMs that spawn worker VMs on demand (gateroom, our case) automate brev create. When the manager defaults to the wrong org after a fresh login, every spawn fails with this message and the bot surfaces it verbatim to operators. Operators read "out of credits", check billing, see credits, and lose ~30 minutes diagnosing before noticing the active-org mismatch buried elsewhere.

CLI version

brev v0.6.324 (current as of 2026-05-15 on Ubuntu 22.04).

[robobryce]

Additional context the operator pointed out after I filed this:

m8i-flex.2xlarge is a free instance type — it should be launchable from any org regardless of credit balance. The fact that the credit-balance check is gating it at all is a second bug on top of the misleading message. Free-tier instance types should bypass the credit check entirely (or, if they do flow through the check, free-tier balance should always read as "sufficient").

So the bug is actually two-layered:

1. Free-tier instances shouldn't hit the credit check. Launching m8i-flex.2xlarge failed for me in brycelelbach+robo-0-c5zs ($0 credits) and succeeded in gateroom-dev ($194 credits) — but both should have allowed the free-tier instance type independent of credits.
2. The error text is misleading regardless. Even if (1) is intentional (i.e. the credit check legitimately fires for some account / org / billing state I'm not seeing), the response should name the org and point at brev set <other-org> rather than saying the account is out of credits when it isn't.

Fixing (1) would have hidden (2) in my case, but both seem worth addressing — (2) is a generally-applicable UX improvement for any org-credit mismatch.