Accounts, usage, and budgets
Three separate things live near each other here and are constantly confused: the accounts your agent CLIs log in with, what has been spent, and the caps that bound future spend.
Provider accounts
Save, relabel, reauthenticate, switch, and remove Claude and Codex logins, with subscription-window polling so you can see how much of a window is left. Only authentication is copied, and switching is always an explicit act you take.
This is for one person switching between accounts they personally own and pay for, replacing the logout and login cycle the provider CLIs otherwise require. It is not account pooling and not a way around a usage limit: accounts are never shared between people, credentials stay local and go nowhere but the provider's own endpoints, and sessions are never load-balanced across accounts.
mux accounts # what is saved, and which is active mux accounts verify # re-verify each saved identity mux accounts audit # the credential audit trail
The three pots, and why they are never summed
| Pot | What it is | How exact it is |
|---|---|---|
| Agent spend | What your agent CLIs used, on your subscription. | An estimate. It is reconstructed from transcripts, because a subscription CLI reports no price per call. |
| Automation spend | What swe-mux's own model-backed features used, on your metered key. | Metered, billed by the call, and exact where the provider reports a cost. |
| Provider quota | How much of a provider's rolling window is left. | Not money at all. A share of a window. |
No surface computes a total across them, and every figure carries the basis it was drawn on. A number without its basis is the bug, not a missing feature: adding an estimate to a metered charge and calling it a total produces a figure that is wrong in a way nobody can see.
Agent spend itself has two denominators - one over every transcript on the machine, one over only the runs swe-mux observed - so the subset is labelled by its denominator everywhere it appears and is never presented as the agent total.
Where a model call goes
Every model setting is edited in one place: Settings, Accounts, Models. Each feature tab keeps a read-only row naming the model it resolved to, with a link back to that editor.
The reason they are together rather than beside the features they configure is that changing endpoint is the operation that touches all of them at once. Split across four tabs, that operation meant four tabs of hunting to find out whether anything had broken, with no screen anywhere answering "what does this install call, and does the endpoint I just switched to even have it".
A blank value is not always legal, and the two cases must never look the same. An override left blank falls through to the cheap model. A pin left blank is refused by the control.
Budgets
A cap is {tokens, dollars, mode}, edited through one control, per feature. Both axes exist because a dollar cap cannot bind against a provider that reports no cost - absent cost is unknown rather than zero, so the ledger records it as unmeasured, totals drawn over it read as a floor, and the token axis is the honest backstop.
What reaches the network, and what does not
Your agent CLIs contact their own vendors under your own subscription. swe-mux proxies nothing and resells nothing, and it is not in the execution path between the CLI and its vendor. Where data lives lists every request swe-mux itself can make.