Agent Fleet Economics in 2026: Testing Low-Cost APIs and Open-Weight Options

How many agents can one person afford to keep running?

The wrong way to answer is to count agents. An “agent” might classify one paragraph, search for twenty minutes, or refactor a repository through eighty tool calls. The useful unit is not the agent. It is the successful task, with its input tokens, output tokens, tool charges, retries, and human cleanup attached.

That distinction changed how I think about two related but different choices: low-cost hosted model APIs and open-weight models that can be self-hosted. Falling API prices matter, but “90% cheaper” is meaningful only when three things are visible:

1. the provider, model, date, and billing lane behind the number;
2. the quality test that decides whether two routes are interchangeable for a task;
3. the operating costs that sit outside the token invoice.

This essay makes those three things explicit. The arithmetic is reproducible. The conclusions are narrower than the old headline, but more useful: cheap tokens can make a personal agent fleet economically possible; only evaluation can make it rational.

The price calculation below compares hosted APIs. DeepSeek V4 Pro appears only as an official API route in that calculation; it is not being used as evidence that a particular downloadable checkpoint is ready for my own deployment. Open-weight and self-hosted options enter later as a separate operational decision, with hardware, utilization, licensing, and maintenance in the denominator.

A price snapshot, not a permanent truth

Prices move. Providers rename models, change cache rules, introduce long-context multipliers, and discount batch traffic. So the table below is a snapshot checked on July 31, 2026, in USD per one million text tokens, using standard Claude and OpenAI API tiers and DeepSeek’s listed regular rates.

These rows are not perfectly symmetric. Anthropic separately prices cache writes; OpenAI applies a long-context multiplier above the threshold stated on its model page; DeepSeek distinguishes cache hits from misses. DeepSeek also says a peak/off-peak policy is forthcoming: during the announced Beijing-time peak windows, every billing item may cost 2× the regular table price once that policy takes effect. Tool calls, web search, batch discounts, regional processing, GPUs, observability, storage, and support are excluded. Before using this table in a budget, open the linked pages again.

Most importantly, the table compares hosted-API list prices, not intelligence or deployability. A dollar cannot tell me whether DeepSeek V4 Pro and GPT-5.4 are equally reliable on my code review, nor whether Sonnet 4.6 is better at my editorial workflow. It also says nothing about the cost or availability of a self-hosted checkpoint. Those questions require an eval on my own tasks and, for self-hosting, a separate deployment audit.

The claim I can defend is simpler: for an identical token mix, the listed inference prices differ by roughly an order of magnitude.

Reproduce the 50-million-token example

Take an overnight workload of 50 million tokens: 35 million uncached input tokens and 15 million output tokens. That is an intentionally heavy scenario, not a claim about a typical five-agent night. Measure your own traffic before borrowing it.

OpenAI GPT-5.4
35M input  × $2.50/M  =  $87.50
15M output × $15.00/M = $225.00
Total                    $312.50

Anthropic Claude Sonnet 4.6
35M input  × $3.00/M  = $105.00
15M output × $15.00/M = $225.00
Total                    $330.00

DeepSeek V4 Pro
35M cache-miss input × $0.435/M = $15.225
15M output           × $0.87/M  = $13.050
Total                              $28.275

At those posted regular rates, the V4 Pro bill is about 90.95% below GPT-5.4 and 91.43% below Sonnet 4.6 for this token mix. If DeepSeek’s announced peak policy is in effect and the entire workload lands in a peak window, its bill doubles to $56.55; the corresponding savings fall to 81.90% versus GPT-5.4 and 82.86% versus Sonnet 4.6. That is why the “roughly 90%” figure belongs to a dated, regular-rate scenario rather than a permanent headline.

It does not prove equal output quality. It does not even prove the cheaper route wins economically: if it fails more often, consumes more tokens, or sends more cases to a human, its cost per successful task may be worse.

The old illustrative rates of $5/$25 and $0.30/$1.20 made the shape visible, but they mixed an invented scenario with the tone of a live quote. Current provider/model/date labels are less dramatic and much harder to misuse.

My routing eval uses a fixed, versioned task set sampled from the work I actually do. For each route, I record:

