DEV Community: Mirza Iqbal

My nightly Claude Code cron was about to start costing real money

Mirza Iqbal — Sun, 14 Jun 2026 15:01:36 +0000

A billing change lands tomorrow, and last week I went looking for what it would break in my own setup.

Its headline is narrow. interactive subscription work stays exactly as it was, but anything running headless, in the background, on a schedule, starts drawing from a separate metered pool with its own limit.

My subscription was safe. my habits were not.

Somewhere along the way I had built the thing everyone builds. a nightly job that wakes up, calls the model to do some work, and goes back to sleep. Quiet, useful, and as of tomorrow, billed against a pool I never wanted it touching.

Two ways my work talked to Claude.

When I actually looked, every call I made fell into one of two buckets.

First, there was me, sitting there, working live. asking, building, iterating. That is what the subscription covers, and it stayed put.

Second, there was automation. scheduled jobs, background runs, anything that called the model with nobody in the loop. I had treated both as "using Claude", one undifferentiated thing. That billing change drew a hard line between them that I had never bothered to draw myself.

One of them was about to get metered.

Interactive work was fine. Automated work was the exposure.

That nightly cron had felt free, because it rode the same subscription I was already paying for. Tomorrow it stops being free and starts metering against a separate quota. Same job, same output, suddenly a line item.

Multiply one quiet background call by every night of a month, and the free automation I had forgotten I was running becomes a bill I never planned for.

Why the nightly cron was the casualty.

That broken pattern was specific. a headless call to the model, fired by a schedule, with nobody watching.

It was also the shape I had reached for without thinking, because backgrounding a task feels like the smart, hands-off move. That change turned my cleverest-feeling automation into my most expensive one.

How I actually split it.

I did not kill the automation. I cut it in two.

Work that needs no model, the gathering, the checking, the prep, stays in a plain scheduled script that costs nothing. Work that genuinely needs Claude moved back to where I am present and the subscription covers it. That schedule still runs. it stops calling the model behind my back.

Unglamorous, and the whole fix. background does the cheap deterministic work, model work happens in the lane that was always covered.

My honest opinion.

Here it is. tomorrow's split raised no costs for me. it surfaced which of my automations were never on the subscription to begin with.

I had blurred two different things into one word and let a metered pattern hide inside a flat-rate habit. That change created nothing new. it switched on a light that showed what was already there. Anyone running scheduled model calls on a subscription plan has the same light about to come on.

What the split actually exposed.

Nothing about my work got worse. one pattern got a price tag, and that price tag was honest.

What I gained is knowing, for every automation I run, which side of the line it sits on. metered or covered, background or present, deterministic or model. I should have known that before a billing change forced me to look. now I cannot unsee it, and every new automation gets sorted on day one.

If you run anything that calls a model on a schedule, go find it before tomorrow does. Whatever feels free is the thing most likely to surprise you.

Your turn

What background job are you running that you have never checked the bill for.

If this was useful

I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. LinkedIn, YouTube and X under Mirza Iqbal, and the work at next8n.com.

My 8-hour job died at hour 3 and I had checkpointed almost nothing

Mirza Iqbal — Sun, 14 Jun 2026 08:31:52 +0000

For hours the job had been running clean.

It was a long grind, the kind you start and walk away from, trusting it to chew through the pile while you do something else. Hundreds of items, one after another, all fine.

Three hours in, the quota ran dry and everything stopped.

I came back to a dead run and a sinking feeling. Work had been going for hours, yet my last save sat way back near the start, because I had told myself I would commit when it was all done. So resuming meant starting again near the beginning, with three hours of finished work stranded and no way to reach it.

That is the moment I learned the interruption was never the real problem.

The cap does not care about your progress.

A quota, a timeout, a crash, a killed process. None of them check whether you are at a clean stopping point. They land whenever they land, mid-item, mid-thought, mid-everything.

Blaming the interruption is comfortable, because it sits outside you. It is also the one part you cannot control. Your cap will always arrive at the worst moment, and planning around "it will not happen this run" is planning to lose work.

So I stopped trying to dodge the interruption and started designing for it.

Resume cost is a number you choose.

Here is the idea that changed how I build long jobs. how much work an interruption can destroy is a setting, decided before the run starts.

Save progress every N items and your worst case loss is N items. Pick N of 500 and a crash can cost you 500 items of redone work. Pick N of 10 and the same crash costs you 10. Same interruption, wildly different pain, and the only difference is a decision you made up front.

