Skip to content

A1 / Capacity economics

How to use more of the Claude Code and Codex capacity your company already pays for

Use more paid AI capacity by moving prepared work—not accounts or allowances—to authorized teammates, then separate recovered output from real cash savings.

  1. 01Prepare the brief
  2. 02Pair human + agent
  3. 03Verify the outcome

Most companies buy AI access person by person. The work, however, does not arrive evenly.

On a ten-person team, some people may have deep queues while other authorized teammates have room to take suitable work using the tools assigned to them. The company has already bought access for all ten people, yet an urgent task can still wait at the desk where it first arrived.

That mismatch was the original Wagglet problem. The answer is not to share an account, pass around an API key, move an allowance, or disguise one user as ten. The answer is to hand the work to another authorized teammate, with enough context for them and their own agent to finish it responsibly.

This sounds like a small scheduling improvement. In a team that does a lot of agent-assisted work, it can become a meaningful operating advantage. It can also be worthless—or even counterproductive—if the tasks do not transfer well. The only honest way to know is to measure it.

Move the task, never the account

The useful unit in Wagglet is a prepared task:

  1. An author writes the desired outcome, constraints, relevant project context, and acceptance criteria.
  2. The task carries detailed instructions for the coding agent and separate guidance for the human runner.
  3. A teammate who has the right access, judgment, and provider capacity claims it.
  4. That teammate runs the task while signed into their own Claude or OpenAI account, supervises the agent, and records the delivery.
  5. A reviewer accepts the outcome or sends it back with specific feedback.

The handoff does not transfer a provider login, personal API key, subscription, allowance, or token balance from one teammate to another. Wagglet does not configure, proxy, or control the provider. The task actually changes hands; the account does not.

The same teammates could coordinate this handoff by talking. Wagglet formalizes that ordinary team-level work allocation with context, supervision, delivery evidence, and review. OpenAI's account-sharing policy says an account is for the individual who created it, so a different teammate uses a different authorized account.

Customers must follow their provider's current terms and plan rules—such as Anthropic's commercial terms or OpenAI's Services Agreement—and Wagglet does not claim provider approval for this workflow.

There are three different kinds of value

Teams often mix three numbers together and call the result “savings.” That produces impressive slides and bad decisions. Keep them separate.

1. Recovered output from a sunk seat cost

If authorized teammates can complete fifteen suitable handoffs using tools the company already bought for them, the team recovered fifteen outcomes from its existing tool budget.

That is real operational value. It is not automatically cash saved. If the alternative was simply to let those tasks wait, no provider invoice disappeared.

2. Avoided incremental provider spend

There is a cash effect only when the company would otherwise have bought additional usage: API tokens, provider credits, a temporary upgrade, or another paid seat.

For example, if comparable overflow work has historically cost $24 per accepted task through an API, and a Wagglet handoff replaces fifteen of those purchases, the gross provider spend avoided is $360. If the company would not really have made that purchase, the honest number is $0.

3. A defensible change to the seat mix

A longer pilot may reveal that some people need premium seats while others can work well on standard seats. That can support a procurement change at renewal time.

Do not assume this result. A light month is not proof that a person does not need a seat, and a seat may be valuable for work that never appears in Wagglet. Any downgrade or removal should be based on several representative periods, the person's actual role, provider terms, and a conversation with the person affected.

A ten-seat example with every assumption visible

The prices below are a dated illustration, not a Wagglet promise. As of August 16, 2026, Anthropic lists Claude Team at $20 per Standard seat per month on annual billing ($25 monthly) and $100 per Premium seat per month on annual billing ($125 monthly); Claude Code is included. OpenAI lists ChatGPT Business at $20 per user per month on annual billing ($25 monthly), with Codex included. Taxes, regions, negotiated agreements, included limits, and product terms can change these figures.

Assume a ten-person team already has ten Claude Team Premium seats on annual billing:

InputExample assumptionWhat the team must measure
Existing seat bill10 × $100 = $1,000/monthActual invoice, taxes, discounts, seat types
Candidate tasks observed40/monthTasks with a business reason to reassign or compare with paid overflow
Tasks safe and practical to hand off60%Permission, access, risk, context, and skill checks
Available handoff slots with teammates20/monthCurrent tool readings, teammate availability, and plan rules
Accepted completion rate75%Accepted outcomes, not merely claimed or delivered tasks
Human coordination per attempt12 minutesAuthor, runner, and reviewer time
Loaded value of that time$60/hourThe company's own planning rate
Comparable API usage per accepted task4M input + 0.8M output tokensHistorical usage for genuinely comparable work

The workflow model is:

eligible handoffs = 40 × 60% = 24 tasks
attempted handoffs = min(24 eligible tasks, 20 available slots) = 20
accepted outcomes = 20 × 75% = 15
coordination time = 20 × 12 minutes = 4 hours

