It's Wednesday afternoon. You're halfway through something good, and the message arrives: you've hit your weekly limit, and it resets in a few days. Everything you'd set up assumed Claude would be there.
First, what Frontier can't do. It can't raise your limit or get around it. That's between you and Anthropic. It won't notice the limit and switch tools for you either. What it can do is make the switch one setting instead of a migration, and help you stop spending your allowance on work that never needed it.
Move a workspace, not your whole setup. Frontier runs Claude Code and Codex CLI through the same connector layer, and both are verified end to end. Your workspaces, Agents, memory and Frontier's own tools work the same through either one. There's a global default, and each workspace can override it from its own Settings tab. Change the default and everything moves to Codex. Override one workspace and just that project moves. Past conversations stay exactly as they were, and only new runs use the new connector.
If you haven't set Codex up yet, it's one pass through Settings → Connectors: tick the Codex card in Quick Setup (it lights up once the `codex` CLI is installed) and apply. Frontier installs the session hooks and registers its tools with Codex. Then open any `codex` session and run `/hooks` once to approve them.
Start a fresh thread when you switch mid-task. A conversation's session belongs to the CLI that started it, so don't keep typing into last week's Claude thread and expect Codex to pick it up. Open a new thread in the same workspace with a short, self-contained brief: what's done, what's left, and what to watch out for. The code is already there, because the worktree and its branch don't care which CLI touches them next. The brief carries the intent. It's the same discipline a good handoff between two people needs, and it tends to produce a better next step than a long, tired conversation would.
Find out where the allowance actually went. In an agent setup, a lot of it is rarely the building. It's the checking. A watcher that fires every ten minutes is a model run every time it fires, around the clock. The Audit Trail in Settings lists every run each Agent made, with how long it took, and it's usually obvious within a minute which one is the noisy neighbour.
Then there are three dials to turn, cheapest first.
Check less often. Every Agent's interval can be set per workspace. A watcher that doesn't need to look every ten minutes can look every hour. An Agent on the `unread` trigger runs only when a thread has a new message, so it costs nothing on a quiet day.
Decide in code, not in a prompt. With the `trigger` mode, a short script decides per thread whether the model runs at all. "Has anything changed since last time?" is often a question a few lines of code can answer, and a script that answers it without calling a model spends none of your allowance.
Put the small judgments on your own machine. Frontier can install an open model from Hugging Face and run it locally. It's a real connector: it runs threads, backs Agents, and answers the model calls inside Agent scripts. Because it runs on your hardware, it uses none of your Claude or Codex allowance, and it doesn't count against your Frontier plan's daily runs either. Each workspace has a Script Model setting, so a loop's constant small questions (is this in scope, is this worth writing up) can go to the local model while the workspace itself keeps building through Claude or Codex. Be realistic about it: a model small enough for a laptop is good at reading, sorting and summarising, and weaker at long multi-step code edits. Give it the watching, not the building.
Put together, a split that holds up through a heavy week looks like this. Claude stays on the one or two workspaces where the hardest building is happening. Codex takes the reviewers, the second attempts and the side projects. That's also a good shape any week, since a reviewer on the other CLI reads the code with fresh eyes. The local model takes the watchers and triage loops that tick all day. When your limit resets, flip the defaults back, or don't. Some people find the split is simply how they want to work.
Two things to be straight about. Codex has usage limits of its own, so splitting spreads the load and doesn't make it unlimited. And in Frontier, runs through Claude or Codex count against your plan's daily run limit, while local models don't. If you plan to run agents overnight, choosing which workspaces run on what before you go to bed is worth more than any single prompt tweak.
The point isn't to work around a limit. It's that a limit on one tool shouldn't become a limit on what you can build this week.
Q: Does Frontier switch to Codex automatically when I hit the Claude Code weekly limit? A: No. Frontier doesn't detect the limit. You switch by changing the global default connector, or one workspace's connector override, which takes a single setting.
Q: Do my workspaces and agents keep working if I move them from Claude Code to Codex? A: Yes. Workspaces, Agents, memory and Frontier's MCP tools work the same through both connectors. Start a fresh thread after switching, since an existing conversation's session belongs to the CLI that started it.
Q: How can I use less of my Claude Code allowance on background agents? A: Check the Audit Trail for the Agents running most often, lengthen their interval, gate them with a trigger script so the model only runs when needed, and move small classification or triage work to a local model.
Q: Do local models count against any limit? A: They don't use any Claude or Codex allowance, since they run on your own machine, and they don't count against a Frontier plan's daily run limit.
If you'd rather start from a setup that's already split this way than build one mid-crunch, browse the example setups and install one in a click. New to Frontier? Download it and have Codex set up before the next reset.