That grind had effectively chosen N of everything. one commit, at the very end. So the worst case was the entire run, and the entire run is what I paid.

Why committing at the end is the bug.

A single end-commit feels efficient. fewer writes, cleaner history, less fuss while the job runs.

It is a trap. every interruption before that final commit erases all of it. You have built a system whose resume cost equals its full runtime, then handed it to an environment that interrupts at random.

My fix was unglamorous. save often, in small bounded steps, and never save a broken half-item. A failed item gets skipped, never checkpointed, so you never resume into a corrupt state. Boring, mechanical, and it turns a lost afternoon into a lost minute.

The opinion I will defend.

Here it is. blaming the cap, the timeout, or the crash for lost work is misdiagnosing your own design.

An interruption is a certainty, not an accident waiting to maybe happen. If losing the run hurts, the real fault is the unbounded resume cost you allowed, while the interruption was always going to come. Bound that cost and the same crash becomes a shrug.

What checkpoint discipline actually buys.

Nothing about my jobs runs faster now. checkpointing adds a little overhead, and I pay it gladly.

What I bought is the right to walk away. A long job can die at any moment, at hour one or hour seven, and the cost is always the same small number of items rather than the whole run. The crash still happens. I stopped letting it set fire to hours of finished work.

If you run anything long, a batch, a grind, an overnight pipeline, decide your resume cost on purpose before you start it. Your cap is coming. the only open question is how much it gets to take.

Your turn

What is the longest run you have lost, and what would a checkpoint have saved.

If this was useful

I stopped letting the invoice be the first place I learn my LLM costs spiked

Mirza Iqbal — Sat, 13 Jun 2026 09:02:20 +0000

For a while, the invoice was my cost monitor.

I would build, ship, run agents all month, and find out how it went when the bill arrived. If something had gone wrong, the bill told me. Calmly. Weeks late.

Terrible way to learn you have a problem.

One month a small mistake quietly burned money for days, and my running total still looked normal until the very end, because a month is a big bucket and a few bad days hide inside it. By the time the number was obviously wrong, the money was already spent and I could do nothing but pay it.

So I stopped trusting the invoice to warn me. It cannot. Wrong shape for the job.

Why a bill is a lagging alarm.

A bill is cumulative. It only ever goes up, and it reports at the end. Both of those make it useless as a warning.

Cumulative means a spike gets averaged into a month of normal usage, so it barely moves the total until it has run for a while. End-of-period means you find out after you can act. An alarm that rings only once the house has burned down has a better name. a receipt.

To catch a cost spike you have to watch something that moves the moment the spike starts, and that is never your total.

Signal one. the burn rate.

First thing I watch now is spend per unit of time rather than spend in total.

Burn rate reacts at once. A retry storm, a jump to a heavier model, an agent stuck in a loop, all of them show up as the rate climbing within the hour, long before the monthly total looks unusual. Your total stays calm while the rate is already screaming.

Rate leads because it measures change, and a spike is nothing but change.

Signal two. the cost-to-work fit.

Rate alone is not enough, because sometimes you genuinely are doing more work and spending more is correct.

So the second signal is cost measured against the work it produced. Call it cost-fit. Spend climbing while output stays flat is the real alarm. Spend climbing because you shipped twice as much is fine.

Cost-fit tells you whether a spike is a problem or a busy day. Without it you either miss real spikes or flinch at every normal one.

Why the total fools you.

A running total feels like the honest number because it is the one you pay. Yet it lags, it averages, and it is the hardest view to act on.

Watching the total is watching the scoreboard after the game has ended. Watching the rate and the fit is following the game while you can still change the score.

The opinion I will defend.

Here it is. Of every place to discover a cost problem, an invoice is the worst, and most people have no other place.

They open a dashboard, see a running total, feel informed, and miss every spike that matters, because a total cannot show a spike until it is too big to undo. A prettier dashboard does not change that. Watching the two leading signals does.

What watching the right two changed.

Nothing about my spending got cheaper because I started watching it. that was never the point.

A problem now reaches me the same hour it starts, while it is small and reversible, instead of at month-end when it is large and already paid. A runaway loop that once cost me a quiet week now costs me twenty minutes. The spike still happens. I no longer learn about it from the invoice.

Got only the bill as your cost signal? Then you are reconciling spend after the fact rather than watching it. Watch the rate, watch the fit, and let the invoice go back to being a receipt instead of a warning that always arrives too late.

Your turn

What is the last bill that surprised you, and what would have warned you sooner.

If this was useful