For the cash comparison only, suppose those accepted tasks would otherwise have run through Claude Sonnet 4.6 at the current published base rate. Anthropic's API pricing lists $3 per million base input tokens and $15 per million output tokens for that model:

illustrative API cost per task = (4 × $3) + (0.8 × $15) = $24
gross provider spend avoided = 15 × $24 = $360
coordination opportunity cost = 4 × $60 = $240
illustrative net economic benefit = $360 - $240 = $120/month

What did not change? The $1,000 seat bill. This example recovered fifteen accepted outcomes, conditionally avoided $360 of provider spend, and produced a $120 estimate after valuing coordination time. It did not save $1,000, cut the subscription bill, or create a universal multiplier.

It can also produce a negative number. If the handoffs require more supervision, the completion rate is lower, or the company would have waited instead of buying API usage, the financial result shrinks or disappears. That is valuable pilot information, not a failed marketing story.

For a Codex-based cash comparison, use the same structure but insert the company's real paid credit price and comparable-task consumption. OpenAI's current Codex rate card maps model input, cached input, and output tokens to credits and warns that consumption varies with the model, task, reasoning, and execution mode. A fixed “Codex task equals X dollars” assumption will age badly; invoice and usage exports are better inputs.

Why an allowance percentage is not enough

Subscription limits are not interchangeable buckets of generic tokens. Claude says usage depends on conversation length, model, features, and activity across Claude surfaces; Codex says task size and complexity change consumption. A display that says “40% remaining” does not prove that a particular multi-hour task will fit.

Wagglet therefore treats a reading as scheduling context, not a promise, shared pool, or extension of anyone's allowance. A teammate can record which provider subscriptions they have, and “Up for grabs” can suggest work matching a task's preferred provider. When an employee explicitly opts into Wagglet Scout, the team can also see recent provider quota observations and reset times. Missing data remains “no reading yet”; it is not converted into imaginary free capacity.

The runner still decides whether the task is appropriate and whether they can supervise it. The task author still decides what context may leave their hands. The reviewer still decides whether the result is good enough.

Which tasks transfer well

The best early candidates have a bounded outcome and a clear way to verify it:

  • reproduce a bug and add a regression test;
  • update a contained UI flow against a supplied reference;
  • prepare a report from an approved source set;
  • run a defined sanity-check matrix and attach evidence;
  • make a narrow refactor with explicit invariants;
  • write or improve documentation against current product behavior.

Poor candidates include work that depends on an unspoken mental model, non-transferable credentials, private data the runner may not access, a high-stakes decision outside the runner's competence, or a task whose only success criterion is “make it better.” A strong agent prompt cannot repair an unauthorized or fundamentally ambiguous handoff.

The teammate must also be a real participant, not a pair of hands hired to press Enter. They need enough context to notice a dangerous instruction, answer routine agent questions, stop when the task leaves scope, verify the result, and explain what happened.

Run a pilot that can prove the idea wrong

A useful capacity pilot can be small: ten people, two weeks, and perhaps twenty deliberately chosen tasks.

Before it starts, record:

  • the seats and seat types already paid for;
  • observed tool utilization, available readings, and teammate availability;
  • overflow API, credit, upgrade, or overtime spend;
  • how long eligible work normally waits;
  • which work and data each teammate is permitted to handle.

For every handoff, record:

  • why the task was eligible;
  • who authored, claimed, and supervised it;
  • which provider and seat type were used—never the credential;
  • whether it was delivered, accepted, rejected, or abandoned;
  • measured coordination and review time;
  • rework, defects, and any paid overflow actually avoided.

At the end, report all three outcomes separately: accepted work recovered, incremental provider spend avoided, and any seat-mix decision supported by the evidence. Include the tasks that failed to transfer. Otherwise the pilot teaches the team to optimize a dashboard instead of its work.

The point is flow, not filling every meter

I do not want Wagglet to turn people into quota-consumption machines. Unused capacity can be the correct result: someone may be doing deep non-agent work, preserving focus, protecting sensitive context, or simply have no suitable task to take.

The opportunity is narrower and better. When valuable work is queued in one place, another qualified teammate can legitimately take it on using their own tools, and the task can be transferred safely, the company should not lose the moment because its project system cannot move context.

Move the prepared task. Keep every account and allowance with its owner. Measure accepted outcomes, actual spend, and human overhead. If the numbers work, expand carefully. If they do not, keep the evidence and change the workflow.

To evaluate the mechanism itself, see the complete Wagglet workflow and the Dual Prompt's authorization boundaries. A capacity pilot should begin only after the team agrees on provider terms, access, measurement, and review.