• task success rate: did the output pass the same executable or rubric-based acceptance check?
• human escalation rate: how often did a reviewer have to repair, approve, or rerun the task?
• cost per successful task: total model, tool, and retry cost divided by accepted results;
• latency and severe-error rate as guardrails, especially for irreversible actions.

Suppose Route A costs $0.08 per attempt and succeeds 96% of the time. Route B costs $0.01 but succeeds 70% of the time, retries frequently, and sends one task in five to a human. Calling B “eight times cheaper” is bookkeeping theatre. The denominator is wrong.

For a simple automated gate, I use:

cost per successful task
  = (model + tool + retry + measured review cost)
    / number of accepted task results

Quality is not one universal score. A model can be strong at extraction, weak at repository navigation, and unacceptable at a destructive database change. I stratify the eval by task class and risk. The result is a routing table, not a model leaderboard.

That is the philosophical shift: do not ask which model is smartest. Ask which route earns trust for this particular consequence.

When agent history really becomes quadratic

There is a real cost trap in multi-turn agents, but it needs careful boundaries.

Assume:

1. each turn adds roughly the same amount of new history;
2. every subsequent request resends the full history;
3. the provider bills all of that history as uncached input;
4. the application does no compaction, retrieval, or state pruning.

Under those conditions, input grows linearly per turn, and cumulative input is the sum of that growth:

Initial context: 5K tokens
New history per turn: 2K tokens
Turns: 30

Total input ≈ Σ(5K + 2K × n), n = 0…29
            ≈ 150K + 870K
            ≈ 1.02M tokens

The dominant term is proportional to (n^2). In that restricted design, doubling the turn count can approach four times the input-token volume.

But agent cost is not universally quadratic. Several mechanisms bend the curve:

• prompt caching discounts repeated prefixes, although it does not remove latency or context limits;
• rolling summaries bound history while risking information loss;
• retrieval injects only the state relevant to the next step;
• structured scratchpads store decisions instead of the entire conversation;
• stateful APIs can avoid resending some reasoning or conversation state;
• hard turn and tool-output budgets stop wandering before it compounds.

Cutting turns is still valuable, but “half the turns means one quarter of the cost” is an upper-bound heuristic for the full-replay case, not a promise. Fewer turns can also reduce quality if they remove verification. The target is less unproductive motion, not fewer thoughts at any price.

A fleet is a routing policy, not a row of identical workers

Sending every operation to one flagship model is easy to implement and hard to justify. Yet routing every cheap-looking task downward is equally careless. I use a cheapest-safe-route policy:

                         New task
                            │
                  deterministic checks
          schema · length · reversibility · data class
                            │
              ┌─────────────┴─────────────┐
              │                           │
       low-risk and tested          uncertain or high-risk
              │                           │
       cheaper candidate             stronger route and/or
              │                        human approval
              └─────────────┬─────────────┘
                            │
                     acceptance check
                       │          │
                     pass       fail
                       │          │
                    record     retry/escalate

The router should begin with rules because rules are legible. Task type, schema presence, context length, data sensitivity, reversibility, and historical pass rate often decide the route without another model call. A learned router becomes useful only when its own error rate and cost are measured.

I do not claim that fewer than 10% of calls need a flagship. That may be true for one carefully decomposed extraction pipeline and false for a research or coding system. The percentage must come from production traces:

flagship share by task class
  = accepted flagship-routed tasks / accepted tasks in that class

The same rule applies to fleet size. Five overnight processes are a scenario; they are not evidence of a universal “five-agent fleet.” Name workers by responsibility, then measure whether concurrency improves throughput or merely multiplies review queues.

How I would run the evaluation

A credible step-down experiment needs more than comparing two polished examples.

1. Freeze the task set

Sample recent production tasks, remove duplicates, and keep both ordinary and ugly cases. Hide expected outputs from the routing logic. Version the dataset so a later prompt or model update can be compared with the same baseline.

2. Define acceptance before seeing results

Use executable tests when possible: schema validation, unit tests, citation checks, database constraints. For subjective work, write a short rubric and blind the reviewer to the model identity. “Looks about as intelligent” is not an acceptance criterion.

3. Run each route with the same budget