I automated my content pipeline and it kept writing the wrong articles

Mirza Iqbal — Fri, 12 Jun 2026 20:51:37 +0000

For weeks my content pipeline did exactly what I built it to do.

It pulled from a pile of sources, drafted clean articles, rendered the covers, handled the publish. The machinery worked.

And the output was wrong.

Not broken-wrong. Polished, on-topic, technically fine, and still the wrong thing to have written that day. I kept shipping articles nobody needed, on the day nobody was asking, while the thing actually worth saying sat unwritten in a folder.

It took me an embarrassing while to see it. I had automated the easy half and left the hard half to luck.

Generation was never my bottleneck.

Writing is the part everyone races to automate. Feed in a topic, get out a draft. That problem is, for practical purposes, solved. A pipeline can produce a competent article on almost anything you point it at.

So the volume went up and the value did not. More posts, same flat result. I had mistaken throughput for progress, which is the oldest trap in automation.

The draft was never the scarce resource. The decision in front of the draft was.

Selection is the job nobody automates.

Selection is choosing what deserves to exist before a single word is written. Of all the things you could say today, which one is worth your name on it.

That choice carries everything the draft cannot. Is this relevant to the people I want to reach. Is the timing right, or is the moment already gone. Does it sound like me, or like anyone. Is it the thing I am uniquely placed to say, or a thing a thousand others could say better.

A generator answers none of that. It will write whatever you hand it with equal confidence, including the wrong thing, beautifully.

Why a machine cannot pick for you.

Selection runs on context the machine does not have. What you learned last week from a client. The argument that changed your mind. The thing your audience is quietly struggling with that nobody has named yet.

That is taste, and taste is lived. It is the accumulated judgment of a specific person who has paid attention to a specific world. You can feed a model your past, but you cannot feed it your nose for what matters next.

So when I let the pipeline both choose and write, I was handing away the one part that was actually mine. The part that was the whole point.

The opinion I will defend.

Here it is. Generation is a commodity now, and selection is the entire game.

The people whose content lands are not better writers than the people whose content disappears. They are better choosers. They have a sharper sense of what is worth saying, to whom, right now. The draft is downstream of that, and the draft was never where the edge lived.

If your content is not connecting, do not reach for a better generator. Look at what you are choosing to make, and who decided it.

What changed when I treated selection as the work.

I did not throw the pipeline away. I moved myself to the front of it.

The machine still does the heavy lifting it is good at. But the choice of what to write now sits with me, on purpose, before anything runs. I look at what I actually learned this week, what my readers are actually stuck on, what only I can say with a straight face. Then the pipeline works on a target I chose, instead of a target it guessed.

The volume dropped. The hit rate climbed. Fewer articles, more of them worth reading. That trade was the whole fix, and it cost me nothing but the honesty to admit that the easy half had never been the problem.

If you are automating your content and the results feel hollow, check which half you handed to the machine. If you gave it the choosing, take that back. Let it write. You decide what is worth writing.

Your turn

What do you let a tool choose for you that you should be choosing yourself.

If this was useful

My first production agent was spaghetti because one layer did three jobs

Mirza Iqbal — Fri, 12 Jun 2026 07:17:31 +0000

It demoed perfectly.

Clean output, every case green, the kind of run that makes you screenshot the terminal.

Then it reached production and fell apart inside a day.

What followed was the worst kind of debugging. The agent would return something wrong, and I could not tell why. Was it the prompt. Was it a timeout on a tool call. Was it stale data. Was it a retry firing twice and confusing the next step. I spent far longer staring at that agent than I ever spent building it.

That pain was on the dev.to front page this week. someone wrote about spending ten times longer debugging AI code than writing it. I felt that one in my spine.

Here is what I eventually found. one layer of my agent was quietly doing three jobs at once.

Most agent failures that people blame on the model are not reasoning failures at all. They are IO failures wearing a reasoning costume. The model looked broken because the layer around it was broken, and the two were tangled into the same lump of code.

As a Mastra Agent Ambassador I now build every agent around one promise. each layer does exactly one job. Three layers, three responsibilities, nothing crossing a line it should not.

Reasoning. the layer that decides.

This is the model. Its only job is to think and choose. Given clean inputs, what is the next step.

It should never fetch data. It should never retry a failed call. It should never format a payload for a downstream system. The moment reasoning starts doing IO, you can no longer tell a bad decision apart from a bad fetch, and your debugging time doubles overnight.

Keep this layer boring. Inputs in, a decision out.

IO. the layer that talks to the world.

