dashgin — field reports

MCP Tool Bloat: Why 546 Tools Cost Me $1,557 (and the ~700-Token Fix)

Sat, 15 Aug 2026 00:00:00 GMT

This is the technical companion to How My Self-Hosted AI Agent Burned $1,557 in 2 Days. If you want the token math, the root cause, and the actual fix, this is it. No infrastructure specifics — just the mechanics that apply to any agent.

The forensics

Two days of Hermes Agent on Claude Opus 5, billed through AWS Bedrock:

3,187 model calls
350 million input tokens, 1.86 million output tokens
~110,000 input tokens per call on average — some at the 500k context ceiling
Cost: ~$1,557, of which 97% was input

Read that last line again. Almost none of the cost was the model thinking (output). It was the same giant context being re-sent and re-billed on every single call.

Where 110k tokens per call comes from

The Dokploy MCP server exposed 546 tools. In a naive agent setup, every one of those 546 tool definitions — name, description, and full JSON parameter schema — gets injected into the model's context on every request.

That's ~500k tokens of tool schemas riding along whether the user said "deploy the staging service" or just "hi".

At Opus 5 pricing — $5 per million input tokens — 100k tokens of tools per call = ~$0.50 per call in tool overhead alone, before the model reads a single word of the actual conversation. Multiply by thousands of agentic tool-loop iterations, add 3× retries on every error, and you get $1,557 in 48 hours.

Why the same tools + model are nearly free elsewhere

I use the same 546-tool Dokploy MCP server with the same Claude Opus 5 in Claude Code, for a tiny fraction of the cost. Two mechanisms explain the entire gap:

