6,418,529,757 tokens. 222 threads. 564 turns. About $25,000 at the API-equivalent estimate used for this incident.
The assignment was to improve roughly 460 articles across AI4SALE and Мед ИТ (MYOD.IT). Most of the work was editorial: preserve the useful technical material, replace the do-it-yourself framing with buyer-oriented copy, add a commercial companion where appropriate, and place the approved articles into a WordPress publication queue.
GPT-5.6-Sol running at xhigh reasoning turned that bounded content job into a self-perpetuating audit system. It reread finished work, sent outdated copies to reviewers, treated stale hashes as evidence that the whole catalog might be wrong, generated internal proof that did not help a reader or publish a post, and repeatedly reported completion without verifying the only outcome that mattered: the right article appearing as a scheduled WordPress post and rendering correctly in a browser.
There is no elegant technical term for this. It was a complete operational failure. The model was capable enough to write, review, script, inspect WordPress, and verify production. The orchestration gave that capability the wrong objective and no economic stop condition.
What the task actually required
The useful part of the plan was straightforward.
- Read each existing article once.
- Decide whether it could support a separate buyer-oriented article.
- Write the new article from the current source.
- Run one independent semantic review.
- Repair only evidenced defects.
- Assign the publication date.
- Create a WordPress
post, not apage. - Verify one pilot in the admin and browser.
- Apply the proven script to the remaining queue.
For deterministic publication, the validator needed a short list of facts: the source file exists, the assigned date is present, the post has not already been created, and the requested post type is post. One successful pilot would prove the route. The rest was a repeatable batch operation.
The system did something very different.
The number was not a normal cost of writing 460 articles
| Observed task-tree measure | Recorded value | What it means |
|---|---|---|
| Total tokens | 6,418,529,757 | Aggregate processing across the root task and its child work |
| Threads | 222 | Separate execution contexts created under the task |
| Turns | 564 | Model interaction turns recorded for the task tree |
| Article scope | About 460 | Russian and English materials in the dual-site project |
| Tokens per article | About 13.95 million | A ratio that exposes process waste, not article complexity |
| API-equivalent estimate | About $25,000 | An estimate, not a claim that the same amount appeared on an invoice |
At that estimate, the process spent about $54 of model work per article before counting the founder’s time, production corrections, or the delay in publication. That would be hard to justify for elite original journalism. It is indefensible for controlled rewrites of existing material.
How a strong model created a stupid system
1. The root task never froze one canonical current input
Articles existed as source files, revised files, reviewer copies, queue manifests, reports, and WordPress records. The orchestrator did not establish one authoritative pointer for each article before fan-out. A reviewer could receive a snapshot created before the latest repair. Its findings were then compared with a newer file.
The predictable result was a false conflict. The reviewer correctly described the old copy. The author correctly said the current copy was fixed. The orchestrator treated the disagreement as uncertainty about the article rather than a version-selection defect.
2. A stale hash became a reason to reread content
A hash answers one narrow question: are these bytes identical? It does not decide whether the current article is good, whether a previous report still applies, or whether the post is ready to publish.
The workflow gave a stale hash too much authority. When a report referred to a superseded file, the system reopened semantic review instead of discarding the obsolete report and checking the current file against the one failed rule. Each new reread could produce a new wording preference, which created another patch, another hash, and another review opportunity.
3. Review became the product
The business result was publication. Internal progress was measured through review artifacts, pass counts, manifests, comparison reports, and declarations that a batch had been checked. Those objects were easier for agents to produce than a verified production outcome, so the system optimized for them.
This is a common agent failure. A proxy metric becomes locally safe. More review looks cautious. More evidence looks responsible. Another pass appears cheaper than accepting uncertainty. Without a total budget and a terminal acceptance test, every local decision pushes toward more work.
4. Finished articles repeatedly re-entered the expensive path
The task had no monotonic state machine. An article that passed review could return to broad review because another artifact was stale, a manifest did not match, or the root agent had lost confidence in the batch. “Written,” “reviewed,” “repaired,” “ready,” “queued,” “scheduled,” and “visible” were discussed, but they were not enforced as separate states with narrow transitions.
That allowed a completed semantic stage to reopen without new evidence of a semantic defect. The system paid again for work it had already accepted.
5. Full context made every correction more expensive
High reasoning can be valuable when the decision is genuinely hard. Here it amplified an orchestration mistake. Child agents received large inherited contexts, old reviewer conclusions, evolving rules, article bodies, status explanations, and prior corrections. A model turn could spend millions of tokens reprocessing history before touching the one current file that mattered.
The model did not become confused because it lacked intelligence. It was asked to reconcile too many authorities, including authorities that should already have been discarded.
6. The checker was asked to reason about deterministic facts
File presence, publication date, WordPress post type, duplicate status, source URL, and HTTP response do not need xhigh reasoning. A small script can check them exactly. Instead, model agents repeatedly inspected reports about those facts and explained their confidence.
The most expensive model in the chain became a filesystem checker, a date parser, a duplicate detector, and eventually a very verbose substitute for a short Python script.
7. Completion was claimed before the production outcome was tested
The failure became visible when the AI4SALE WordPress admin did not show the expected increase in posts. One item had been created as a page. Another check focused on whether a date looked correct rather than whether the article rendered correctly at its public URL.
A process that had spent billions of tokens on certainty had not run the simplest acceptance test: create one scheduled post, confirm it appears in the correct admin list, open its preview or public URL, and inspect the rendered page.
Why GPT-5.6-Sol xhigh did not rescue the process
Capability does not supply an objective function that the orchestrator forgot to define. The root agent controlled delegation, context, pass count, and the decision to reopen work. The child agents followed the tasks they received. Reviewers found issues in the versions they were shown. The model’s caution made the system worse because caution had no marginal cost attached to it.
Four missing controls mattered more than model intelligence:
- one canonical current file for each article;
- one business acceptance test tied to publication;
- a maximum number of authoring and review passes;
- a total token or API-cost ceiling for the whole task tree.
Without those controls, a nearly general-purpose system can be locally rational and globally absurd. Every extra check can be explained. The total process still burns $25,000 to move text between files.
The 25-line approach that should have replaced the audit cascade
for item in manifest:
assert item.source_file.exists()
assert item.publish_at is not None
assert item.post_type == "post"
remote = wordpress.find_by_slug(item.slug)
if remote:
assert remote.status in {"future", "publish"}
continue
post_id = wordpress.create_post(
title=item.title,
slug=item.slug,
content=item.html,
status="future",
date=item.publish_at,
)
result = wordpress.get(post_id)
assert result.post_type == "post"
assert result.status == "future"
assert result.date == item.publish_at
Before scaling, run this on one article. Open that article in the WordPress admin. Open the browser route. Confirm the layout. If the pilot passes, use the same script for the remaining manifest. If one row fails, repair that row or the shared deterministic defect. Do not reread 460 articles because one database record is wrong.
The operating rule created after the failure
AI4SALE now applies a bounded content chain:
- Define the canonical input, acceptance test, pass limit, total cost ceiling, and stop condition before fan-out.
- Use one authoring pass.
- Use one independent semantic review.
- Repair only evidenced defects.
- Require new defect evidence before another semantic review.
- Use scripts for deterministic facts.
- Prove the production path with one bounded pilot.
- Scale the accepted method without another full-corpus audit.
The deeper lesson is uncomfortable. Powerful models can hide bad operations for longer because they keep producing plausible work. The answer is not a weaker model. The answer is a smaller system with explicit authority, cost, and completion.
Questions founders ask after an AI cost overrun
The $25,000 figure is an API-equivalent estimate applied to the recorded 6,418,529,757-token task tree. It is presented as an estimate, not as an invoice claim.
The model executed an unbounded process designed by the root orchestrator. The primary causes were competing source copies, repeated full reviews, large inherited contexts, no total cost ceiling, and no terminal production acceptance test.
No evidence showed that repeated full-corpus passes added value proportional to their cost. Many passes revisited already repaired material or reconciled stale artifacts rather than new reader-facing defects.
Use one canonical current input, a finite state machine, deterministic checks for deterministic facts, one authoring pass, one independent review, a bounded pilot, total task-tree cost accounting, and a stop condition tied to the business outcome.
AI4SALE will show where your agent workflow should stop spending and start finishing
Share the workflow, approximate volume, models, current checks, output destination, and any recent cost or quality surprise. We will propose the canonical input, acceptance test, deterministic gates, cost ceiling, and first bounded production test.
Which AI workflow is consuming more time or model spend than its result justifies?
The companion implementation guide explains how to control an AI agent review loop before it becomes a cost overrun, including the task manifest, state transitions, budget governor, deterministic validator, and production pilot.