Every call to an API, a database, a tool, a file. All of it lives here, and all of it is deterministic.

This is where retries belong. Where timeouts belong. Where validation belongs. Where the guardrails belong, the checks that clean what comes in before the model ever sees it, and what goes out before a user ever does. Mastra gives you input and output processors for exactly this, a home for that discipline so it is not smeared across your prompts.

When IO is its own layer, a failed call reads as a failed call. It surfaces as an IO error, not as a confusing model answer. That one separation is what gave me my nights back.

Orchestration. the layer that sequences.

This is the loop. It holds state, decides when to call reasoning and when to call IO, manages approvals, and knows when the task is finished.

It does not think, that belongs to reasoning. It does not fetch, that belongs to IO. It conducts.

When orchestration is thin and explicit, you can read your agent like a short story. step, check, step, check. When it is tangled with the other two, you get the spaghetti I shipped the first time.

Why the framework alone will not save you.

Here is the opinion I will defend. the framework is not the thing that keeps you clean. the layer discipline is.

You can write the same spaghetti inside Mastra that you would write with nothing at all. The tools make the right structure easy, but they do not force it on you. If you let reasoning fetch, and IO decide, and orchestration think, no framework on earth will make that agent debuggable.

The discipline stays yours to keep. The framework only makes keeping it cheaper.

What changed after I split them.

The next agent I built with the three layers held apart was not smarter. The model was the same model. But when something broke, I knew within a minute which box to open. A wrong answer was a reasoning issue. A missing value was an IO issue. A step out of order was orchestration. The fog was gone.

That is the whole payoff. not a cleverer agent, a debuggable one. And a debuggable agent is the only kind you can run in production without dreading the pager.

If you are building your first real agent, do not start with the prompt. start by drawing three boxes and promising yourself that nothing leaks across a line it should not own. It is the least glamorous decision you will make, and the one that saves you the most sleep.

Your turn

Which layer do you overload by accident most, reasoning, IO, or orchestration.

If this was useful

I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building agents in the open is useful to you, that is where it lives. LinkedIn, YouTube and X under Mirza Iqbal, and the work at next8n.com.

My first production agent was spaghetti because one layer did three jobs

Mirza Iqbal — Fri, 12 Jun 2026 07:09:53 +0000

It demoed perfectly.

Clean output, every case green, the kind of run that makes you screenshot the terminal.

Then it reached production and fell apart inside a day.

That pain was on the dev.to front page this week. someone wrote about spending ten times longer debugging AI code than writing it. I felt that one in my spine.

Here is what I eventually found. one layer of my agent was quietly doing three jobs at once.

As a Mastra Agent Ambassador I now build every agent around one promise. each layer does exactly one job. Three layers, three responsibilities, nothing crossing a line it should not.

Reasoning. the layer that decides.

This is the model. Its only job is to think and choose. Given clean inputs, what is the next step.

Keep this layer boring. Inputs in, a decision out.

IO. the layer that talks to the world.

Every call to an API, a database, a tool, a file. All of it lives here, and all of it is deterministic.

When IO is its own layer, a failed call reads as a failed call. It surfaces as an IO error, not as a confusing model answer. That one separation is what gave me my nights back.

Orchestration. the layer that sequences.

This is the loop. It holds state, decides when to call reasoning and when to call IO, manages approvals, and knows when the task is finished.

It does not think, that belongs to reasoning. It does not fetch, that belongs to IO. It conducts.

When orchestration is thin and explicit, you can read your agent like a short story. step, check, step, check. When it is tangled with the other two, you get the spaghetti I shipped the first time.

Why the framework alone will not save you.

Here is the opinion I will defend. the framework is not the thing that keeps you clean. the layer discipline is.

The discipline stays yours to keep. The framework only makes keeping it cheaper.

What changed after I split them.

That is the whole payoff. not a cleverer agent, a debuggable one. And a debuggable agent is the only kind you can run in production without dreading the pager.

Your turn

Which layer do you overload by accident most, reasoning, IO, or orchestration.

If this was useful

Green tests, broken docs. Dogfooding caught what 15 tests missed

Mirza Iqbal — Thu, 11 Jun 2026 14:41:19 +0000

A broken doc still renders.

That is the whole reason documentation rot is so dangerous.

The page looks fine right up to the moment someone clicks the link that went nowhere.

This week I shipped a small tool to catch that, and the tool taught me a lesson I keep relearning.

What the tool does

It scans a folder of markdown and flags three kinds of rot.

