Quota and subscription switching
How OFM watches each subscription's quota window, keeps a reserve it never spends, and moves unattended work to another subscription you have already used on that project.
The scarce resource in OFM is not money, it is the quota window of the subscriptions you already pay for. Running out is not a bill that grows, it is a hard stop in the middle of a batch.
4.0.0 watches those windows, keeps a reserve it will not spend on its own, and — for unattended work — moves the next launch to another subscription when the usual one is spent.
The gauges
Every subscription you use gets a gauge on Mission Control’s permanent status bar: how much of the current window you have consumed, and the reserve drawn in at the end of it. A preserved quota is invisible by nature, so it has to be shown.
The gauges are always live, whether or not you let the quota influence routing.
The reserve
A share of every window is never spent by an automatic decision. Whatever the router does on its own, you keep something in hand for the task you did not see coming.
Only you can dip into it. When everything is spent, the router steps down one level, or parks a unit that can wait, and says so on screen.
Which subscriptions it may switch to
Only the ones you have already run yourself on that project, and that started properly. Nothing you have not used there is ever brought in.
- The scope is per project, never global. A repository where only Claude has ever run will never see Codex started on it.
- A provider whose model you pinned is never used as a fallback.
- If no fallback is eligible, the usual subscription is kept.
Choosing the fallbacks yourself
The eligible subscriptions for a project are listed as chips on the project header. One click excludes one, and the exclusion wins over everything the router observed and survives later launches.
Worth ten seconds on any project where you run unattended work, because your CLIs are not all paid the same way. Most run on a subscription: a quota window, nothing extra to pay inside it. A CLI you have pointed at your own API keys bills per token instead. If you would rather it never picked up an overnight batch on its own, untick it here and it never will.
Manual launches are unaffected either way — you always see the CLI before it starts.
Where switching applies
Switching is wired at one place: the orchestrator starting a unit, which covers batch work and recurring work turns. Both start a fresh session per unit, so changing CLI costs no context.
It does not apply to a tab you opened by hand, and never to a session already running. A reroute is written to the engine log, with the subscription that was spent and the one that took over.
It stays on your machine
Counters, eligibility and preferences live in your config directory and are never uploaded. See Data & file locations.
Frequently asked
- Does switching happen while a session is running?
- No. A switch only happens when a fresh session is started by the orchestrator or by a recurring job. A tab you opened by hand keeps the CLI you chose.
- Which subscriptions can the router switch to?
- Only the ones you have already run yourself, successfully, on that same project — and only those you have not excluded.