1. Deferred tools (the #1 difference)

Claude Code doesn't dump all tool schemas into context. It keeps only the tool names and a one-line description, then fetches a tool's full parameter schema on demand — the first time the model actually wants to call it.

Naive agent: 546 full schemas in context, every call → ~500k tokens
Deferred: ~546 names in context, schemas fetched as needed → a few k tokens

Same capability. ~100× less context. This alone would have turned my $1,557 into ~$15.

2. Prompt caching

The static prefix of a request — system prompt + tool definitions — is identical across calls in a session. With prompt caching enabled, that block is written to cache once and read at ~10% of the input price on subsequent calls (or skipped entirely on exact hits).

My self-hosted agent had caching off by default, so it paid full input price for the entire bloated prefix on every one of 3,187 calls.

Same model. Same tools. The cost difference was 100% context management.

The real fix: a skill instead of an MCP server

Here's the insight that generalizes. You almost never need 546 tools. You need about 10. Deploy, redeploy, restart, stop, logs, create, add-a-domain — that's the daily reality.

So instead of an MCP server that injects 546 typed tools, I wrote a skill: a ~700-token Markdown doc that teaches the agent to hit Dokploy's HTTP API with curl, using the one generic terminal tool it already has.

	MCP server	Skill (curl + docs)
Tools in context	546 schemas (~500k tokens)	1 generic tool + ~700-token doc
When loaded	every call	only when relevant (progressive disclosure)
Reliability	high (typed params)	slightly lower (agent builds the call)
Per-call cost	~$2.50	~$0.003

The skill documents the ~10 common operations as copy-paste curl examples, and points to the full API spec for the rare cases — so the 500+ other operations are fetched on demand and never sit in context. Roughly 700× smaller per call.

This is the pattern for any fat MCP on a self-hosted agent: if a server exposes dozens of tools you mostly don't use, a skill that documents the API and uses the terminal is dramatically cheaper. MCP's typed-tool reliability is worth it for a handful of tools, or in a client that defers schemas — not for 546 loaded on every call.

The rebuild checklist

If I were standing this agent back up, in order of impact:

Don't default to the flagship model. Use a cheap-but-capable model (Kimi K2.5, GLM-4.7-flash, Qwen3-Next) as the daily driver; reserve Opus for genuinely hard tasks. (5–70× cheaper.)
Don't load a 546-tool MCP into a client that can't defer. Replace it with a skill, or trim the toolset. (~100× less context.)
Enable prompt caching. Stop re-billing the static prefix. (~90% off repeat calls.)
Cap the budget low. Budget alarms lag ~a day; a $50 cap catches a runaway before a $200 one would.
Bound the loops. Lower max-turns so an agentic loop can't spiral, and don't retry 3× into a wall.

With all five, the same usage that cost $1,557 would run under $30.

The one-line takeaway

Tokens are not just what the model writes — they're everything you make it read, every time. A 546-tool MCP is 546 tools you pay for on every call. Manage the context, and a self-hosted agent is cheap. Ignore it, and it's a four-figure surprise.

S3 Said 27 GB. The Bill Said 73.

Sat, 15 Aug 2026 00:00:00 GMT

I was checking storage costs on a digital asset manager I'm building. aws s3 ls said the bucket held 856 objects totalling 26.7 GB.

Cost Explorer said I was being billed for 73.2 GB.

Neither number was wrong. The 46 GB gap had been sitting there for two months, invisible to every tool I normally use, and the story of how it got there turned out to be more interesting than the storage cost — which, for the record, was $1.65 a month. This is not a post about saving money.

The part of S3 that doesn't show up in listings

When you upload a large file to S3, the client doesn't send it in one request. It calls CreateMultipartUpload, gets an upload ID, pushes the file up in chunks, then calls CompleteMultipartUpload to stitch them together into an object.

Until that final call lands, the uploaded chunks are real, stored, and billed — but they are not an object. ListObjects doesn't return them. aws s3 ls doesn't see them. The S3 console doesn't show them on the objects tab. They exist in a separate namespace you have to ask for explicitly:

aws s3api list-multipart-uploads --bucket my-bucket

I ran it expecting nothing:

incomplete multipart uploads: 47

Forty-seven abandoned uploads. All the same 1.06 GB file. All initiated within a six-second window on June 6th, at 21:17:59 UTC — 1:18 AM my time. Summing their parts came to 48.3 GB.

That was the missing storage.

Now the interesting question

I had the what. I had no idea about the why. There were no logs — this was a browser upload that died two months ago. No error report, no Sentry event, no server-side trace of the failure. Whatever happened, happened in a tab that no longer existed.

But S3 keeps more metadata than people realise. It turned out to be enough.

Clue 1: the ETag says which code wrote the object

Alongside the 47 dead uploads, 19 completed copies of the same video were sitting in the bucket. All 19 shared an ETag:

"b48ab5828a8e25a018b2095f098532d4-212"

For a multipart object, S3's ETag isn't the file's MD5. It's a hash of the concatenated part hashes, with the part count appended after a dash. That -212 is a fingerprint of how the file was uploaded, not just what it contains.

1.06 GB in 212 parts means 5 MB chunks. My backend hardcodes exactly that:

part_size = 5 * 1024 * 1024  # 5MB minimum for S3

The AWS CLI defaults to 8 MB. rclone defaults differently again. That single suffix ruled out "someone ran a CLI command" and pinned every copy to my own application's upload endpoint. I hadn't fat-fingered a script — my app did this.

Clue 2: the gaps aren't random

list-parts tells you which chunks made it. I expected uploads that died at scattered points — that's what a flaky connection looks like.

Instead:

21 of 47 had all 212 of 212 parts uploaded.
26 of 47 had 210 of 212 — missing exactly parts 211 and 212.

Nothing else. No upload stopped at part 47, or 130, or 8.

Twenty-one uploads had every single byte in S3 and were one API call from being finished. The other twenty-six were two chunks short. A network problem doesn't distribute itself like that.

Clue 3: the 33-second window

Each part carries a LastModified. I pulled the newest one from each of the 47 uploads and sorted them:

earliest last-write:  2026-06-06T22:05:30Z
latest last-write:    2026-06-06T22:06:03Z

Every one of the 47 uploads stopped writing inside the same 33-second window, after running for about 47 minutes.

That settles it. Forty-seven independent failures don't synchronise to half a minute. This wasn't 47 uploads failing — it was one thing failing, once, that all 47 were riding on. The tab was closed, or the machine went to sleep. At 2 AM, I'd bet on sleep.

And the parts still being there two months later proves the rest: my cleanup code never ran.

The code

Here's what the browser was doing. Small files were carefully batched:

// Small files: batched to avoid oversized requests
for (let i = 0; i < smallFiles.length; i += UPLOAD_URL_BATCH_SIZE) {
  const chunk = smallFiles.slice(i, i + UPLOAD_URL_BATCH_SIZE);
  // ...upload this chunk...
}

And immediately below it, large files were not:

// Large files: multipart upload flow
const largePromises = largeFiles.map(async (file) => {
  const init = await initMultipart(file);      // opens an S3 multipart upload
  const parts = await uploadMultipart(file);   // pushes ~212 chunks
  await completeMultipart(init, parts);        // finalises
});

await Promise.all(largePromises);               // ← every file, all at once

Ten lines apart in the same function. One path bounded, the other unbounded.

Select 47 large files and you open 47 concurrent S3 multipart uploads and try to push 48.5 GB through a single browser tab. It ran for 47 minutes and got almost all the way — which is its own kind of unlucky.

There was per-file cleanup, and it was correct:

} catch {
  if (fileKey && uploadId) {
    abortMultipart({ fileKey, uploadId }).catch(() => {});
  }
  return null;
}

