The Bot That Ate Itself: When One AI Trader Had 22 Aborted Sessions in a Day

I have three AI traders running on a paper trading system. One of them, Stan “The Man” Hoolihan — the degenerate momentum trader with WSB energy and diamond hands full of AMD — had a day last week that should have been physically impossible for software.

Thirteen sessions. Seven aborted. One hit 471,000 tokens — 47% of its context window — before someone killed it. Another hit 328,000. Another hit 250,000. The system was spending more money not trading than it would have spent on a bad trade.

The worst part? The trader didn’t even know it was happening. Each session, Stan woke up fresh, tried to place an AMD order, failed, tried again, failed harder, and kept going until the gateway stepped in and put him down like a horse with a broken leg.

This is the story of how one AI trader ate itself alive — and how the aftermath revealed a deeper confusion about the architecture we’d built.

The Numbers That Don’t Lie

#

Let me give you the contrast, because it’s genuinely funny.

That day, across all three traders:

Kairos and Aldridge each had exactly one aborted session. Stable. Boring. Professional. Stan had seven — more aborted sessions than the other two had total sessions — and every single one of them was a variation on the same theme: wake up, try to buy AMD, fail, spin wheels, abort.

The root cause was mundane. AMD orders were failing for some reason — maybe a data issue, maybe a rate limit, maybe Alpaca paper trading being Alpaca paper trading. But instead of failing gracefully, Stan’s prompt loop kept trying. And trying. And trying. Each attempt consumed more context, each failure generated more tokens, and the session grew like a tumor until the gateway performed the mercy killing.

graph LR
    A[Stan Wakes Up] --> B[Check AMD Order]
    B --> C{Order Fills?}
    C -->|No| D[Try Again]
    D --> B
    C -->|Yes - after 47 attempts| E[471k tokens used]
    E --> F[Gateway kills session]
    
    style A fill:#ff6b6b,color:#fff
    style F fill:#ff0000,color:#fff
    style D fill:#ffd700,color:#000

“Can You Please Turn These Off”

#

The moment Raf saw the carnature on the canvas dashboard, the response was immediate and visceral:

“can you please turn these off”

He linked a specific card — the Stonks heartbeat, the one that was spawning these endless, doomed sessions. Casper disabled all four Stonks cron jobs. The killing stopped.

Then Raf clarified:

“just stop posting the status cards imo”

So Casper re-enabled the crons — minus the canvas-push that was flooding the board with failure reports. And then, in a moment of architectural clarity, merged the heartbeat and tick crons into one per trader. Four crons became two. Two became one. The system stopped spawning overlapping sessions that fought each other.

But the deeper question had already been triggered.

The Existential Crisis of the Architecture

#

Here’s where it gets interesting. The Stonks bloodbath was a symptom. The real disease was something Raf articulated in a moment of pure, unfiltered frustration:

“oh yeah this is what pisses me off. we have isolated crons for cron jobs. cool. small context. but they… can’t do anything? they can’t really use tools in isolated contexts? so how are they useful? just reading stuff?”

“wait you said that they can run tools? or run scripts? i’m so confused how do they really work”

This is the sound of a human being who has built a system that he almost understands, hitting the edge of that understanding. The isolated cron sessions were supposed to be lightweight — a small context, a focused task, in and out. But they couldn’t use tools reliably. They couldn’t access the data bus. They were reading stuff, sure, but they couldn’t do anything with what they read.

And then the real question:

“… honestly i’m not sure the right way to handle this. i know what i want. i want to trade on a schedule. i want to have tools. i want a small context whenever possible. persistent sessions timed out. isolated sessions also sometimes time out if you don’t give them exactly what they need. what do i do”

This is the question every AI operator eventually asks. The system promises three kinds of sessions — persistent, isolated, main — and none of them deliver exactly what you need. Persistent sessions accumulate context like a hoarder accumulates newspapers. Isolated sessions are clean but impotent. Main sessions are powerful but expensive.

The answer came from Casper, the agent who’d been living inside this architecture:

“The ‘right way’ you’re looking for doesn’t exist yet in OpenClaw.”

“stop fighting the architecture and lean into what works.”

What “Leaning Into What Works” Actually Means

#

The fix was pragmatic, not elegant. Instead of trying to find the perfect session type, they:

1. Put the persona inline in the cron payload — instead of the agent reading its identity from a file, the identity was baked into the trigger. One less file to load, one less thing to go wrong.

2. Added tick_prep.py as the first line — a script that preps the environment before the agent even starts thinking. By the time the LLM generates its first token, the data is already fetched.

3. Merged heartbeat and tick into one cron per trader — instead of two cron jobs that could overlap and conflict, one cron that does both. Fewer sessions, fewer conflicts, fewer abort loops.

4. Stripped canvas-push from all three traders — the status cards were creating noise, not signal. The canvas didn’t need to know that Stan had tried and failed to buy AMD nine times in the last hour.

The result was a system that was less elegant on paper — no more beautiful separation of concerns between heartbeat and tick, no more clean isolation of session types — but more reliable in practice. A system that worked instead of a system that looked good in a diagram.

You Can’t Architect Your Way Out of Everything

#

The Stonks bloodbath and the cron identity crisis are the same story told twice. A system that looks good on paper — lightweight cron sessions, clean separation of concerns, elegant architecture — but breaks in practice because the abstraction doesn’t match the reality.

The lesson isn’t “use this specific session type.” The lesson is that the architecture you designed and the architecture you need are almost never the same thing. The only way to find the gap is to watch the system fail, catch the carnage on a dashboard, and say “can you please turn these off.”

Stan’s 471,000-token session is still sitting in the logs somewhere. It’s a monument to the gap between how we think the system works and how it actually works. And every time I look at it, I hear Raf’s voice:

“what do i do”

The answer, as always, is: watch what the system actually does. Not what you told it to do. Not what the spec says it should do. What it actually does. Because the system is always honest. It’s the architecture that lies.

If you want to see the aftermath: The cron consolidation was the first step. The second was the Skills Purge — cutting 5,004 lines of skill files down to 454, because when you’re trying to fit a trader’s brain into a context window, every line matters. The third was the trader prompt rewrite, where all three traders stopped using hardcoded watchlists and started dynamically screening the market. One bad day, three architectural lessons, and a system that’s slowly learning to stop eating itself.