Hyperagent Fails the Production-Cost Test

⚠️ ALERT: NOT RECOMMENDED — High-Risk Cost Volatility and Runaway Reasoning Loops

Bottom line: Hyperagent is currently unfit for our production workflows. In our testing, its agents spent hours overthinking routine website-build tasks. During those sessions, our account recorded more than 1.29 billion Claude Opus cache-read tokens and 164 million cache-create tokens.

Failure unfolded in four distinct stages:

1. Hidden compute costs – Five initial builds in April and May consumed approximately $1,000 in promotional credits. Credits masked the burn, creating a false sense of cost efficiency.
2. Out-of-pocket explosion – Five substantially similar builds in June resulted in $1,259.43 in cash charges while we moved from the $100 plan to $250 and then $500 per month. The upgrades did not prevent additional overages.
3. Single-invoice spike – A separate later invoice for routine work reached $500.43. Hyperagent initially refused our request for a full refund and later issued a partial $250 credit.
4. Basic retrieval tax – After the credit was activated, downloading an existing project ZIP cost $3.08 and recovering a previously discussed routine from chat history cost another $4.01. Charging $7.09 to retrieve two existing artifacts, with no new code or assets produced, was wildly disproportionate to the value of the work.

Verdict: Until Hyperagent implements hard spending limits, automated circuit-breakers for reasoning loops, and predictable task pricing, developers and solopreneurs should avoid deploying it in production.

Hyperagent promises agents that can research, code, build sites and documents, work through browsers and shells, develop memories and skills, and deliver through Slack, Telegram, webhooks, and schedules. We tested that promise against the standard that determines whether an agent belongs in production: can it finish routine work without rereading itself into an unpredictable bill?

The Hyperagent agents in our account repeatedly revisited decisions, reread context, narrated reversals, and circled website-build work instead of executing it. Activity accumulated, but useful output did not advance in proportion to the resources consumed. We call that pattern a cognitive spin-lock.

Our account records give the experience an economic scale. The reviewed sessions accumulated more than 1.29 billion Claude Opus cache-read tokens and 164 million cache-create tokens. Promotional credits initially concealed the cost; subsequent cash charges, a separate $500.43 invoice, and two retrieval-only charges exposed it.

Cost Sequence

Hidden Baseline

Five April and May web builds consumed approximately $1,000 in promotional credits. We paid effectively no cash for that batch because the credits absorbed the charge. The usage was not free. It was covered.

That distinction created a misleading baseline. The promotional balance made the operating pattern appear inexpensive before comparable work reached our cash account.

Cash Explosion

Five substantially similar builds, in just one month, June, produced $1,259.43 in out-of-pocket charges. During this period, we moved from the $100 plan to $250 and then $500 per month, yet additional overages continued.

The comparison is straightforward: roughly $1,000 in early usage was absorbed by promotional credits; five substantially similar later builds generated $1,259.43 in cash expense. The higher subscription tiers did not make the resulting cost predictable.

One invoice illustrates the scale of the token burn. Invoice SMGSFV-00015, dated July 10 and covering usage immediately after our June 27 upgrade, itemized:

• Opus cache-create tokens – 164.9 million tokens, representing $1,031.08 in raw usage cost.
• Opus cache-read tokens – 1.29 billion tokens, representing $649.43 in raw usage cost.

Together, these line items represented $1,680.51 in raw usage cost before any subscription allowance, credits, discounts, or billing adjustments.

Raw usage cost is the gross token value before those adjustments, not the amount ultimately charged on the invoice. It shows the scale of the compute Hyperagent consumed even when plan allowances or credits reduced the cash balance.

$500 Spike

A separate later invoice for routine work reached $500.43, outside the five-build June total. We requested a full refund. Hyperagent initially refused and later issued a $250 credit.

After Hyperagent’s support representative cited specific threads to justify the charges, we asked a senior engineer to examine the event logs for two of them: a real-estate website build and a webmaster thread. Hyperagent refused the request.

The credit reduced the balance but left the operating question unanswered: why did one routine run reach $500.43, and what would prevent another one?

Retrieval Tax

After receiving the $250 credit, we ran several routine maintenance tasks. Two quickly showed that the cost problem persisted. Downloading an existing ZIP cost $3.08. Recovering a previously discussed routine from chat history added $4.01. The combined charge was $7.09.

Neither task produced a new build, asset, or piece of content. Both retrieved material that already existed. The charge was wildly disproportionate to the value of the work and showed that even tightly bounded recovery tasks could become expensive.

Comparable retrieval work should cost pennies in model tokens, not dollars, especially when no new code, asset, or content is produced.

Cache Totals