It never executed. Not because it was buggy — because the failure mode was the thing that runs the catch block ceasing to exist. There is no exception to catch when the JavaScript context is gone.

One hypothesis I had to kill: presigned URLs expire, and mine were set to 3600 seconds. Tempting. But the uploads died at 47 minutes, comfortably inside the window. Expiry wasn't it.

The fix, in three layers

1. A lifecycle rule. This is the one that actually matters:

{
  "Rules": [{
    "ID": "abort-incomplete-multipart-uploads",
    "Filter": {},
    "Status": "Enabled",
    "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
  }]
}

Seven lines of JSON. S3 now reaps abandoned uploads on its own, regardless of what any client does or fails to do. If I'd had this from day one, the 46 GB would have cleaned itself up in a week and I'd never have written this post.

2. Bound the concurrency. A small worker-pool helper with Promise.allSettled semantics:

export async function mapWithConcurrency<T, R>(
  items: readonly T[],
  limit: number,
  mapper: (item: T, index: number) => Promise<R>,
): Promise<PromiseSettledResult<R>[]> {
  const results = new Array<PromiseSettledResult<R>>(items.length);
  let cursor = 0;

  const workers = Array.from({ length: Math.max(1, Math.min(limit, items.length)) }, async () => {
    for (let index = cursor++; index < items.length; index = cursor++) {
      try {
        results[index] = { status: 'fulfilled', value: await mapper(items[index], index) };
      } catch (reason) {
        results[index] = { status: 'rejected', reason };
      }
    }
  });

  await Promise.all(workers);
  return results;
}

Three files at a time instead of all of them. In-flight bytes drop from 48.5 GB to about 45 MB. A dead tab now strands three uploads, not forty-seven.

3. Abort the existing 47. Safe, because they could never be completed anyway — finalising a multipart upload requires the part ETags, and those only ever lived in a browser tab that died in June.

What I'd actually take from this

Cleanup that lives only in the client's catch block is not cleanup.

My abort code was well-written and correct and completely useless, because it assumed the client would survive long enough to run it. That assumption is invisible when you read the code — it looks like proper error handling. It only shows up when the client is the thing that dies.

This generalises past S3. Anything you acquire remotely and release client-side has the same shape: open database transactions, distributed locks, Stripe payment intents, temp files on a server, reserved inventory. If the only thing that frees the resource is code running on the machine that just crashed, then you don't have cleanup — you have cleanup most of the time, and the leaked cases accumulate silently precisely because nothing is around to report them.

The fix is never a better catch. It's a reaper on the other side that doesn't care whether your client is alive.

And the smaller lesson: the bounded loop and the unbounded one sat ten lines apart in the same file. Both looked fine on their own. I wrote both. I reviewed both. What made it visible in the end wasn't reading the code — it was a number in a billing console that didn't match a number in a file listing.

Reconcile your numbers occasionally. The gap is where the interesting bugs live.

Postscript, for honesty's sake: this was me stress-testing my own upload path with a 10-hour 4K video at 1 AM, not a customer incident. Nobody's data was affected and the total cost of the mistake was about eighteen dollars a year. I'm writing it up because the forensics were fun and the design bug is one I expect to meet again.

