Saphan StudioDocs
Cost management

The dimensions of cost

The question of what agent development costs has no single answer — it has axes. Which axes the record can answer along, and which ones need an export.

"What does agent development cost" is not one question. It is a family of questions, and they are asked by different people for different reasons: a controller wants it per project, an engineering manager wants it per change, a platform owner wants it per model.

The record can answer along all of them for one reason: every row is born tagged. The axes are not a reporting layer bolted on afterwards; they are properties the row already carries at the moment it is written.

The axes, and how each is answered today

AxisHow it is answered
Per stream of worksaphan cost names the stream and reports every run — actual, the prediction where one was recorded, the difference where both are known — plus totals. The stream is the native unit of these books.
Per merged changeA stream closes into exactly one observed merge, so the cost of a merged change is that stream's rollup: one command, and it includes the review and coordination runs that shipped it.
Per projectThe workspace total. A workspace binds the repositories a fleet works on; saphan ledger show totals it, and saphan board export carries the cost lanes into a report you can hand outward.
Per portfolio⚠ The export, aggregated in your own reporting tool. There is no built-in cross-workspace rollup.
Per personEvery run row carries the actor and session that spent the money; every gate row carries the human who decided. Who spent, and who approved, are separately queryable.
Per roleImplementation, review and coordination are booked in separate lanes — so management overhead is a number rather than an estimate. A fleet whose coordination cost is invisible is not accounted; it is guessed at.
Per model, per vendor, per billing worldEach row pins the model and backend that actually executed, normalised into one currency column and classed by billing world.

The answer a finance reader is usually after

Because the same record holds the decisions and the costs, spend is attributable to decisions.

The difference is worth being concrete about. A conventional report says: this much went on agents last month. This record says: this merged change cost this much, against a prediction this person recorded, approved at this gate by this person, on this date. The first number can only be accepted or disputed. The second can be defended, which is a different and considerably more useful property when somebody asks.

Composing the axes

Because the tags are on the row rather than in a pre-built report, the axes combine into questions nobody designed a screen for — the most expensive area of development over a quarter, the share of spend that went to review rather than implementation, which class of work overruns its predictions most often.

Two surfaces serve that:

  1. The export. Every row, every dimension, one object per line — into whatever your organisation already uses to slice numbers.
  2. A read-only projection of the same record, queryable in plain language, which returns a themed rollup with each theme's share of total spend and the number of rounds behind it. It reads the same ledger every other surface reads, so a figure you get conversationally is the same figure the console shows.

What is not built

  • No time-window or group-by reads are built in. Per month, per actor, per repository and per portfolio are all export-and-aggregate today.
  • No cost-centre tag exists on a stream. Streams map to repositories and to actors, which is usually enough to derive a chargeback, but the derivation is yours to do — there is no field to write a cost centre into.

Both are limitations of the reads, not of the record: the dimensions are already on every row, so nothing has to be reconstructed later.

Next

On this page