A link to a file that moved and now returns a 404.

A table of contents anchor that drifted away from its heading.

And the one most link checkers skip, a doc that nothing else references.

That last one deserves a name. It is dead code wearing a different hat.

Nobody deletes it because nobody is sure it is unused. Nobody reads it because nothing points to it. It sits there and goes stale, quietly lying to the next person who finds it by accident.

If you have ever run a dead code check on a codebase, you already understand the orphan doc. Same idea, applied to markdown.

The part where I got humbled

I wrote 15 tests. They ran on Ubuntu and macOS. All green.

Then I pointed the checker at my own setup, hundreds of real files, and it lit up a long table of contents as completely broken.

Every anchor reported wrong.

Except the anchors were fine. I checked by hand. The links matched the headings.

The bug was mine, and it was a good one.

The bash trap

Here is the heading lookup, simplified.

set -uo pipefail

# does the anchor match any heading slug in the file?
heading_slugs "$file" | grep -Fxq "$anchor" || report_broken "$anchor"

It reads as correct at a glance. Generate the heading slugs, search them for the anchor, and report only when the search fails.

The trap is the interaction between two things you turned on for safety.

grep -q exits the moment it finds a match. It does not read the rest of the input. When it exits, it closes the pipe.

heading_slugs, still writing, gets a broken pipe and dies with a non-zero status.

set -o pipefail then declares the whole pipeline failed, because one stage in it failed, even though the stage that mattered succeeded.

So a real match was reported as a miss. On a one heading doc the producer finishes before grep closes the pipe, so the bug hides. On a forty heading doc it fires every time.

The fix is to keep the producer out of grep's pipeline.

# process substitution. grep's exit status is its own, the producer's death
# is not part of the pipeline, so pipefail stays out of it.
grep -Fxq "$anchor" <(heading_slugs "$file") || report_broken "$anchor"

Two smaller bugs were hiding behind the loud one. The slug list was printed without newlines, so every slug ran together into a single line. And the slug collapsed repeated dashes while the platform that renders the anchors does not, so a heading with a separator mismatched its own valid anchor. The fix for the second one is to normalize both sides through the same function, so any difference cancels.

The two lessons

A passing test suite proves the cases you imagined. It says nothing about the cases you did not.

My tests had one heading because one heading was easy to write. Real docs have forty, and forty is where the bug lived.

The fastest way to find what your tool misses is to turn it on yourself first. The real corpus is the test the synthetic fixtures cannot be.

I shipped a checker for rot, and the checker found rot in the work of the checker's own author. That is the job working as intended.

One question for you

If you write bash, this trap is somewhere in your scripts right now.

A strict mode plus a command that exits early is a quiet false signal, and it only shows up under the inputs you did not test.

I write about the unglamorous parts of building tools that survive real use, the bugs that pass every test and fail on contact with reality.

So tell me. What is the bug your own tests were too polite to catch?

I keep shipping my best work to an audience of one

Mirza Iqbal — Thu, 11 Jun 2026 05:50:52 +0000

There is a folder on my machine I am quietly proud of.

Almost nobody has seen what is inside it.

Years of work live there. A knowledge system I built and rebuilt until it actually held. Pipelines that run on their own. An archive I shaped book by book, late at night, to a standard I would defend to anyone.

The audience for all of it is one person.

Me.

I am good at the part nobody watches

Give me a hard private problem and I will go deep, finish it, polish it past the point that makes sense, and feel calm the whole way.

Ask me to put a fraction of that in front of strangers and something locks.

The post stays a draft.
The repo stays private.
The talk I could give stays an idea.

The part I have stopped pretending about

Private mastery is a comfortable place to hide.

It feels like work because it is work. Real, hard, skilled work. But it asks nothing of the part of me that is afraid of being judged. No comments. No silence after posting. No one telling me I got it wrong.

A private win cannot be rejected.

That is exactly why it is safe. And safe is the problem.

The bill comes quietly

Nobody can hire what they cannot see.
Nobody can learn from a system that lives on one laptop.
Nobody can follow a person who never shows up.

I have met people who know less than I do and earn more, and for a long time that felt unfair. It is not unfair. They ship in public. They let the work be seen, judged, and remembered. The knowledge was never the thing that paid. Being known for it was.

The fear has already been tested

Four separate organizations made me an ambassador for their tools. I have spoken on a real stage. People I respect chose to work with me.

None of that happened in private.

Every one of those doors opened because, for a moment, I let the work be seen. So the fear has already had its turn. And it lost.

