Core concepts

The Amux object model has six kinds of entity. Understanding how they nest answers most questions of the form "who gets billed", "who can see what", and "why was this request rejected".

How the objects relate#

User (sign-in identity)
  │
  ├── Personal account ────── Personal workspace (exactly 1)
  │      balance lives here        │
  │                                └── API keys
  │
  └── Organization account ── Workspace A ── API keys
         balance lives here  ├── Workspace B ── API keys
                             └── Workspace C ── API keys

The account is the billing entity#

Balance belongs to the account, not the workspace. There is one for the personal account and one for each organization. They are independent and cannot be transferred between each other.

Charges always follow one path:

API key → its workspace → that workspace's account → deducted from that account's balance

So "whose money does this call spend" depends only on which key was used. Decide the billing owner before adding credit; see accounts, organizations, and workspaces.

The workspace is an isolation unit, not a billing unit#

Workspaces express team, department, or project boundaries. Several workspaces under one organization share that organization account's balance while keeping separate members, keys, usage, and logs.

A personal account has exactly one workspace. It cannot be added to, removed, or shared with others.

The API key is where a call begins#

A key is the calling identity: anyone holding it can make calls in your name and incur charges. Four kinds of constraint can be configured on a key:

See API keys.

Model and provider are two dimensions#

A model is the unit of capability, identified by a canonical ID in the form vendor/model (for example anthropic/claude-opus-5).

A provider is the entity serving that model. The same model is often offered by several providers, with different prices, context lengths, supported protocols, and supply tiers. The catalog lists every provider's price for each model.

Protocol is a third, independent dimension. It determines the wire format and endpoint address and is unrelated to the target model: you can call Claude with the OpenAI SDK, or Gemini with the Anthropic SDK.

Every call makes one choice along each of the three:

Protocol (your client decides) × model (you specify) × provider (routing decides, or you pin)

For how providers are chosen, see routing and failover; for what the supply tiers mean, see providers and supply tiers.

Credit is tracked in lots#

Top-ups, promotional grants, and subscription allowances each form a separate lot, recording its own amount, type, and expiry. Charges consume them in a fixed order:

Promotional credit → subscription allowance → paid credit

Within a type, lots expiring sooner are consumed first. This order keeps refundable paid credit intact for as long as possible. See balance, credit, and consumption order.

The full path of one call#

Client
  │  sends an API key to the endpoint for its protocol
  ▼
Authentication ── checks key status, spend limits, model allowlist
  │
  ▼
Routing ── merges account / key / request configuration, orders candidate providers
  │
  ▼
Upstream call ── on failure, moves to the next candidate (failed attempts are not billed)
  │
  ▼
Billing ── deducts from the account balance at the serving provider's itemized rates
  │
  ▼
Recording ── writes the call log and usage aggregates

Routing's three-layer merge is the step that raises the most questions; it is covered separately in routing and failover.

Related#

• Quickstart
• Accounts, organizations, and workspaces
• Roles and permissions
• Billing overview