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 exists to set expectations honestly, 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.