What I am actually doing about it

I am not going to pretend I fixed this.

What I am doing is smaller. One thing leaves the folder each day now. A post. A note. A piece of the work, shown badly rather than hidden perfectly.

This post is one of them.

It is not my best work. My best work is still in the folder. But this one has something the folder never will.

It can be seen.

Your turn

What is the best thing you have built that almost nobody has seen?

If this was useful

I work through this in public now, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives.

LinkedIn, YouTube and X under Mirza Iqbal, and the work at next8n.com.

Four ambassador titles and I still could not press publish

Mirza Iqbal — Wed, 10 Jun 2026 16:47:09 +0000

I knew exactly what to build. The stack, the pattern, the deploy, the post, all of it clear in my head. Almost none of it shipped for years.

That gap has a name most of us avoid saying out loud. Knowing and doing are two very different skills.

This is not a story from someone who never struggled with it. I hold four ambassador titles. Sixteen years in tech. Documented savings in the millions for real enterprise clients.

And I would still sit with a finished thing and refuse to press publish.

For a long stretch I was sure the problem was knowledge. So I learned more. Another framework, another course, another deep read. More input felt like motion.

Learning was the most comfortable way to avoid the actual work. The actual work was exposure.

Private work felt safe. A repo nobody opens. A draft nobody reads. A side project that quietly stays a side project. My best thinking happened where no one could judge it.

Public work felt like walking into a lit room full of people. So I went and found one more thing to learn first.

Here is the part I had backwards.

We keep treating knowledge as the bottleneck. The real one is distribution.

I know developers with a fraction of my knowledge earning far more, because they ship in the open while I polished in private.

What finally broke it had nothing to do with motivation. Motivation is a feeling, and feelings do not arrive on schedule.

The rule that worked was almost too small to be scary. Ship one honest thing today, then do it again tomorrow before the fear catches up.

So I started treating done as the goal and perfect as the enemy. One public post. One small repo. One real reply to a real person who was waiting.

My early ones were not my best work. That was the whole point. Reps were the work. Polish was procrastination wearing a respectable outfit.

If you are sitting on things you know you should ship, look closely at the real blocker.

You probably do not have a knowledge problem. You have an exposure problem wearing a knowledge costume. One more course leaves it exactly where it is. One small shipped thing moves it.

Honesty check, because this is not a victory lap. The freeze still shows up before I publish, including right before this post went out.

What changed is simple. Now I ship anyway, small and often, and let the reps do what reassurance never could.

In the last few weeks that meant public repos, posts here most days, and the messages I had avoided for months. None of them were perfect. Every one of them got shipped.

Your turn

One question, and the easy version of it.

What is the one thing you know you should ship but have not yet?

Name the thing in the comments. Skip the reasons. The thing is enough.

If this was useful

I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Connect on LinkedIn, I am on YouTube and X as Mirza Iqbal, and the work is at next8n.com.

3 patterns broke when I ran Claude Code unattended for 7 days

Mirza Iqbal — Wed, 10 Jun 2026 06:34:50 +0000

API Error: 400 messages.N.content.M: `thinking` blocks in the latest
assistant message cannot be modified. These blocks must remain as they
were in the original response.

That error ended a session I was not watching.

168 hours. 47 sessions. Claude Code running real grinds while I slept, traveled, and worked on other things.

Three patterns broke over the week. None of them were the failure I expected going in.

Here is the strongest thing I took away.

Loud crashes were the failures I worried about. They were rarely the ones that hurt.

What actually hurt looked like forward motion while it quietly destroyed work or stalled the queue.

I run automation like this for a living, across DACH enterprise deployments, and the same three shapes keep showing up. Naming them is most of the fix.

Pattern one. The turn that poisons itself

This was the unexpected one.

With extended thinking on, every assistant turn carries a thinking block that must round-trip back to the model byte for byte on the next request.

Interrupt that turn at the wrong moment, or let an automatic compaction rebuild the history, and the block comes back changed.

Then the server rejects the whole request. Your turn dies. Your run stops.

What surprised me is that nothing in my own tooling could catch it.

That error returns at the transport layer, after the turn has already failed.

My hooks fire around tools and sessions. They never fire around a failed API request.

So the instinct to write a guard that catches it and retries is a dead end. There is no event to hang the guard on.

Here is the real fix. You cannot script your way out of this one. It is a discipline.

Do not resume a turn you interrupted mid-thought. Rebuild the history cleanly, or start fresh, before you continue.