Hold tool permissions, maximum turns, retry policy, context, and output requirements constant. Record cache hits separately from misses. If one provider exposes different reasoning controls, document them rather than pretending the configurations are identical.

4. Compare outcomes, not demos

Report success rate, escalation rate, severe failures, latency, tokens, and cost per successful task with sample counts. A route graduates only when it meets the predeclared quality and risk thresholds.

5. Keep monitoring after deployment

Model aliases and provider behavior change. Pin snapshots where possible, log the resolved model version, retain a rollback switch, and rerun the eval when the model, prompt, tool set, or task distribution changes.

This process gives routing its real advantage. The win is not “zero quality loss.” The win is known quality loss, bounded by an explicit tolerance, in exchange for a measured reduction in cost per successful task.

Where the token argument ends

At small scale, token price may dominate. As the fleet grows, other costs appear:

1. Evaluation — datasets, graders, regressions, and review;
2. Operations — traces, retries, rate limits, alerts, and stuck runs;
3. Safety — permissions, rollback, secrets, and irreversible actions;
4. Attention — the finite number of outputs a person can judge well.

The last one is the hard ceiling. Fifty overnight outputs at five minutes of review each consume more than four hours the next morning. Cheap inference can move the bottleneck from compute to judgment; it cannot abolish the bottleneck.

This is why I no longer repeat “this machine is 98.4% scaffolding.” The number came from an illustrative decomposition, not a measured cross-project constant. The durable point remains: model calls are one component of an agent system. The harness—state, tools, evals, permissions, and observability—decides whether cheap calls become useful work.

The same caution applies to market-share claims. I do not have a primary, comparable dataset proving that open-weight models represent 25–30% of industry token usage, so that figure does not belong in the argument. If a number cannot survive a request for its denominator, collection method, and date, it should not steer architecture.

Four changes worth making now

Measure before migrating. Log provider, resolved model version, task class, cache status, input and output tokens, tool charges, retries, acceptance result, and human minutes. Otherwise the most expensive route remains hidden inside an average.

Bound context before chasing unit price. Trim irrelevant tool output, store durable state in structured form, summarize with checks, retrieve only what the next step needs, and cap turns. Then price the smaller, more stable workload.

Step down one low-risk class at a time. Extraction or tagging with a deterministic validator is a better first experiment than autonomous commits or outbound messages. Run both routes on the frozen set and compare cost per accepted result.

Keep escalation and rollback cheap. A routing decision should be reversible in configuration. If uncertainty, novelty, or consequence rises, route upward or require a human. Saving cents on an irreversible action is an expensive kind of thrift.

Second-half forecast

My forecast is not that open-weight models or low-cost APIs replace every frontier hosted model. It is that task-level economics replace model loyalty.

Multi-model routing will become ordinary because the price spread is too large to ignore and the quality spread is too task-dependent to summarize with one benchmark. Open-weight and low-cost API models will win repetitive, verifiable workloads first. Frontier routes will remain valuable where failure is expensive, evaluation is weak, or a genuine capability gap appears.

Self-hosting may help teams with stable volume, privacy constraints, and the operational skill to keep accelerators busy. For a solo builder, it is not automatically cheaper: idle hardware, batching, upgrades, observability, and incident time belong in the denominator. “Open weights” is a licensing and deployment property, not a free-inference coupon.

The architecture I expect to last is modest:

• deterministic code where deterministic code works;
• the cheapest evaluated model for reversible work;
• stronger models for uncertainty and high-consequence decisions;
• a human at boundaries the system has not earned the right to cross.

Closing

So, how big an agent fleet can one person afford?

With the July 31 regular-rate snapshot and the 50-million-token scenario above, the raw DeepSeek V4 Pro inference bill is about one-eleventh of the GPT-5.4 bill. That is a real and consequential price difference. It can turn experiments that were rationed into processes that run continuously.

But affordability is not the same as usefulness. The fleet is viable only if it produces accepted work faster and cheaper after retries, tools, operations, and human review are counted. The number of agents is theatre; cost per successful task is economics.

Cheap models lengthen the lever. They do not choose where to place it. That remains the builder’s work: measure the consequence, define success before the run, and spend intelligence only where it changes the outcome.