Accounting

Two cost records, every time

Every component result carries two cost structures: a general cost record covering I/O, network usage, and timing, and an inference cost record covering AI token usage and spend. CostGeneral is populated for every component. CostInference is populated for every inference and inference:estimate call. Both are also available in the per-step metric record streamed by the tracer in real time.

Money: nano precision

All monetary values in the engine use a nano-precision money type based on the Google Money proto. This avoids floating-point rounding errors on the sub-cent amounts that make up most per-token costs.

Signs must be consistent: if units is positive, nanos must be positive or zero; if units is negative, nanos must be negative or zero.

For example, a per-token price of $0.0000015 is represented as units: 0, nanos: 1500 - nine decimal places of precision with no rounding loss. For a cost of €1.50, it would be units: 1, nanos: 500000000.

The rate field records the exchange rate at the moment the cost was calculated, so historical records remain accurate even as rates change over time.

General cost: I/O and timing

The general cost record measures the operational footprint of a step - how much data it read, wrote, deleted, and how long it took.

Use these numbers to track storage growth, monitor network-heavy workflows, and attribute infrastructure costs back to specific steps or runs.

Inference cost: full token breakdown

The inference cost record gives you a complete picture of every model call - actual token usage split by phase, pre-call estimates, and cost in two currencies.

Token phases

Input, output, and thinking tokens are priced at different rates - the engine applies the correct per-token price for each phase automatically.

The estimate phase is populated by inference:estimate calls. When a full inference call follows, the actual input, output, and thinking phases are populated separately, so you can compare the estimate against reality.

Provider vs. client cost

Every cost appears twice:

• cost_provider - cost in the model's base currency (typically USD). This is what the AI provider charges. The rate field on this Money record is always 1.
• cost_client - cost converted to your configured currency using that day's exchange rate. The rate field records the exact exchange rate used, so you can audit or reconstruct any conversion later.

For example: 1,240 input tokens on Claude Opus at $1.50/MTok costs $0.00186. Converted to EUR at a rate of 0.919, cost_client is €0.00171 with rate: 919 (stored as a scaled integer).

Multi-currency support

The engine fetches exchange rates daily. Configure your currency once; every cost across every step is converted automatically.

- name: analyse
  component: inference
  vars:
    provider: anthropic
    model: claude-opus-4-20250514
    currency: EUR
    prompt: "{{ document }}"

Or set a default currency at the engine level so you never have to specify it per-step.

Supported currencies include USD, EUR, GBP, JPY, AUD, CAD, CHF, and every other major ISO 4217 currency. The currency template modifier formats any Money value for display:

message: "This run cost {{ result.cost_client | currency 'EUR' }}"
# → "This run cost €0.014"

Step-level metrics

Every step emits a metric record that is available in real time via the tracer and in aggregate after the run completes. Each record identifies the step precisely:

Hierarchical step IDs

step_id encodes position in the workflow tree. A flat step at position 2 is "2". A nested step inside a loop is "2.iter.0.1" - the second step inside the first iteration of the loop at position 2.

This means you can:

• Group metrics by top-level step without flattening the tree
• Attribute cost to a specific loop iteration
• Correlate a failed step to its exact position in a deeply nested workflow

Loop and retry tracking

iteration is -1 for non-loop steps, and 0, 1, 2… for successive loop iterations. retries counts how many times the step was retried before it succeeded (or gave up). Both fields are available on the metric - giving you a complete picture of how much a flaky step actually cost.

Aggregating costs

What you can build on top

The accounting data coming out of the engine is production-ready infrastructure for:

• Per-user billing - attach run_id to a user record; sum their inference costs across runs
• Budget enforcement - check running totals mid-workflow using inference:estimate before committing to expensive calls
• Cost dashboards - stream step metric events to your observability stack in real time
• Model comparison - run identical workflows against different providers and compare total inference cost
• Audit logs - every step has a UUID run_id and hierarchical step_id; the full trace is reproducible and the rate field on every Money value makes conversions auditable