Sit with the cheaper lesson underneath. Some of the most expensive failures cannot be automated around. You can only avoid them.

Pattern two. The cliff at 83 percent

This second pattern cost me the most actual work.

My longest grind committed its progress rarely. One checkpoint every few hours of running.

That feels fine while it runs. It is a trap.

When the rate-limit cap exhausted partway through, the resume point sat hours behind the real progress.

One grind of more than 800 items stalled at 83 percent. Roughly 17 percent of the work was momentum I had to win back by hand.

Run the math and it is plain. Commit once every few hours, and any interruption at hour three erases hours.

This fix is mechanical. How often you commit becomes a property of the loop, something the loop handles on its own so you never have to remember.

Bind the resume cost to a small fixed number of items. A cap exhaustion or a crash then costs you that small number of items. Your afternoon stays safe.

This is the pattern I now refuse to start a long loop without.

Pattern three. The ghost lock

Quietest of the three, and the one that looked most like everything was fine.

Each worker reserved its slot with a lock file. Standard practice for stopping two runs from colliding.

One run got killed hard. The lock file stayed behind, with a dead process id inside it.

My queue then did exactly what it was told. It saw a reservation and waited.

Nothing was running. Nothing was progressing. The dashboard looked busy.

It sat blocked for around 70 minutes before the stale lock aged out on a timer.

Make the lock aware of the thing it protects, and the problem disappears.

Any lock that names a process should release the moment that process is gone. Waiting for a clock to run down is the slow, expensive path.

Reap on death. Keep the timeout only as a backstop.

One thread connects all three

Look at the three together and the shared shape is obvious.

A loud failure is a gift. You see it, you fix it, you move on.

Dangerous failures in an unattended run wear the costume of progress.

A poisoned turn that stops a session you were not watching.

A grind that commits so rarely it gives back hours on the first interruption.

A queue that waits politely on a worker that already died.

Every one of them looked, from the outside, like a healthy system.

Here is the real lesson of running a thing for a week with nobody watching.

Your monitoring is tuned for the errors that shout. The ones that cost you are the errors that smile.

What I am not pasting here

I run a version of each fix in production. The exact instrumentation, the commit-interval numbers, and the runbook that maps each failure shape to a first response are the work I bring to client engagements.

Leaving them out is on purpose.

Paste the implementation, and the next person to hit this copies it and never has the conversation that surfaces the deeper problem underneath.

That conversation is where the real damage gets caught.

Pattern is the gift. Recipe is the work.

Your turn

You have left an agent or a long job running unsupervised at some point.

Something broke while you were not looking.

Which of these three did you hit, and what would you name the one I missed?

Drop the shape you saw in the comments.

Our shared library of failure modes only gets sharper when more of us name the thing out loud.

Your MCP server's write tools are silently dropping their body

Mirza Iqbal — Mon, 08 Jun 2026 14:09:19 +0000

If you have built a Model Context Protocol server with a passthrough tool, the kind that
lets the model call any endpoint, there is a real chance its write operations are quietly
broken in some clients. You may not have noticed, because reads work.

I hit this building an open source MCP server for Hetzner. Listing worked perfectly. Every
create, update, and delete came back from the API with the same complaint.

A valid JSON document is required.

The body was arriving empty. Here is why, and the single line that fixed it.

First, here it is working. This server stands up a load-balanced stack and tears it back
down in plain language, with a cost guard in front of every billed action.

The symptom

A passthrough tool needs a free-form body so the model can send any payload. The obvious
way to type that in Zod looks harmless.

body: z.unknown().optional()

Reads need no body, so every GET sailed through. The moment the model tried a POST, the
body never reached the API.

The root cause

z.unknown() compiles to an empty JSON schema. Not an object, not a string, an empty shape.

Several MCP clients drop a property whose schema is empty. There is nothing to validate and
nothing to send, so the field is stripped before the request leaves the client. Your server
receives the call with the body undefined, forwards an empty payload, and the API rejects it.

The cruel part is that the error comes from the upstream service, not from your server, so
you go hunting in the wrong place for an hour.

The fix

Give the body a real schema. An object is enough, and accepting a JSON string as well makes
it work no matter how a client serializes the payload.

body: z.union([z.record(z.string(), z.unknown()), z.string()]).optional()

Then parse a string body into an object before you use it. The schema is now non-empty, so
clients forward the field, and the string branch covers the clients that send serialized
JSON. That is the whole fix.

How I knew the fix actually held

