What is a user token, exactly?
A user token on ftes.ai is a unit of billed work. Every call a Digital FTE makes to a language model consumes real input and output tokens, and the platform debits three user tokens for each token of that real cost. The multiplier is a fixed platform mechanic rather than a negotiated rate, and it is the same for every organisation. A user token is therefore not a unit of model capability and does not correspond to a word; it corresponds to a share of the work the model actually did.
Because the unit is work rather than access, adding a colleague to the workspace changes nothing about the bill. Adding a scheduled sweep does.
How does the wallet behave at zero?
The wallet is checked before an AI call is made, not after. When the balance is insufficient the call is rejected and the interface says so, with the option to top up; it does not run the work and invoice for it afterwards. That is a deliberate design choice with a real cost — work stops — and a real benefit: a metered product cannot produce a bill nobody authorised. For a finance lead the practical consequence is that the maximum exposure in a period is the balance in the wallet.
Job handlers reserve against the wallet before long-running work begins and debit the actual usage when it completes, so a multi-minute sweep cannot start on a balance that cannot cover it.
The arithmetic: one run, with every input stated
Take an illustrative run: an agent call that sends four thousand tokens of context and receives one thousand tokens of output consumes five thousand real tokens. At the three-times multiplier the wallet is debited fifteen thousand user tokens for that run. Against a starting grant of one million user tokens, that run is roughly one sixty-sixth of the grant, so the grant covers about sixty-six runs of that exact shape. Every number in this paragraph except the multiplier and the grant is an assumption chosen to show the arithmetic.
The shape of that sum is the point. Two inputs decide it: how much context each run carries, and how many runs happen. Nothing else in the sum moves.
Why does context length dominate the bill?
Because input usually exceeds output by a wide margin in agent work. An agent that reads a site section, its memory, its targets, and its prior drafts before writing a short proposal spends most of its tokens on reading. Halving the context a run carries therefore moves the bill far more than shortening what it writes. This is why the ftes.ai agent packages keep per-capability token budgets in configuration rather than letting each call take what it wants.
The management lever that follows is unglamorous and effective: give a role a tighter remit and a smaller memory scope, and the same work costs less because each run reads less.
What does run frequency actually cost?
Every recurring schedule is a standing order against the wallet. A daily brief is thirty runs a month; a weekly measurement sweep is four. Doubling a cadence doubles that line, and the value of the extra runs is rarely double. The honest way to set a cadence is to ask how often the underlying thing changes: a site's search visibility does not change hour to hour, so an hourly sweep buys noise at full price.
This is where most avoidable spend lives in practice. A schedule set once during setup and never revisited will quietly outspend every ad-hoc run a manager makes deliberately.
How does metered work compare to a seat licence?
A seat licence prices access and is predictable regardless of use, which suits a tool a whole team opens daily. Metered work prices output and suits work that runs whether anyone is watching, because the bill tracks what was produced rather than who had a login. The trade is predictability against alignment: a seat licence never surprises and often pays for idle access, while metering never pays for idleness and requires a budget conversation.
ftes.ai chose metering because a Digital FTE is judged on work produced, and a price that moves with work produced is one a manager can reason about at review time.
Where does this arithmetic stop being reliable?
It is exact for the mechanism and illustrative for any month's total. The multiplier, the hard stop, and the per-call debit are product facts a customer can verify in their own ledger. A forecast of next month's spend is not, because it depends on how much context the work carries, how often it runs, which model tier is selected, and how much is sent back for a second attempt. ftes.ai reports actual spend from the token ledger rather than a projection for that reason.
A manager who wants a number for a budget should take a period of real usage from the ledger and reason from that, adjusting for any schedule they intend to change.