A Hermes session reports tokens, models, and cost for the whole conversation. Inside that one conversation, the agent might fix a regression, review a teammate’s pull request, and draft a migration plan. Each of those can burn a similar number of tokens while delivering very different value to the business, and a session total averages that difference away.
The job is the better unit. It’s one piece of work aimed at one result, and Hermes routinely finishes several in a single session while handing parts of a task to subagents with their own context and terminals. Measure cost per job, and teams can compare agent work, rank it, and decide which of it to keep funding.
Our Cost Controls release covered Hermes's spending side, including rules evaluated against live usage before the provider call, warn-and-block bands, and shadow mode for calibration. Budgets cap what gets spent. Job-level cost tells you what that spend bought.
What it takes to produce a cost per job
- Automatic job detection. The Revenium classifier reads session data to find coherent task arcs and gives each one a job name, a job type, and an execution status. On Hermes, this runs deterministically in the
revenium-classifierplugin aton_session_end, so attribution never depends on a model remembering to label its own work. - Job-level accounting. Metered usage links to the detected job, putting what a job cost next to what it produced. That reading is only as complete as the attribution behind it.
- Experimental value estimation. For eligible successful jobs, the integration estimates economic value from bounded assumptions or from valuation policies the operator configures.
Together they turn a session total into a per-job figure. Value estimation is an opt-in Revenium Labs experiment, built for investigating agent economics with assumptions you can inspect, and it doesn’t certify savings on its own.
Drawing the boundary around one job
A single model call is too small to mean anything to the business. A whole conversation is too big, since it can hold several unrelated efforts. Detection draws the boundary around the task arc between those two. Every number downstream depends on it.
Each job closes as SUCCESS, FAILED, or CANCELLED, recorded once and immutably through the Revenium CLI with revenium jobs outcome. SUCCESS means the agent finished what it set out to do. Nothing more. Whether a customer accepted the result is a separate question that execution status can’t answer.
Cost attaches through the completions linked to the job with --agentic-job-id. Subagent spend rolls up under the originating root session and job, so a fan-out of subagents keeps its accounting in one place. When links are missing, the error always runs in one direction: the job looks cheaper than it was. Sessions that contain several jobs are still the harder case for attribution.
Take a bug fix. Hermes investigates a regression, implements a change, and runs the test suite. Detection names that arc as one debugging job and closes it as SUCCESS, and the completions and tool events from the investigation and the test run attributed to it. All of that is recorded before any value estimate enters the picture.
How value and ROI get estimated
When an agent does work a person would otherwise have done, the estimate starts with how long that person would have needed and what their time would have cost. The integration puts bounds on that hours-and-rate estimate and stores model assumptions separately from operator-approved values. A reader should be able to tell which is which.
Operators control the valuation policy through the rate-card and revenue-card paths in configuration. Those policies define how each job type gets a monetary value. A job that falls outside the configured policies gets no value by default. Plenty of agent work produces neither labor savings nor revenue.
The integration also records the review, rework, handoff and training costs that operators supply against each job. Costs that haven't been configured remain unknown. Treating them as zero would overstate the net value.
Revenium pairs the recorded value and its supporting metadata with attributed AI cost in the ROI view. The value and the computed ratio appear separately. A ratio calculated against AI spend only accounts for the AI portion of the workflow's cost. Calculating the full return also requires the human time spent around the job.
For the bug fix, the annotated assessment shows the assumed hours and rate, the resulting estimated range and any supplied review or rework costs. An evidence label identifies where the value came from. Gross value, net value after supplied costs and the value used in the displayed ratio each appear on a separate line.
Why the evidence behind an estimate matters
A cost per job is only worth having when the value next to it holds up to scrutiny. Trivial, unclear, or unsupported work shouldn’t earn a positive valuation just because an agent completed it, and the model can abstain instead of assigning one.
A model estimate, an operator-configured value, and an observed business outcome each support a different claim, and none of them alone proves causal impact. Collapse them into one number and you lose the ability to tell which one is carrying the result.
That’s why model-only estimates currently stay local and are withheld from value reporting. The ROI view doesn’t yet show provenance, and without it a reader couldn’t distinguish a model’s guess from a value an operator signed off on.
Operators can revise an assessment while keeping the assumptions it originally used, so every number has a visible history. Failed and cancelled jobs stay in the picture as well, with no positive value. Drop them, and every rate calculated from the remaining jobs looks better than it should.
What comes next
Better job-cost attribution and wider classification coverage come first, ahead of any stronger ROI claims, and some known attribution gaps are still open. After that, the direction is stronger outcome evidence. Customer acceptance records or downstream business systems could ground assessments in something firmer than transcript-based inference, though those integrations haven’t shipped.
The most useful input right now comes from operators who compare detected jobs and estimated values against work they already know well. We especially want the cases where the classifier gets the boundary, the outcome, or the valuation wrong.
Get started
- Install or upgrade the Revenium Hermes integration and look at the jobs it detects.
- Pick a workflow you know well. Check the job boundary, execution status, and linked transactions before reading anything into the economics.
- Turn on experimental evaluation locally, review the assumptions it uses, and configure valuation policies deliberately.
- Read the ROI and unit economics docs and join the conversation on Discord.
