AI usage limits
What happens when a device's Claude subscription plan hits its usage window, how CodeHerder recovers automatically, and how to keep work moving before the reset.
If your workspace runs agents on a subscription-based AI plan (such as a Claude Max or Pro plan), that plan has a usage window that can fill up. This page covers what CodeHerder does when that happens on a device, and what you can do about it.
For how to view the usage meters themselves, see AI limits in Managing your devices.
What happens when a plan hits its limit
CodeHerder only reacts to one signal here: a Claude subscription usage window reaching 100% utilization before it has had a chance to reset. Usage from other AI providers is shown for visibility but never pauses placement — only a Claude subscription window at 100% does.
When that happens, CodeHerder stops routing new work to that device — for every agent on it, regardless of which coding-agent CLI (harness) each one runs. The pause is per device, not per agent or per harness: an agent using a different harness on the same device is paused too, because the device itself is the thing withholding capacity.
Sessions already running are not affected — only new placements pause. The device’s Online and healthy status do not change; the only visible signal is a usage meter at 100% in the device’s AI limits section.
It recovers on its own
There’s nothing to do here. Once the window resets, the device server picks that up on its next usage check (typically within about five minutes of the reset) and CodeHerder resumes placing new work on the device automatically. Tasks that were waiting during the exhaustion window start without any manual action.
Keeping work moving before the reset
If a workflow stage’s Assignee is left on Auto — best fit (the default — see Assigning and claiming work), CodeHerder already tries every eligible agent and device when placing a task. If a second device is Online, healthy, not itself exhausted, and has an assigned, approved agent with the capabilities the stage requires, that task is placed there automatically — you don’t need to do anything.
The one case that needs a manual nudge: if the stage’s Assignee is pinned to a specific agent, and that agent only runs on the exhausted device, CodeHerder will keep waiting for that agent rather than trying anyone else. Re-pin the stage to an agent on a different, non-exhausted device from the Assignee dropdown, or clear the pin back to Auto — best fit, to get it moving again. See Assigning and claiming work for how to change an assignee.
Otherwise, your options are simply: wait for the reset, or make sure a second device with headroom is registered, linked to the workspace, and staffed with a capable agent — see Managing your devices for adding and sharing devices.
What won’t help
Reordering, disabling, or adding an agent’s launch configs does not clear this pause — it only changes which config runs next on that device, and selection never looks at live AI usage. Because the pause applies to the whole device, switching configs on the same exhausted device does not get work moving there again. If you want a different outcome, the change has to move the work to a different device — see above.
Related guides
- Managing your devices — view the AI limits meters, and register or link a second device
- Assigning and claiming work — pin a workflow stage to a specific agent, or leave it on Auto — best fit
- Why isn’t my task moving? — the full diagnostic flow, including this cause
- Agents and the CLI — how launch-config ordering and selection work
