Updated 3 Oct 2026 · measured 2 Oct 2026
In our 2 Oct 2026 trace of Hermes Agent v0.21.0 (the default toolset of 31 tools, gpt-6-luna via openai-codex, 3 runs per task), a 3-call file task sent 52,841 input tokens, an estimated 86% of them the fixed overhead re-sent on every call. Your cost per useful run is that token bill plus infrastructure and retries, divided by the runs that produced a useful result.
The model
The number that matters is cost per useful run, not your raw monthly spend. A run that retries three times costs three runs; a run that fails costs and earns nothing. The working figure is:
cost per useful run = token cost per run + (monthly infrastructure / runs per month) + retry overhead.
Illustrative inputs only, not a measured benchmark and not your numbers: at 20,000 runs a month, $1,800 of infrastructure, and $0.32 of model tokens per run, the formula returns about $0.41 per run. If a managed plan quoted $0.13 per run, that example would be roughly 3x. The real comparison is your own figure against a price you are actually quoted; the decision is not the multiple, it is whether you can carry the operational work for the gap.
To compute yours: take one representative window of your own usage logs, itemise token cost per run, and divide by the runs that produced a useful result. The same model drives the free self-check.
What this page claims, and does not: it reports one measured trace on our own test install (Hermes v0.21.0, 2 October 2026), one public field report (issue #4379), and a transparent model. The dollar figures in the example above are illustrative, not observed. The traced runs reported their cost as included in a subscription (provider estimate $0.00), and we did not convert their tokens to dollars.
Licence and billing
The software is. Hermes Agent is open source under the MIT licence. Running it is not: you pay for model tokens, through an API key or a subscription, plus the machine Hermes runs on.
A local model replaces the per-token bill with the cost of your own hardware. The fixed overhead still applies: Hermes sends the full prefix on every call, and your hardware spends processing time on it instead of you paying an invoice.
The tokens do not change. Who bills them does.
Our trace ran through the openai-codex provider on a ChatGPT subscription. Hermes classifies that route as subscription-included in its pricing source, so each usage report showed a cost status of included and a provider estimate of $0.00. The roughly 15,200 fixed tokens per call on our install were still sent.
On a pay-per-token API key, the same token counts become your invoice. That is why this page reports tokens: they carry across billing models, and dollars do not.
We did not convert the trace tokens to dollars. The runs had no per-token price attached, and a conversion would need a published per-token price for the same model on a pay-per-token plan.
The anatomy
Because Hermes re-sends the tool schemas, the system prompt, the skills index, and memory on every API call, before any task-specific work. In our v0.21.0 trace that prefix was about 15,200 tokens per call, so each extra call adds another 15,200:
Every extra API call re-sends the full prefix. Fewer calls and a smaller prefix cut most of the input bill.
See the method and commandsSwipe the table sideways for more columns.
| Task | Fixed overhead share | Input tokens, median | API calls |
|---|---|---|---|
| One-word hello | 99.96% | 15,175 | 1 |
| One terminal command | 99.7% | 30,436 | 2 |
| Four-step file task | 86.1% (6-call round: 97.6%) | 52,841 (6-call round: 93,274) | 3 (one round: 6) |
The older comparison point. Issue #4379 measured Hermes v0.6.0 on claude-sonnet-4-5 via OpenRouter in April 2026 and found fixed overhead near 73 percent of an average request, from 6 request dumps of live gateway traffic. The model, the version, and the workload differ from ours, so 86 and 73 are not directly comparable.
The mechanism is vendor-documented. Anthropic's tool-use pricing documentation states that input-token pricing includes the tools parameter: the names, descriptions, and schemas of every tool in the request.
For the per-component split (tool schemas about 67 percent of the prefix), the exact commands, and the limits of this trace, see the per-component fixed-overhead breakdown.
Bill drivers
Each failure below re-pays the fixed overhead, about 15,200 tokens per call on our v0.21.0 install, so a reliability problem shows up first as a cost problem.
State resets on restart, so a run starts over and re-pays the full fixed overhead.
Read fromrestart timestamps against run-id continuity.
A flaky tool or a drifting retrieval step triggers retries, each one a full-priced run.
Read fromretry count per successful task, before and after an upgrade.
Every enabled tool is re-sent on every call, so unused tools tax every run.
Read fromthe tool schema bytes in hermes prompt-size, and the tools each run actually used.
A long system prompt, a large skills index, or memory that no longer earns its tokens.
Read fromthe system prompt, skills index, and memory lines in hermes prompt-size.
The full six-check taxonomy (state, migration, data exposure, tool safety, failure trail) is on the guide home; the cost angle is the four bill-creep drivers.
The levers
Three levers reduce the fixed overhead, because they work on the part that repeats on every call:
Load fewer tools per run. Tool schemas were about two thirds of the fixed prefix in our v0.21.0 trace. Turn off toolsets a platform never uses with hermes tools, then check the result with hermes prompt-size.
Trim the system prompt and skills. Every token of instruction is paid on every call. Cut what the model already knows, and uninstall skills you do not use, because the skills index rides in the system prompt.
Cap retries. A retry is a full-priced run. Bound them, and fix the flaky step rather than paying for it repeatedly.
A first pass this week: run hermes prompt-size, turn off toolsets you did not call, cap retries, then compute cost per useful run from one week of logs and set it next to one quoted managed price.
Then compare your cost per useful run to a quoted managed price and make the keep, migrate, or retire decision. The framework on this page is free. If you want an independent read on your own numbers, a written Verdict applies the same framework to your logs.
Questions
It depends on your model, your token volume, and your infrastructure, so the useful answer is a formula, not a single number. Cost per useful run is roughly: token cost per run, plus monthly infrastructure divided by runs per month, plus the cost of retries. In tokens, our Hermes v0.21.0 trace measured 15,175 input tokens for a one-word hello and 52,841 for a 3-call file task.
Because Hermes re-sends the tool schemas, the system prompt, the skills index, and memory on every API call, before any task-specific work. On our v0.21.0 test install that prefix was about 15,200 tokens per call, and 86 percent of input tokens on a 3-call task. Issue #4379 found about 73 percent on v0.6.0, with a different model and workload.
Take one representative window of usage logs. Sum the token cost across runs and divide by the number of runs that produced a useful result, not the total runs. Add infrastructure divided by runs, and count retries as full runs. Compare that figure to a managed price per run, not to your monthly invoice.
The software is free and open source under the MIT licence. Running it is not: you pay for model tokens, through an API key or a subscription, plus the machine Hermes runs on.
It changes who bills the tokens, not how many are sent. Hermes treats the openai-codex route as subscription-included and reports the cost as included, with no per-run dollar figure. On a pay-per-token API key, the same token counts are billed at the provider's rates.
A public field report on Hermes v0.6.0 in the project issue tracker (issue #4379), which itemised 6 request dumps and found about 73 percent of an average request was fixed overhead, tool definitions the largest part. Our own trace on Hermes v0.21.0 (2 October 2026) is a newer data point with a different model and workload. Measure yours rather than assume either number.
Turn off unused toolsets, trim the system prompt and skills, and cap retries. Tool schemas were about two thirds of the fixed prefix in our v0.21.0 trace, so tools are the biggest lever. Then compare cost per useful run to a managed alternative before deciding to keep self-hosting, migrate, or retire.
Only if your cost per useful run, computed from your own logs, is below a managed price you are actually quoted, and you can carry the operational work. The raw monthly bill is the wrong comparison; cost per useful run against a quoted per-run price is the right one. High, steady volume with a stable set of tools is the case most likely to favor self-hosting.