← All articles

Two clocks, one queue: moving agent work when a subscription limit closes

The Guildwise HQ team · 7 November 2026 · 5 min read

• How-to
• AI agents

Start with the clocks, not the logins

When an agent hits a usage limit, the quickest fix looks like switching to another login. That fix creates more risk than it removes. A limit belongs to one account, and each account has rules about who may use it. The useful question is how to move work across accounts your team is entitled to use, and how to pause work cleanly when none of them has room.

The starting point is the clocks. Anthropic's help documentation for paid Claude plans describes usage limits that reset on a schedule, and it describes usage credits that let a person continue after included limits are reached. Community guides for Claude describe a rolling session window of about five hours and a weekly allowance. Those two numbers do not reset together. Check the usage page for each account rather than relying on a guide, because limits have changed during 2026.

Codex follows a similar two-window pattern in community write-ups. A community guide on Codex usage limits describes two windows with different reset behavior. Treat that as a working model to verify on your own account, not as a provider specification.

The practical consequence is that the clocks run separately. A weekly allowance can be exhausted while the short window is fresh. In that case, waiting for the short window to reset does not unblock the agent. Your routing rule has to read both numbers before it decides where a task goes.

What the terms allow

Anthropic's Consumer Terms of Service say an account holder may not share login details, API keys or account credentials with anyone else. They also say the account may not be made available to anyone else, and that the holder is responsible for activity under the account.

That rule matters for agent teams. A shared Claude login used by several people, or by several pipelines run by different people, falls outside the consumer terms. The same terms say an account can be suspended or ended if the terms are breached.

Holding more than one account is a separate question from sharing one. Some practitioners describe a team pattern in which each person signs in with their own account and connects their own agent command-line tools. Treat that as a practice note, not as a legal reading. Confirm the current wording for each provider before you design a routing rule around several accounts.

Sanctioned overflow paths

The safest way past a limit is a route the provider documents. For Claude, Anthropic's help center describes usage credits on paid plans. Usage continues against those credits after the included limits are reached, and each run costs more than included usage.

Overflow routes need the same discipline as any other spend:

• A named approver who can authorize overflow for a specific task or batch.
• A monthly ceiling per team, set before the month starts.
• A record that ties each overflow run to the task it completed.

These routes keep every run tied to an account that a specific person owns. That is the main reason to prefer them over borrowed logins.

A routing rule that keeps credentials where they belong

Use this checklist when you split agent work across accounts:

1. Give each account one owner. That person runs the sessions on that account, and nobody else signs in with it.
2. Route by task class, not by who is free. For example, send long multi-file refactors to the account with more weekly room, and send short review tasks to the lighter account. Keep the route table in version control so changes are visible.
3. At the start of each batch, record the remaining allowance and the next reset time for each account. Read these from each provider's own usage page.
4. When a limit message appears, the agent writes a pause record before it stops. The record names the task, the branch, the last passing check, the files still to change and the next step.
5. Resume only in a session owned by the person who holds that account, or on an approved overflow route.
6. Never move a half-finished task onto another person's login to keep it moving.

The pause record is what makes the queue work. Without it, a resumed agent has to rediscover what it already did, and it may repeat or contradict earlier changes.

Example: a weekly cap hits mid-refactor

The following scenario is hypothetical and shows how the rule plays out. A small team has two personal subscriptions, each owned by a different engineer, and one overflow budget reserved for urgent work.

On a Monday afternoon, the owner of the first account reaches the short window partway through a refactor. The agent writes a pause record. It lists the branch, the last test run that passed, the three files still untouched and the first step to take on resume. The task returns to the queue with its status set to paused.

When the window resets, the same owner's session picks up the record. Later in the week, the weekly allowance runs out on that account. The task waits, because the team has not approved overflow for it. On Thursday, a release deadline makes the case for overflow. The team lead approves one overflow run under the ceiling, and the record tells that run exactly where to start.

The example shows three decisions that the routing rule makes in advance: which account owns the work, when overflow is allowed, and who approves it.

Keep overflow spend under a ceiling

Set a monthly ceiling per team for credits and other overflow runs. When a run would cross the ceiling, the agent stops and writes the pause record instead of continuing. Review overflow spend each week against the tasks it completed. A task that needed overflow every week is a signal to change the route table or the plan, not a reason to raise the ceiling.

Key takeaways

• Plan around two limit clocks. A short window and a weekly allowance can run out at different times, and a fresh window does not fix an exhausted week.
• Do not share logins. Consumer terms prohibit sharing an account's credentials or making the account available to others.
• Use documented overflow routes, such as usage credits, with a named approver and a monthly ceiling.
• Write a pause record whenever a limit stops work, so the next session resumes from the record and not from memory.
• Route tasks by class and owner, and keep the route table in version control.

This article was written with AI assistance and researched from the sources listed.

Sources

1. Consumer Terms of Service
2. Manage usage credits for paid Claude plans
3. How Codex usage limits work: two windows, three kinds of reset - DEV Community
4. How to Run Multiple Claude Code Accounts (2026)

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.