A usage limit should not end your session.
Every provider stops you eventually, and Happier cannot change that. What it can do is hold the session at the limit, show you when it resets, and start the work again from where it stopped. Turn on “Always wait and resume” and it does the whole thing unattended — one setting, and you come back to a session that carried on instead of one that stopped. That is on one account. Own several subscriptions and there is a better answer below: pool them, and a session that runs one dry moves to the next.
With one account, Happier waits out the reset and resumes the session
A provider refuses a turn and Happier shows “Usage limit reached”, with the reset time when the provider supplied one. From there: wait — “Resume when limit resets” keeps the session and picks it up on its own — or “Check limit now” to re-probe, or stop waiting. Waiting is the one that keeps your afternoon: Happier holds the reset time, re-checks it for you, starts the session again if it had exited in the meantime, and sends a prompt to carry on from the interrupted context. Tick “Always wait and resume” once and you stop being asked — every limit after that is handled the same way with nobody watching. A Codex session goes one further and arms the wait by itself once “Continue automatically” is set.
That banner appears for Claude Code, Codex, OpenCode, Gemini and Pi. No other agent in the registry reports usage limits to Happier in a form it can act on, so what you get there is whatever the provider’s own CLI prints.
Pool the subscriptions you own, and the session carries on across them
A pool belongs to a connected service, not to an agent. A connected service is a kind of credential — a Claude subscription, a Codex subscription, an Anthropic or OpenAI key, a Gemini login — and a pool is a set of your own accounts on one of them. Which agent you run is a separate choice, made when you start a session.
So the same pool serves more than one agent. Claude subscriptions and Anthropic keys are consumed by Claude Code, OpenCode and Pi; Codex subscriptions and OpenAI keys by Codex, OpenCode and Pi; Gemini logins by Gemini. Build a pool of your two Claude accounts and it is there whether you open Claude Code, OpenCode or Pi that afternoon.
Nothing switches until you build a pool, and a pool is something you make on purpose: Settings → Connected services, open the service those accounts belong to, then Pools → Create pool, name it, and add the accounts you want in it. Until that exists, every session uses the one account you picked and stops when that account stops.
Once the pool exists it starts with automatic fallback on, for the services that can change account inside a running session. There is a toggle on the pool — "Automatic fallback" — and turning it off leaves you a pool you switch by hand, which is a reasonable way to run it if you would rather decide each time.
The defaults are deliberately unambitious. Happier falls back to another member, preferring whichever has the most quota left, at most once per turn and three times per session hour, with a thirty-second cooldown in between. When a provider says a limit resets at a particular time, Happier takes it at its word and does not treat that account as a candidate until then. A pool is a way to not lose twenty minutes to a re-login; it is not a rotation service, and the per-hour ceiling is there so it cannot quietly become one.
People often call this load balancing. What Happier does is narrower, and worth knowing before you pay for a second subscription: it does not spread work across your accounts to keep them level. Nothing moves at all while the account you are on still has room. The pool is there for the moment one runs out — the product calls it automatic fallback, and that is exactly what it is.
How a pool falls back: the account it picks, and how often
The defaults a new pool starts with. All of them are editable per pool.
| Setting | Default | Why |
|---|---|---|
| Which account it picks | Most quota left | Read from the last usage snapshot. A fixed priority order and fully manual are the alternatives. |
| What triggers a switch | Usage limit, expired auth, changed account | A failed token refresh does not, because a refresh usually fails for a reason another account will not fix. |
| Preventive switch | Below 15% remaining | Only when another member has fresher usable quota. Set it to 0 and Happier waits for the real limit. |
| Switches per turn | 1 | One turn cannot walk your whole pool. If the next account is also out, the session stops and says so. |
| Switches per session hour | 3 | A ceiling, not a target. |
| Cooldown between switches | 30 seconds | Stops one flapping provider response from producing a burst of account changes. |
| Provider reset times | Honoured | A member that a provider says is out until 4pm is not a candidate until 4pm. |
Which accounts you can pool, and which agents can use them
One row per account you can connect. Being able to use a pool and being able to change account inside a running turn are two different capabilities, and the second one is rarer.
| Account you connect | Agents that can use it | Switches mid-session | Quota meter |
|---|---|---|---|
| Claude subscription | Claude Code, OpenCode, Pi | Claude Code | Yes |
| Anthropic API key | Claude Code, OpenCode, Pi | Claude Code | No |
| Codex subscription | Codex, OpenCode, Pi | Codex | Yes |
| OpenAI API key | Codex, OpenCode, Pi | Codex | No |
| Gemini | Gemini | None | Yes |
OpenCode, Pi and Gemini can all be pointed at a pooled account and can move between its members, but not without the session restarting — so for those you are choosing the account before the session starts rather than during it. Every other agent Happier runs signs in through its own CLI and is not part of this at all.
GitHub is a connected account too, and it is the one that is not here: no agent runs on a GitHub token. Happier uses it to publish a repository or open a pull request, so it has neither a pool nor a quota meter.
Your own accounts, and what your provider’s terms allow
An account pool is for accounts you own. The shape of the feature is one person with several of their own logins — a personal Max subscription and a work Claude seat, a Codex subscription and an OpenAI key — kept visible and switchable in one place, instead of re-authenticating a CLI every time you run out.
It is not a way to put several people on one subscription. Provider terms — Anthropic’s and OpenAI’s alike — prohibit sharing a single subscription between people, and pooling does not change that: if you use it that way you are outside your provider’s terms, and no client can fix that for you.
We’re not lawyers, we give no guarantee, and provider terms change. Read them. If your organisation has an agreement with a provider, check it before you connect a work account.
Build a pool in the app, start a session on it from the CLI
Two accounts connected on the same service, one pool, and a check that the meter is reading. Building the pool is a job for the app — Settings → Connected services, pick the service, Pools — because no command creates one; happier connect signs an account in from a shell and stops there. Starting a session on a pool you have already built is the half that is in the CLI: happier --auth cs:<id> takes the id of a profile or a pool. There is a longer cs:group:<id> spelling for the case where a profile and a pool share an id and the short form cannot tell them apart.
Connecting the accounts comes first, and that part has a configuration reference: how each provider’s sign-in works, which agent can consume which credential, and where the quota snapshots come from.
A self-hosted relay can switch this off, and can switch quota meters off separately from pooling. If you are on someone else’s server and the Pools screen is missing, that is the server’s answer rather than a bug.