A schema change you cannot see is a schema change you cannot trust. So I wrote a suite that
drives the compiled server over stdio, the exact artifact a client loads, against the live
API. Reads, the cost and delete guards, and a create then delete for every resource type.
Every billed resource is removed in a finally block, so a failure never leaks a charge.

It caught the bug, proved the fix, and runs on every change now. The number that matters is
not that it compiles, it is that every tool answered the real API and the account was left
clean.

If you build MCP servers

Two things to carry away.

Audit any tool that types an input as unknown or leaves it untyped. Give it a real schema.
Test write tools through the built server against the real service, not only your unit tests. This failure only appeared at the client boundary.

The server I found this in is open source under MIT. It gives an AI assistant the full
Hetzner platform, Cloud, Storage Box, and Robot dedicated servers.

npx -y hetzner-mcp

What is the most painful silent failure you have hit building MCP tools?

Your private GitHub repo CI is one quota away from going red

Mirza Iqbal — Mon, 08 Jun 2026 10:40:03 +0000

status      conclusion   elapsed
completed   failure      2s
completed   failure      1s
completed   failure      3s
completed   failure      2s

Four CI runs.

Every one red.

Every one dead in under three seconds.

No build. No tests. No lint.

I spent twenty minutes reading my own diff for the bug.

There was no bug.

The repo was private, and it had run out of free Actions minutes.

I had green checks for two days.

Then red checks for the better part of a week.

The last green run was the 23rd. By the 25th every check was failing. It stayed red until the monthly minutes reset on the 1st.

Nothing in the code changed across that line.

A quota death wears a code failure's face

This is the part that wastes your afternoon.

A real failure and a quota failure paint the same red X on your pull request.

Same icon. Same color. Same sinking feeling.

So you do the rational thing.

You open the diff. You re-read the test. You blame the last commit.

You push a fix that fixes nothing, watch it go red in two seconds, and push another.

The faster the run dies, the more it feels like your code, because a fast failure reads like a fast, obvious mistake.

It is the opposite.

The tell is in the clock, not the logs

Open the run.

A real failure has a body. Steps that started. A step that executed and then failed. A log you can read.

A quota failure has no body at all.

The run is marked failed, the steps list is empty, and the whole thing is over in one to three seconds.

That is the signature.

Failed conclusion, zero steps executed, near-instant finish.

When you see that shape three runs in a row, stop reading your code.

The dispatcher rejected the job before a runner ever picked it up.

You are not looking at a broken build. You are looking at a closed gate.

Why private repos are the ones that bite

Public repositories get unlimited Actions minutes.

Private ones get a free monthly allowance, and the meter is invisible until it hits zero.

There is no warning step. No yellow. No banner telling you that five percent is left while you still have a window to act.

The minutes drain quietly across every push, every scheduled job, every auto-sync hook you wired up to feel productive.

The more automation you bolt onto a private repo, the faster you walk into the wall.

And the wall does not announce itself. It starts answering every push with a two-second red.

The one question that ends the loop

Before you touch the diff, ask one thing.

Did the run actually run.

Open the latest red run and look at whether any step executed.

If steps ran and one failed, it is your code. Read the log.

If no steps ran and it died in seconds, it is the gate. Close the editor.

That single check turns a half-day of phantom debugging into a ten-second diagnosis.

I now run it before I read a single line of my own changes, because my reflex to blame my code is wrong often enough to be dangerous.

What you actually do about it

You have three honest moves, and none of them is push again.

Flip the repo public if the code can be public. Unlimited minutes, problem gone.
Wait for the monthly reset if the work can wait. The meter refills on its own.
Pay for more minutes if it is real production and neither of those fits.

What you do not do is keep firing commits at a closed gate.

Every fix you push while out of minutes is another two-second red that teaches you nothing and convinces you a little harder that your code is haunted.

The green log lies more than the red one

Here is the uncomfortable part.

For two days my checks were green, and I trusted them.

But the green was running on borrowed minutes that were about to run out.

A passing check told me my pipeline was healthy.

What it actually told me was that the meter still had room.

The status icon measures whether the job was allowed to run, not whether your project is sound.

Most of us read a green check as proof of correctness.

It is closer to proof of permission.

The day those two diverge is the day you lose an afternoon to a failure that was never in your code.

Your turn

Go look at your last failed CI run on a private repo.

Did the steps execute, or did it die in two seconds with an empty body.

If you have ever pushed a fix at a run that was never going to run, tell me how long it took you to notice.

For me it was twenty minutes and three commits, and I build CI guardrails for a living.