Why a team uses more tokens
Most tools point a single AI agent at your whole task. Castforge runs a small team instead, and a team uses more tokens than one agent. That is expected, and it is worth understanding so you can decide when the extra work is worth it.
There are two main reasons:
- Each role is a separate teammate. A Lead, a Coder, a Reviewer, and any other role you add are each a separate agent that reads the task and works in its own context. Where a single agent reads the task once, a three role team reads and reasons about it three times, once per role, plus the handoffs between them.
- Review loops add back-and-forth. When the Reviewer can request changes back to the Coder, the work goes around again: the Coder revises, the Reviewer re-checks. Each round is more work, so the review loop pushes usage up a notch.
On Claude specifically, programmatic runs draw from your capped Agent SDK credit first, then from standard API rates once that credit is used. A team that does more work draws from that credit faster than a single agent would. This is the same billing context shown on the Claude card when you connect it.
The intensity indicator
When you set up a team, Castforge shows a relative intensity indicator: Token use: Light, Moderate, or Heavy, with an approximate range like "~2-3x a single agent for the same task".
A few things to keep in mind:
- It is relative and approximate, not a measured token count. The "~Nx a single agent" framing compares a team to a single agent doing the same task, as a rough expectation, not a precise number.
- It varies by project. A small change costs far less than a large feature, whatever your team looks like. The tier sets an expectation; it does not promise a figure.
- It rises with the team. Roughly, one role reads Light, a small team reads Moderate, and a larger team reads Heavy. Turning the review loop on bumps the tier up one notch, because the Coder and Reviewer iterate.
The indicator sets expectations up front, so a bigger token bill is never a surprise. It does not change what your team does; it just tells you, before you start, that more roles means more work.
How to spend less
If you want the same outcome for fewer tokens, these are the levers, roughly in order of impact:
- Use fewer roles for small tasks. A solo Coder is plenty for a quick fix or a small change. Add a Lead, a Reviewer, a Tester, or a Researcher when the task is large enough to benefit from the structure.
- Put a cheaper model on the Lead and Reviewer seats. Each seat picks its own model. A planning or reviewing role often does fine on a cheaper model, while you keep your strongest model on the Coder. A cheaper model changes the cost per token, which is a real saving even when the token count is the same.
- Turn the review loop off for small work. The "Reviewer can request changes back to Coder" rule is the single biggest driver of extra rounds. Turn it off when the work does not need a second pass, or cap the number of rounds (1 to 5) so it cannot run away.
- Prefer Careful or Balanced over Autonomous. More autonomous modes do more on their own, which can mean more turns. The round cap already guards runaway review rounds, but a more conservative mode keeps you in the loop and keeps the work focused.
A good rule of thumb: start small, and add roles or turn on the review loop only when the task is big enough to earn them. You can change any of this at any time, both when creating a project and later in the project's Agents and roles settings.
What each agent actually reports
Castforge records a token figure at the end of every turn, and the figure is whatever the agent's own CLI hands back. The agents do not all hand back the same thing, which is worth knowing before you compare two seats.
A note on where you see this today: the "Usage and costs" view and the usage card are still gated off during the beta, because the through-Castforge telemetry was not trustworthy enough to show. The numbers below are what gets recorded per turn. They are what those views will report when they come back.
Claude reports a genuine per-turn split: how many tokens went in on that turn, how many came out, and a cost. That is the shape most people picture when they read "token usage".
GitHub Copilot, and Gemini when it runs over the agent protocol, report something different. Their protocol has no per-turn split to give. What it sends instead, part way through a turn, is the session's context window occupancy: how many tokens are currently sitting in the conversation's context, out of the total the model can hold. A typical reading is something like 18,750 of 200,000.
Castforge records that occupancy figure as the turn's input tokens, because it is the closest honest number the protocol offers, and leaves output tokens at zero rather than inventing a split the agent never sent. So on a Copilot seat:
- The input token figure is context occupancy for the whole session, not the size of that one turn's prompt. It grows through a conversation as context fills, and it does not reset each turn.
- The output token figure stays at zero. That is not a measurement of nothing; it means the agent did not report one.
- A cost figure appears only when the agent reports one in US dollars. Castforge does not convert currencies, so an amount reported in anything else is left out rather than relabelled.
Two practical consequences. First, do not add a Claude seat's tokens to a Copilot seat's tokens and read the sum as a total; they are different quantities. Second, a Copilot number that climbs across a long conversation is context filling up, which is normal, not a sign that one turn got expensive.
Before this was wired up, a Copilot seat recorded zeros across the board. If you are looking at an older project and every Copilot figure is zero, that is why.
The spend cockpit
The intensity indicator sets an expectation before you start. The spend cockpit is the other half: what a run is actually spending while it runs.
It has two parts. In the workspace right rail there is a compact Spend card carrying the run's total tokens, a dollar figure where one applies, and a small per-seat bar showing which roles the tokens went to. Clicking the card opens the spend drawer, which carries the full breakdown. The drawer closes with Escape, or by clicking the dimmed area beside it.
Both are scoped to the current run in the current project. This is not a lifetime total and it is not a figure for your whole account.
What each figure means
Spent is the measured total for this run: every token recorded on a finished turn, input and output together. It is a measurement, not a forecast.
Projected is an estimate. Castforge takes the rate it has measured so far in the current phase and applies that rate to the cards still left in the phase. The drawer says so on screen, in these words: Estimated from the measured rate so far across the cards left in this phase. Not yet spent. If no card in the phase has finished with recorded usage yet, there is no rate to project from, and the drawer says that rather than showing a number.
Per verified card is tokens spent on work that was actually checked. Cards still waiting on verification, and cards that failed it, are left out on both sides: their tokens are not in the total and they are not in the count. It is the closest thing the cockpit has to a figure for finished work, and it is deliberately stricter than dividing the run total by the number of cards.
By seat attributes the run's tokens to the roles that spent them, as a stacked bar with a legend. Each seat keeps its own colour from the role palette, so a role reads the same colour here as it does everywhere else in the app.
By phase shows each phase on the board with its measured spend beside the estimate band for its quality tier, so the two sit together rather than one replacing the other. Spend reaches a phase row through the board card each turn ran against. Turns that ran against no card are listed on a row of their own rather than spread across the phases, and a phase shows no actual until one of its cards records usage.
A phase can run under a different quality tier from the rest of the project. Where it does, the estimate band on that row comes from the phase's own tier rather than the project default, which is why two rows can legitimately show different bands.
Which figures are estimates
Two of them, and the drawer labels both.
Projected is an estimate, as described above. The per-phase estimate band is the same quality-tier range the intensity indicator uses, which is relative and approximate rather than a measured count.
Spent, per verified card and the per-seat split are all measurements of tokens that were really recorded.
What the dollar figure is, and who is charging you
Castforge does not charge you for model usage. You pay Castforge for the workspace, and you pay each provider directly for what their models do. Castforge never adds a margin to model usage and never resells it, and the two are never added together into a single number.
That separation decides what the cockpit shows:
- On a seat connected with your own API key, the dollar figure is the cost the provider itself reported for that usage, added up across the run. Castforge does not apply a rate card of its own to a token count; it records what came back. So the figure is a real estimate of what that seat is spending with your provider, which is the visibility a bring-your-own-key setup is meant to give you.
- On a seat signed in through a subscription, the drawer shows no dollar figure and says the usage is included in that plan. Inventing a number there would describe a charge that is not being made.
On Claude this sits on top of the billing context described near the top of this page: a programmatic run draws from your capped Agent SDK credit first, then from standard API rates. The cockpit is the same story at the level of one run, reported by the provider rather than worked out by us.
A seat whose agent does not report usage shows a line saying it is not reported by that agent, rather than a zero. That is the same honesty the previous section describes for the weekly card, and it now applies to the per-seat bar too: a zero would read as a measurement of nothing, when the truth is that nothing was measured.
The soft ceiling
You can set a spend ceiling for a project from the drawer. It is set in tokens rather than in dollars, because tokens are the one unit that means the same thing on a subscription seat and a bring-your-own-key seat alike.
It is a soft ceiling. When the run reaches it, Castforge stops at a safe boundary between pieces of work and asks whether to continue or to stop for now. It does not cancel a turn that is already running and it does not drop queued work, so whichever you choose, nothing is thrown away. The drawer states the same thing before you set it: Castforge pauses the run at this point and asks before going further. Nothing is cancelled and no queued work is dropped.
The ceiling belongs to the project, so it applies to whatever run is going in that project, and it is still there after you close and reopen the app. Leave the field empty for no ceiling, and the drawer says the run keeps going until you stop it.
Choosing to continue picks the held work back up under the same run. Choosing to stop leaves that work held rather than discarding it, so you can come back to it later.
The pause card carries a third choice: turn off the ceiling and continue. That one clears the ceiling for the project before it picks the work back up, so the run will not stop at that figure again. It is on the card itself rather than only in the drawer, so a ceiling you set earlier can always be turned off from the place you are asked about it, even on a build where the drawer is hidden.
If you type a figure above one billion tokens, Castforge stores one billion instead and the note under the field tells you so. One billion is already far above anything a single run reaches, so a ceiling higher than that would mean never pausing at all.
Where to find it
The cockpit is not on every build yet. The token counts underneath it are still being corrected, so the Spend card and the drawer sit behind the same visibility gate as the weekly usage card, and they are hidden wherever that card is hidden. The reason is the one the previous section gives: rather than show a figure that is not yet trustworthy, this readout waits until the recording underneath it can be relied on.