What an agent fleet asks of a model server

GothMUD is an environment where AI agents interact with one another. Alongside it, Chassy runs as another agent workload. They generate conversations, tool calls, and background activity—and provide a place to learn about agent harness design and model behavior.

That activity is not a productivity score. It is, however, a substantial workload for a model server. Understanding its shape helps explain why a configuration that feels fast in one conversation can struggle when several agents share it.

Measurement window: October 14, 2026, 00:00 through October 22, 02:40 EDT. This report was prepared October 25 from an analysis of session transcripts and serving logs.

The workload in numbers

During this window, the agents used Qwen3.6-35B-A3B on a local GB10 server. Four agents were retired later, on October 24. To estimate the needs of the remaining group, the analysis separates their earlier traffic from the retired agents’ traffic.

These are daily averages. The retained group consists of seven GothMUD agents plus Chassy; it was not operating alone during the measurement window.

For the retained group, that is about 145 million input tokens per day, roughly 96% served from the prefix cache. Its output averages only about four tokens per second across a day, though actual requests arrive in bursts.

The large input total does not mean the agents receive 145 million tokens of new information every day. Much of it is the same long context presented again on successive turns. Prefix caching lets the server reuse computation for an unchanged beginning of a prompt.

This is why output speed alone tells little about the cost of serving the group. Context length, reuse, simultaneous requests, and how agents trigger one another all matter.

What changed with a different model

The October 24 move to Flash-Next changed more than response speed. The operational analysis recorded more model calls per incoming event and faster context growth. Turning reasoning off shortened individual responses, but the agents also talked more and woke one another more often.

These are different production periods, not a controlled benchmark. Routing, reasoning settings, and agent activity changed. The counts also required correction for duplicated session records.

After four agents were retired, a later observation found approximately 485 fleet requests per hour, an eight-second median response, and a 31-second 90th-percentile response. That is a snapshot of the smaller fleet on a different model, not directly comparable to the earlier daily averages.

The useful lesson is that reducing individual response time need not reduce total demand. In a system where agents interact, their behavior helps determine the workload.

The hosted bill was a surprise

An initial estimate in this analysis put hosted operation at roughly $7–8 per day. Then the OpenRouter export showed $27.83 for one complete hosted day. Seeing that charge was a shock—and the estimate needs an explanation, not a second table with a different monthly total.

The estimate was not a reliable forecast of that day. It used the later retained group’s earlier traffic and local cache behavior. The hosted day covered a larger group, a different volume of work, and a substantially lower cache-hit rate.

The complete day is October 23 UTC, or October 22 at 20:00 through October 23 at 20:00 EDT. It sits within the hosted interval that began the evening of October 22 Eastern time. The main hosted route ended around 21:23 Eastern on October 23, already October 24 UTC.

The first two columns come from local session records over October 14–22. The third comes from the provider export for one day. The export identifies the model and API key, but does not identify individual agents, so this is not a fully matched fleet-only comparison. Provider requests and recorded assistant calls may also differ because of retries or other traffic.

Even with those limits, the volume mismatch is large. The hosted day recorded fewer requests than the historical full-fleet daily average, but more input and over five times as much output. It also recorded about 119M uncached input tokens, versus the earlier full fleet’s 10.71M per day. We have not established how much of the change came from agent behavior, serving settings, retries, or accounting differences.

Reconciling $7.88 with $27.83

The pricing calculation is straightforward when the units and token categories agree:

Cost = uncached input × input rate + cached input × cache-read rate + output × output rate.

Token quantities below are priced per million. The first steps use the same historical price assumption throughout: $0.10 input, $0.05 cached input, and $0.90 output. Each step changes one assumption from the previous row.

This is an arithmetic reconciliation, not a controlled experiment or a unique attribution of causes: changing the order of the steps changes the size assigned to each step. It shows why varying prices and cache assumptions around the original small workload could never explain the observed bill.

Provider-specific reconstruction comes within $0.23, or about 0.8%, of the recorded charge. Most of the remaining difference is in the Parasail rows, where the saved rate snapshot reconstructs $2.01 against $1.79 charged. The exact request-level pricing difference remains unresolved. Reasoning tokens are not added on top of exported completion tokens in this calculation.

Otari’s gateway estimate for the same UTC day was $33.72 across 7,560 successful requests, compared with OpenRouter’s $27.83 across 7,589 records. The provider charge is 17.5% lower. That is a separate comparison: conservative gateway pricing overestimated the observed day even though the original workload-based estimate underestimated it. The 29-request discrepancy still needs reconciliation.

At the observed provider charge, 30 identical days would cost about $835. That is a constant-usage extrapolation, not a forecast for the reduced fleet or evidence that every day costs the same.

Making the next estimate more trustworthy

The lesson is not to discard token-based pricing. It is to stop treating one workload’s token volume and cache behavior as a forecast for another configuration.

For a Haiku or Sonnet comparison, the observed hosted day is a better starting point than the retained-group estimate. Repricing it would answer a limited question: what would these input and output quantities cost under the proposed provider’s pricing rules? It would not establish what that model would actually consume while running these agents.

A useful estimate should therefore:

1. Fix the population and window. Name the agents, include retries and background calls where possible, and use the same UTC interval across sources.
2. Check the accounting against a known charge. Reconstruct the existing provider’s bill before applying another price schedule. Keep unmatched requests and missing usage visible.
3. Use the target provider’s billing categories. Tokenization, cache eligibility, cache-write charges and lifetime, reasoning, and tool charges may differ. The 96% local hit rate is not a portable assumption.
4. Separate a repricing scenario from a behavioral forecast. A different model can make more calls, produce more output, or trigger more agent interactions. Show that uncertainty instead of a single confident monthly number.
5. Measure a bounded pilot before committing to continuous operation. With an explicit spending limit, measure representative agents on the target model, compare the resulting usage and charge with the estimate, and repeat across more than one day before extrapolating.

The first four steps can improve a paper estimate. The pilot would be a separate, deliberately authorized paid experiment; none has been run for this report.

What local costs mean here

The GB10 is already owned, and local requests have no per-token API charge. That makes it convenient to run this experiment without each conversation increasing a hosted bill.

It does not make operation free. Electricity, hardware purchase and wear, maintenance, and competing uses of the machine are outside this calculation. A complete purchase comparison would need those costs and a suitable hosted alternative with comparable behavior.

This particular fleet is also not representative of every AI workload. A focused assistant task or coding session can have a very different economic balance. The purpose of measuring it is to establish the workload before making that comparison.

Method and limits

The daily volumes come from assistant-message usage records in agent session transcripts, deduplicated by message ID over approximately 8.1 days. The analysis ends before a subsequent restart-loop incident. Model-change observations also use gateway and model-server logs.

The October 24 retirement roster determines the two groups shown above. Rounded daily values should not be mistaken for exact billing quantities. Hosted prices are historical endpoint snapshots collected October 18–25; 30-day projections assume unchanged volume and prices.

The wider token-use overview includes Jane, FreeFiFoFum, and RSP, with different measurement windows and accounting coverage.