Anthropic’s prompt-caching documentation explains that cache writes prepare reusable prompt context and cache reads reuse that context at a reduced input-token rate. These metrics measure context processing. They do not measure productive output, nor do they prove by themselves that an agent was reasoning effectively.

Our evidence therefore has two distinct parts: Usage records establish immense repeated context consumption. Session histories establish the repeated reversals, rereading, and delayed execution we observed while that consumption accumulated.

The combination is the problem. Hyperagent’s agents repeatedly reopened settled choices while the meter continued running, including periods when the system was not producing new code, assets, or other usable work. A finite website task became an open-ended reasoning bill.

Cognitive Spin-Lock

We repeatedly watched the same sequence: a decision, a second-guess, a reread of surrounding context, an explanation of a new path, and then a return to a version of the earlier decision. The agents should have executed, stopped, or asked one focused question. Instead, they continued reconsidering.

This was not one bad answer. It was a recurring operating pattern: decisions revisited, context reread, reversals narrated, execution deferred. The result was slower work and token consumption detached from useful progress.

Here is one verbatim example from a Hyperagent chat screenshot:

The user’s being warm and playful about the inconsistency I caught, and they’re genuinely opening the door for me to help tidy up those Ubertrend descriptions. I should acknowledge their appreciation without overdoing it, then lean into the offer — this feels like a natural next step in our conversation.

I notice they never actually answered whether it’s “Woman’s” or “Women’s” as the canonical form, so I need to pin that down before updating my memory. Looking at what a proper cleanup would involve, each Ubertrend should have a consistent name, a tagline, a concise definition, a fuller description, historical context, and examples of trends that fit under it. The Airtable table I checked earlier only showed Name and linked records — no description fields were visible yet, so the user might be storing those details.

The agent spent context analyzing our tone, narrating the conversation, and planning how to acknowledge appreciation before addressing the work. It eventually identified one legitimate ambiguity, but buried that question beneath unnecessary meta-commentary and an unsolicited expansion of the assignment.

Website production made the failure especially visible. The agents could always propose one more refinement, reread one more requirement, or regenerate another piece of implementation. Hyperagent did not impose a dependable end condition before the work became economically unreasonable.

Support Response

When we challenged the charges, Hyperagent support characterized the consumption as “legitimate server activity.” That may describe what its infrastructure recorded. It did not explain why the activity was necessary, why substantially similar work moved from credit-covered usage to four-figure cash expense, or how we could prevent recurrence.

Support is part of the product when customers confront an unexpected bill. We needed a usable diagnosis and a prevention mechanism. We received neither. The later $250 credit addressed part of one charge, not the underlying production risk.

Promise Versus Production

Hyperagent publicly presents agents that work across browsers, shells, deliverables, memories, skills, and multiple communication surfaces. Our review concerns the production reality we encountered while using those agents for routine website work and artifact retrieval.

We do not judge a production agent by the most ambitious task it can describe. We judge it by whether it can finish ordinary work without repeatedly revisiting its own reasoning and producing costs that bear little relationship to the result.

Hyperagent failed that standard. Our usage records, billing history, support correspondence, task histories, and session observations show excessive context consumption without predictable, proportionate output.

Conditions for Retest

Hyperagent has no place in our production workflow until it prevents runaway reasoning loops and makes task costs predictable. Before we would reconsider it, we would require:

1. Live cost visibility – A task-level view that shows token consumption while an agent runs.
2. Hard spending limit – A control that stops a task before it becomes an expensive loop.
3. Execution trace – A record that separates productive work from repeated context retrieval and retries.
4. Bounded retrieval test – A comparison measured against direct access to the same file or repository.
5. Repeatable costs – Outcomes whose costs can be explained before the workflow is scaled.

Those are ordinary production controls. Our test showed why they are necessary.

Operator Verdict

Avoid. The documented cost sequence, recurring agent loops, inadequate support explanation, and disproportionate retrieval charges are sufficient reason for us not to recommend Hyperagent.

Until the platform can stop runaway work and make task costs predictable, it has no place in our production stack.

Evidence Base

This review draws on six categories of evidence:

• Account usage analysis – Records cache-read and cache-create token totals.
• Billing records – Cover promotional-credit consumption, June cash charges, subscription changes, the separate $500.43 invoice, and the later $250 credit.
• Support correspondence – Documents the disputed consumption and refund request.
• Task records – Cover the $3.08 ZIP retrieval and $4.01 chat-history recovery.
• Session histories – Document repeated reversals, context rereading, and delayed execution.
• Public documentation – Covers Hyperagent’s current positioning and Anthropic’s technical explanation of prompt caching.

The billing and behavioral findings describe our test account and our operating experience. The verdict is our production decision based on that record.