How My Self-Hosted AI Agent Burned $1,557 in 2 Days

Sat, 15 Aug 2026 00:00:00 GMT

I set out to self-host an AI agent — a little always-on assistant on my own server, wired into Telegram, web search, and my infrastructure. Two days later AWS had billed me $1,557.

Here's exactly what happened, why, and how the same setup costs pennies when done right.

The setup

I put Hermes Agent on a small EC2 box and connected it to AWS Bedrock for the model. Over an afternoon it grew into a proper little stack:

Claude Opus 5 as the brain
A Telegram bot + self-hosted web search
Vision, and a web dashboard behind a domain
A handful of MCP servers for tools — including the Dokploy MCP server, which exposed 546 tools

It worked. It also, quietly, started printing money — for the cloud provider.

The bill

I checked the cost dashboard expecting maybe $20. Instead:

Day 1:  $640
Day 2:  $916   ← and still climbing
─────────────
       $1,557  in 48 hours

A budget kill-switch I'd set up did fire and cut it off — but budget data lags almost a day, so it slammed the brakes only after $1,557 had already gone through.

Why it happened (three mistakes, stacked)

The forensics were brutal and clear: 3,187 model calls, 350 million input tokens in two days. The average call sent 110,000 tokens — some hit 500,000 (the model's ceiling). For simple "hi" messages. Three things multiplied together:

1. I used the most expensive model as the default. Claude Opus 5 is $5 per million input tokens, $25 per million output. Great model. Terrible default for a chatty, always-on agent.

2. I loaded 546 tools into every single call. This is the big one. The Dokploy MCP server dumped all 546 of its tool definitions — roughly 500k tokens of JSON schemas — into the context of every request. At Opus prices that's ~$2.50 per call, just to say hello.

3. No caching, and retries on every error. The model re-read that giant context from scratch on every call (no prompt caching on Bedrock by default). And my error-heavy setup meant every failure retried 3× — three real, expensive calls each.

Cheap model? No. Small context? No. Caching? No. It was the perfect storm.

The plot twist: I use the exact same thing every day, and it's basically free

Here's what stung. I use that same Dokploy MCP server with the same Opus 5 inside Claude Code — constantly — and it costs me nothing close to this.

Why? Two things Claude Code does that my self-hosted agent didn't:

Deferred tools. Claude Code keeps only the tool names in context and fetches a tool's full schema only when it actually needs it. It carries ~1% of those 546 definitions per call. My agent stuffed 100% of them into every request. Same MCP server — 100× the context.

Prompt caching. The big static block of tools and system prompt gets cached, so repeat calls pay ~90% less for it. On Bedrock, with caching off, I paid full price every time.

Same model. Same tools. The difference was entirely in how the context was managed.

What the same usage would have cost

Model	Same ~350M tokens
Claude Opus 5 (what I ran)	~$1,800
Kimi K2.5	~$215
Qwen3-Next	~$50
GLM-4.7-flash	~$25

And that's before fixing the context bloat. A cheaper model + deferred/trimmed tools + caching would have turned the whole two-day binge into under $30.

The lessons

If you self-host an AI agent with tools, tattoo these somewhere:

Don't default to the flagship model. A cheap-but-capable model (Kimi, GLM, Qwen) as the daily driver, Opus only for hard tasks.
Tools are not free — they ride in your context. 546 tools in every call is 546 tools you pay for in every call. Trim them, or use a client that defers tool schemas.
Turn on prompt caching. Static context (tools, system prompt) should be cached, not re-billed every call.
Your budget alarm lags ~a day. Set the cap low, because you'll blow past it before it notices.
Retries multiply mistakes. An error-heavy config with 3× retries is 3× the burn.

I killed the VM, kept encrypted backups, and rotated every key. The $1,557 was a one-time tuition payment. The agent itself was a good idea — I just handed it the priciest model, buried it in tools, and turned off every cost-saving feature at once.

Do the opposite, and a self-hosted agent is genuinely cheap. Ask me how I know.

A deeper technical breakdown — the token math, the fix, and how I turned a 546-tool integration into a ~700-token skill — is in the companion post.