One person is capped. The work does not have to stop.

A developer is midway through a change. The branch is pushed, the failing case is understood, the next step is obvious to them and to nobody else. Then the agent stops: the usage window is spent. The task is not blocked on knowledge or on review. It is blocked on one person's allowance, and it stays blocked until that window resets.

Teams reach for three answers. Wait for the reset, which costs the rest of the day. Buy credits, which turns a scheduling problem into a recurring bill. Or share a login — which breaks the provider's terms and puts one person's account behind someone else's work.

This page is the answer to that question, and the word carrying the weight in it is legitimate. The prepared task moves. Nothing belonging to an account moves with it.

1. 01

   The author prepares the task once

   The work carries LLM instructions for the agent and Human instructions for whoever supervises the run, with scope, constraints, evidence and stop conditions settled before anyone claims it — the shape the Task Handoff guide sets out. A task too vague to hand over is a specification problem, not a capacity problem, and moving it will not help.

2. 02

   The team can see who has room

   Wagglet reads provider usage from each person's own machine and shows it per teammate: which limit window is in use, how much of it is spent, when it resets, and which plan reported it. Any member of the same Team can see it.

3. 03

   A qualified teammate claims it

   Claiming is governed by permission and skill — who may access the work and who can judge the result. The teammate chooses the task; Wagglet does not assign it to them. Seeing that someone has capacity and deciding they should take this particular task are two different judgements, and the second one stays with a person.

4. 04

   They run it on their own account

   Their own Claude Code, Codex or Cursor subscription, their own session, their own identity. The author's provider relationship is not involved at any point.

No automatic routing

Wagglet does not assign work by remaining quota. Capacity is visible; the claim is a person's decision. There is no scheduler matching tasks to the teammate with the most headroom.

No shared quota

Nothing is pooled, combined, transferred or extended. Each person's plan stays their own, and a capped teammate stays capped.

No provider cost saving

Moving work does not reduce what anyone pays a provider. No subscription is cancelled, downgraded or shared, so the bill is the same either way.

What Wagglet collects is the provider's own rate-limit reporting: which limit window is in use, the share of it spent, when it resets, how fresh the reading is, and the plan the provider named. That is the whole of it.

Prompts, conversations, file contents and the work an agent performs are not collected and are not part of this view. Knowing that a teammate's weekly window is nearly spent tells you nothing about what they used it on.

Does Wagglet pool or transfer AI provider quota?

No. Each teammate keeps their own provider account, subscription, credits, and limits. Wagglet moves only the prepared task.

Does Wagglet automatically assign work to whoever has capacity?

No. Provider usage can be visible to the team, but an eligible teammate chooses whether to claim a task. Wagglet is not a quota-based scheduler.

What happens when every teammate has reached their limit?

There is no spare execution capacity to use. The team must wait for a reset or change its provider plan; the handoff workflow cannot create quota.

• Tasks are not specified well enough for anyone else to run. The bottleneck is specification, and a handoff workflow will expose that rather than fix it.
• Only one person can judge the result. Moving execution does not move the judgement the work requires, and a delivery nobody qualified can accept is not progress.
• Everyone reaches their limit at the same time. There is no spare capacity to move work to, and the honest answer is a larger plan, not a workflow.