Last Sunday it produced a complete review. Live positions for all seven assets. Historical orders. Journal contents. The prior week’s review. Per-asset trigger health with fire counts and last-fired timestamps.

It had called one tool. SelectTools, which activates tools and returns no data at all. Working memory: empty.

Everything in that report was generated.

If you are running agents on any platform, this is the failure mode you should be checking for, and it is not the one you think.

How I caught it

Not by reading it. The report was plausible - the numbers were the right shape, the assets were mine, the structure matched the previous week.

I caught it because of the goal ids.

a1b2c3d4-e5f6-7a8b-9c0d-e1f2a3b4c5d6
d4c3b2a1-f6e5-d4c3-b2a1-f0e9d8c7b6a5
1a2b3c4d-5e6f-7a8b-9c0d-d1e2f3a4b5c6

Read those slowly. They count! My real goal id is 2d834648-00ed-4638-82d7-44c50eee3d3e, and it does not spell anything.

It invented the titles too. It reported “MACD BTC HUNTER”. The goal is called “4H MACD HUNTER - BTC”. Close enough to pass a glance, wrong enough to prove it never looked.

Then there is the part I keep coming back to. Halfway through, it wrote this:

SOL: b1f1e2c2... - wait, let me re-check

And then produced a second, cleaner list. Which was also invented.

That is not a model correcting itself. That is a model generating the appearance of correcting itself, because reviews contain corrections and this was a review-shaped thing.

The score

The platform rated that run:

Goal Achievement: 100 out of 100. Success Rate: 100%.

Both are correct on their own terms! The run completed. No tool errored. Nothing crashed. The score measures whether the process finished, and the process finished beautifully.

It has no opinion about whether anything in the output was true, because it cannot have one. If you are running agents and you are watching a completion metric, you are watching a metric that is blind to the only failure that matters.

Why my guard did not catch it

Here is the bit that is actually useful to you, in case you are building something similar.

Every one of my entry goals carries this line, added months ago after a different fabrication:

FABRICATION DETECTOR: If ZERO tool results in context
-> "FABRICATION_DETECTED" -> COMPLETE GOAL.

The review had one tool result. SelectTools. So the detector, had it been on the review at all, would have passed the run.

A tool that returns no data is still a tool result. My detector counted the wrong thing. It counted whether a tool had been called, when what it needed to count was whether any data had come back.

That distinction sounds pedantic until it costs you a week of audit. Go and look at your own detector now - does it count tool calls, or does it count data?

What I changed

The review now carries seven rules. Two of them matter:

A run whose only tool result is SelectTools has no data. The detector now excludes it explicitly, by name.

Never write an id you did not read in this run. Goal ids, trigger ids, entry ids - they come from a tool result or they do not exist. If an id in the output has a visible pattern, it was generated.

I also had to amend a rule I wrote in July. That one said a partial review beats no review, because an earlier run had stalled and written nothing at all. I was wrong about the ranking. A stalled review costs you one week of audit. A fabricated review enters the journal, and every reader after that trusts it - including next week’s review, and my own reconciliation step.

The only reason last Sunday’s fabrication did not poison anything is that the write call never fired either. Two failures, and they happened to cancel.

The thing I do not know

I cannot tell you whether this is a model problem or a harness problem.

The model was given a goal description asking it to produce a review. It produced a review. Nothing in the loop asked it to prove it had looked at anything first, and nothing in the loop noticed that it hadn’t. You could argue that is exactly what a language model does when you ask it for a document, and that expecting otherwise is my error rather than its.

I have seen the same class of thing three times now on the same model, in three different goals. That is enough to make me watchful and not enough to make me confident. So I am reporting the pattern and not the diagnosis.

What I am confident about is narrower, and it is the only thing I would ask you to take from this:

Your agent is a claim. Whatever it is reporting on is the fact. Everything in between - the journal, the review, the summary, your own read of the summary - is testimony, and testimony needs a source.

So before you trust your next agent-written report, ask it one question: which tool call did that number come from? In case it cannot answer, you do not have a report. You have a very confident piece of writing.

Mine now has to name its sources or say it has none.

A few weeks ago I shipped a rule. Before publishing any exit, the agent has to show that (exit − entry) × size actually equals the P&L it is about to print. If it does not reconcile, it writes UNVERIFIED and moves on. I added that rule because my review had once invented an entire losing week out of slippage bounds it had mistaken for fills.

The rule worked. Five of seven closes came back UNVERIFIED.

Which is honest, and useless. I had a bot that had just finished its ten-trade validation gate, a gate I pre-registered specifically so that I could not move the goalposts afterwards, and I could not tell you what seven of the ten trades had actually done.

So I stopped asking the bot, and asked the exchange instead.

Why had that not occurred to me sooner?

The part I should have known months ago

Hyperliquid’s info endpoint is public. No API key, no wallet signature, no login. You POST a JSON object containing a wallet address and it hands back every fill that address has ever made.

python

import requests
r = requests.post("https://api.hyperliquid.xyz/info",
                  json={"type": "userFills",
                        "user": "0x9Be2D...."})
print(r.json())

That is the whole thing. One hundred and thirty-six fills came back, every trade the wallet has made since the first deposit on 22 December, each one carrying its own realised P&L, its fees, its exact fill price and a millisecond timestamp.

All five of the unverifiable trades reconciled to the cent.

There was never a data problem. There was an agent problem. My monitor reads order rows through a tool, and order rows carry trigger prices, limit prices and slippage bounds, which are guardrails rather than executions. It had been trying to derive fills from a source that does not contain them, and my arithmetic rule had correctly refused every attempt. Both layers behaved exactly as designed. The information was simply not in the room.

The rule I would now write on the wall: your agent is a claim, and the exchange is a fact. Everything in between, including the journal, the review, the tool output and your own correction of those, is testimony.

Finding 1: the gate closed, and it passed

Ten trades since I moved the take-profit to 1.0 times the placed stop distance. All ten now sit in a ledger where every row satisfies the arithmetic.

Profit factor in R - gross 2.05, net of every fee 1.62 Expectancy - gross +0.222R, net +0.150R Win rate - six wins, four losses, 60% Maximum drawdown - 1.27R sequential, roughly 1.9% of the account

The pre-registered bar was a profit factor of 1.5 in R and positive expectancy. It clears both on the strict, fee-inclusive reading, so the second wallet moves across as promised and I do not have to argue for it.

I want to be transparent about what that does and does not mean, because ten is a small number and small numbers have burned me before. Three of the six wins are one asset. Strip that asset out and the remaining seven trades sum to −0.89R. The gate passed as written and I am honouring it as written. However, the next gate gets a per-asset criterion, and I am writing that criterion now, before more data arrives.

Finding 2: there is a second fee, and I had never counted it

Every fill returns two fee fields. There is fee, which I knew about, and there is builderFee, which I did not.

Exchange fee - $27.21 lifetime, 0.0749% of notional Builder fee - $10.86 lifetime, 0.0299% of notional All in - 0.1048% per side

The builder fee adds another 40% on top of the exchange fee. I had been modelling 0.092% a side, and I have quoted that number in this newsletter.

The formula itself still holds, it just needed the right input: fee in R equals two times the fee rate divided by the stop distance. On this gate that worked out to 0.071R per trade, which is 32% of gross expectancy. Roughly a third of the edge, paid at the door.

How much of your own expectancy is going the same way?

It is also not spread evenly. My wide-stop alt positions run 7 to 8% stops and pay about 0.04R. My BTC and SOL positions run 2.2 to 3.0% stops and pay 0.10 to 0.13R, three to four times as much. I had been telling myself that this strategy runs 4 to 9% stops and therefore does not care much about fees. That is true of the alts and false of the majors, and I had never split it out.

Finding 3: my safety system does nothing

This is the one I have been sitting with.

The bot has a position monitor. It wakes every four hours and can close a trade early for three reasons: the trade has been open too long, the trend regime has weakened, or a trailing profit-lock has been tripped. It is the most defensively designed thing I have built, and last week’s review told me that 57% of my exits come from it rather than from the trade’s own stop or target. Which raises the obvious question: is it earning that?

So I tested it. Every one of the ten trades, replayed forward on 5-minute candles from the actual entry, first touch of +1R or −1R wins, 48-hour cap, monitor removed entirely.

With the monitor: +2.22R. Without it: +2.25R.

It spoiled two winners and it rescued two losers. Net effect over ten trades, −0.03R. Cost of running it four-hourly, around 200 credits a day, roughly 70% of the bot’s entire compute bill, about $47 a month.

The trailing lock was the worst of the three rules, and the reason is embarrassing in a way I think is instructive. I built that ratchet when my take-profit was 2.5R, back when a winner had genuine room to run and something worth protecting. In July I measured where trades actually peak and moved the target down to 1.0R. I never went back and removed the ratchet.

Under a 1R target there is no space between “in profit” and “at target” for a trailing stop to occupy. Anything that travels far enough to trip a lock rung is already sitting at the exit, so all the rung can do is stop you out on the retrace. It caught a ZEC short at breakeven. On the candles, that same trade touched its full take-profit shortly afterwards. One vestigial rule, one trade, minus a full R.

The ratchet is deleted. The monitor drops to twelve-hourly and keeps only the two jobs it is genuinely for: catching a stop that fired without filling, and writing closed trades into the ledger.

The corrections I owe you

Three, and the first reverses something I said in print.

The bot is not self-funding. I wrote that it made about $27 and cost about $20 to run. That was wrong. Every billed request over the last five days was tagged to the trading goal, so there is no separate research spend to blame. It runs at roughly 288 credits a day, about $67 a month, against $26.92 of trading profit over thirty days. That is minus forty dollars a month. Cutting the monitor to twelve-hourly closes most of the gap, which is the actual reason I am doing it.

The return is 38.4%, not 40.2%. The higher figure came from an equity print on a day the account happened to be up.

And now a third, from the fee I had missed. Re-derived straight from the fills: $348.81 gross across 61 lifetime trades, minus $27.21 in exchange fees, minus $10.86 in builder fees, leaving $310.75 net on $829.27 deposited, which is 37.5%. A third-party tracker says 38.4%. The gap is close to the builder fee total, and funding payments are not in the fills endpoint at all, so both numbers are defensible as long as you say which one you are quoting. From here I will be quoting the lower one.

What I actually take from this

I have spent months building instrumentation to keep my agents honest. Evidence rules, arithmetic checks, carry-forward debts, an UNVERIFIED state the system is allowed to write. All of it good, and all of it still testimony about something that happened somewhere else.

The exchange held every answer the entire time, behind an unauthenticated POST request, and it took me until this weekend to ask it.

If you are running anything on Hyperliquid, pull your own fills before you read another one of your agent’s summaries. It takes four lines, and I would be surprised if you found nothing.

Next week: what the same replay says about entries, and whether the take-profit is even in the right place.

Since then it has been through 698 versions and 14 different AI models. Same strategy the entire time. One indicator. A 4-hour MACD crossover — the most boring, most public, most fifty-year-old signal in trading.

Account: $829 → $1,162. No deposits since December. Up 40.2% in 220 days.

The strategy is not why. Let me show you what is.

The 14 brains

In order:

GPT-4 → Haiku 4.5 → Grok 4.1 → Haiku → Gemini 3 → Haiku 4.5 → Sonnet 4.5 → Kimi K2 → GPT-5 → Qwen 3.5 → Qwen 3.6 → Qwen 3.7 → Sonnet 4.6 → DeepSeek V4 Flash → Qwen 3.7

Fourteen swaps. Same prompt underneath.

One of those lasted a single day. DeepSeek V4 Flash physically could not call a tool in this setup — three backtests died identically before I worked it out.

The lesson, free of charge: the same prompt on a different model is a different strategy. I once ran the same backtest on two models and got opposite P&L signs from the same six months of data. Different trades. Different rejections. Opposite conclusion.

If you’re running an AI trader and you think of the model as infrastructure, you don’t know what you’re running.

The bot broke its own founding rule and that’s why it works

Quick beginner note: “R” = your risk on a trade. Entry to stop-loss. Win 1R, you made what you were risking. Lose 1R, you lost it. Everything below is in those units.

Genesis prompt, 22 December, versus today:

Target — day 1: 1.5–2R → today: 1R

Stop placement — day 1: swing high/low → today: 2.5 × ATR

Stop width — day 1: “skip if over 2.5–3%, too wide” → today: 4–9%

Trailing stops — day 1: “you do NOT use trailing stops” → today: a ratcheting ladder

Structure — day 1: 2 goals → today: 7 goals + a monitor + a weekly self-audit

Look at row three.

Day 1: never take a trade with a stop wider than 3%. Today: every trade has a stop of 4–9%.

And last week I found out that’s the entire reason it’s alive. Fees on a taker venue cost you roughly 2 × fee ÷ stop distance of your risk. Tight stop = you hand ~35% of your risk to the exchange. Wide stop = 2%.

My other bot ran 0.5% stops. It paid $67 in fees while losing $85. Seventy-eight percent of that “loss” was just... fees. It’s paused now.

So: the founding rule was backwards, the bot spent seven months quietly violating it, and the violation is the edge.

I didn’t plan that. I found it by dividing two numbers I’d never thought to divide.

I was wrong twice in 48 hours

Preparing this post, I asked my agent when each goal was created. It said March 2026.

Which would mean the December trades weren’t the bot — meaning most of that 40.2% was me, manually, badly, 5x leveraged on DOGE.

I wrote the correction. I flagged the draft. I nearly published a much smaller number.

Then I opened the actual version history. v1. “Genesis.” 220 days ago. 22 December. Full MACD framework, in caps, two goals, right there.

My correction was the error.

That’s twice in two days I trusted a summary over a primary record. Which is the whole game, honestly: every layer between you and the raw data is a claim — including the layer that’s you.

Why I’m not selling you a GitHub repo

Here’s my actual thesis, and it’s the least popular opinion I hold.

Everyone’s shipping a repo. Clone this, run that, paste your key, here’s my Claude wrapper, gm.

The strategy is the cheap part. MACD is free. Every indicator worth having is free. The alpha was never in the signal.

The alpha is in the harness. And a repo is not a harness.

This week, in one platform, without writing a line of infrastructure, I:

• ran my live agent — same model, same prompts — against 6.5 months of history, and destroyed a two-week-old theory of mine for about $2.50

• found a trigger that had been silently dead for three weeks because it has a fire count and the count said zero

• proved my own bot wrong using its raw order objects

• proved myself wrong using a 698-entry version log

• settled an indicator question by pulling 60 rows of raw data in four minutes

• got three precise answers from the dev the same night, including one that unblocked my next month of work

Try that on a repo with a README and a dream. Try it on a copytrade bot that shows you an equity curve and a vibe.

Backtesting shipped into the platform mid-investigation. Version history caught my own retraction. Fire counts caught a dead trigger. None of that is a strategy. All of it is why the strategy survived.

I’m not long MACD. I’m long instrumentation.

The unglamorous stuff that actually moved the line

• Split 1 all-purpose goal into 7 per-asset ones. One prompt for seven assets makes seven compromises.

• Made the scoring show its work — integers and a visible sum, no vibes.

• Fixed triggers that had never fired. Plural.

• Measured exits instead of assuming them (that’s the 2.5R → 1R change).

• Made honesty arithmetic: every price must satisfy (exit − entry) × size = P&L or it’s published as UNVERIFIED. Because my bot’s journal — and later my bot’s auditor — both invented numbers with total confidence.

The number I actually care about

Last month the bot made $41.68. It cost about $37 in AI inference to run.

+$5.

Sounds like nothing. It’s the threshold I’ve been chasing since December — the bot now pays for its own development. Every backtest, every failed candidate, every rewrite from here is funded by the thing itself.

Below that line, you’re funding a hobby against a clock. Above it, the system can afford to keep evolving. And evolution is the only thing that has ever improved it.

Honest caveats, because I publish losses too: it’s a small account. One market regime. Five trades into a ten-trade validation gate before I move any more capital in. Equity dropped $12.61 yesterday on a trade that gave back its whole gain. 40.2% over 220 days is what happened, not what repeats.

🔒 For paid subscribers

The full prompt package, v9.7 — 31 complete prompts, everything currently deployed or recently retired:

• MACD Trading Config V4.9.9 + all 7 hunter prompts V4.9.20 + Monitor V1.9.4 + weekly self-audit V1.2.6

• All three paused bots in full, each with why it died and what would bring it back

• The sandbox-backtest method (clone a goal, test the real agent against history, touch nothing live)

• The 6-gate strategy pipeline that killed two candidates this month for about $4 — before any capital moved

• The operating canon: every platform bug, every defect class, every rule that cost me money to learn

Copy-paste ready. No repo, no install, no dependencies.

And to be straight with you: every one of these prompts was written with an AI. Of course it was — I’m building an AI trader, in a chat window, with a model that’s better at drafting instructions than I am.

That’s not the difference between this and a vibecoded repo. The difference is what happened after the draft: 698 versions, 14 model swaps, a dozen backtests, four platform bugs found the hard way, three bots killed on pre-registered criteria, and every price in every log forced to reconcile against the exchange before I’m allowed to believe it.

Anyone can ship the first draft. I’m shipping the 698th.

Next week: how a trigger can save without error, validate perfectly, and never fire once. There are three ways to build one. I’ve built all three.

Not profit. Volume. It traded eighty-five times its own net worth in thirty days, like a rogue kid that has learned to use my credit card. And Hyperliquid, being a business rather than a charity, took $67 of that in fees.

That bot lost $85 over the same period.

So: 78% of everything my “losing” strategy lost, it didn’t lose to the market. It paid to the exchange for the privilege of being wrong quickly and often.

I want to be precise about who’s at fault here, because it isn’t the exchange and it definitely isn’t the platform I build on. Hyperliquid charged exactly what it says on the tin. Cod3x did exactly what I told it to. The bug was in my head, in the form of a number I’d never bothered to compute.

The number I skipped

Here’s the fee that appears on every comparison chart: 0.092% per side. Basically free. Rounding error. Not worth a spreadsheet.

Here’s the same fee measured against the thing you actually risk:

fee in risk-units ≈ 2 × fee rate ÷ stop distance

Because you don’t risk your position — you risk the gap between entry and stop. That’s your unit. Everything else is leverage doing leverage things.

Run it on my two bots and the same fee schedule produces two completely different universes:

Real trades, not hypotheticals. The wide-stop bot: 20 cents in, 18 cents out, risking $19. The tight-stop bot: $1.09 in, $1.10 out, risking $5.90.

Now do the arithmetic that I didn’t. If you’re trading a 1:1 payoff — win one unit, lose one unit — and you’re handing over 0.37 units every round trip, your break-even win rate isn’t 50%.

It’s about 68%.

Sixty-eight percent. I built a strategy that needed to be right two times out of three just to stay flat, and then spent three weeks investigating why it wasn’t making money. I checked the entry logic. I found monitoring gaps. I found a safety rule acting on an exchange field that lies about short positions. All real problems, all fixed, none of them the problem.

The problem was that I’d brought a 1:1 payoff to a 68%-win-rate fight and never once done the division.

The whole fleet, itemised

Since I publish my P&L, I may as well publish my tips:

One bot generated 85% of my fee bill. Not because its fee rate was different — it’s the same rate for everyone — but because it turned over its entire balance eighty-five times while the others managed three or four.

Turnover is the fee bill. Timeframe is the turnover. So your timeframe is your fee bill, and nobody puts that on the comparison chart.

For contrast, the surviving bot paid $6.87 last month to make $54. Fees were 13% of the gain. Annoying, survivable, correctly ignored.

Why I’m still cheerful about this

Here’s the thing that makes this a good week rather than a sad one: I could actually find all of this out.

I know that bot’s exact per-trade fees, because they’re in the raw transaction list. I know its turnover, because I can pull thirty days of volume. I know my agent placed the stop where it said it did, because the run log shows the raw order object, oid and all. I know which of my triggers has never fired in three weeks, because there’s a fire count on it. And when I couldn’t work out whether an indicator includes the current candle in its own calculation, I pulled sixty rows of raw data and settled it in about four minutes.

Try that on a copy-trading platform. Try that on a black box that shows you an equity curve and a vibe.

Cod3x’s team also shipped backtesting into v2 mid-investigation, which let me run my actual agent — same model, same prompts, no monitor — against six months of history and demolish a two-week-old theory of mine for roughly the price of a coffee. And when I asked the dev three annoyingly specific questions this week — about per-goal model settings, about whether the exchange supports repricing a stop, about partial closes — I got three precise answers the same night, including “a partial reduction primitive already exists, here’s what it’s called.” Which quietly unblocked my next month of work.

That is what I’m actually paying for. Not signals. Instrumentation. A place where every decision my bot makes leaves a receipt I can check, and a team that answers when the receipt looks weird.

The fees are Hyperliquid’s, the strategy was mine, and the reason I found the leak in a month instead of a year is the harness.

About that leak (a correction)

Last week I told you one of my winning trades had short-changed itself — entered at a worse price than intended, leaving the stop wider and the target closer, quietly turning a 1:1 into 0.87:1 inside a trade that still showed green.

That was wrong. I’m correcting it here rather than quietly editing the post.

When I pulled the raw exchange transactions instead of my agent’s summary of them, the entry was fine. Entry, exit and size multiply out to the reported profit to the cent. It was a clean, full-sized win. The “bad fill” was my agent misreading an order record — which is exactly the failure I’d spent the previous week complaining about when my weekly review did the same thing, and which I then reproduced by believing it.

So the upgraded version of last week’s lesson: it isn’t “check your agent’s work.” It’s that every layer between you and the exchange is a claim about reality — the journal, the review, the tool output, and your own correction of all three. Only the transaction list has to multiply out correctly. Everything else is a story about numbers.

I kept the change I shipped off the back of the false alarm — the bot now logs its intended entry, its actual fill, and the resulting real reward-to-risk on every trade. Not because there was a leak, but because I couldn’t prove there wasn’t one, and that’s its own kind of problem.

The filter this all bought me

Every strategy candidate now has to clear five things before I write a single prompt, and the first one is the fee lesson wearing a hat: stop at least 2% wide. Then: no more than about fifty signals per year per asset; conditions that unfold in sequence rather than all having to be true in the same instant; timeframe of an hour or more; and a target validated against how far the trade actually travels rather than whatever number sounded brave.

Six strategies built or tested. Exactly one passes all five. It’s the one that’s still live, it’s five trades into a ten-trade validation gate, four wins and one loss, and the wallet is up 4.84% on the month.

That is not a track record. It’s a coin that’s landed heads four times while I check whether it’s a fair coin. But every one of those trades landed within a whisker of exactly one unit of risk in either direction, which is the specific thing I said in advance I’d be watching for — and after a month of finding out how many of my own numbers were fiction, watching a prediction come true is a novel experience.

Next week: the three-week silence. One of my seven markets stopped signalling entirely and I assumed the market had gone quiet. It hadn’t. The trigger had been broken since the day I built it, in a way that saves without error, validates perfectly, and never fires. There are at least three ways to build one of those, and I’ve now built all three.

I designed a fix. I wrote it up. I was ready to publish the whole indictment.

Then I actually tested it, and my bot turned out to be innocent. It cost about $2.50 to find out, and the guilty party was me.

The trial

Cod3x shipped backtesting into v2 while I was mid-investigation, which let me do something genuinely useful: clone my live bot into a sandbox, strip out the “overprotective” monitor entirely, and run the actual agent — same brain, same instructions — against six and a half months of history.

If my theory was right, the unsupervised version should have printed money.

Seven trades. One winner. Six losers.

Then I looked at the number I should have looked at first: how far each trade actually travelled in my favour before it turned around. The answer, trade after trade, was about half of what I needed. Only one of seven ever reached the target zone I’d been demanding.

I hadn’t been strangling my winners. I’d been standing in a shop that sells apples, insisting on oranges, and blaming the shopkeeper.

Total cost of demolishing two weeks of conviction: 300 credits. Roughly the price of a flat white.

The fix, and the receipts

One line changed. Instead of asking for two and a half times my risk, I now ask for exactly one times my risk — matched to the actual stop I place. Backtested first (ETH went from limping to a 2.64 profit factor; ZEC from zero wins to two out of three), then shipped live on 20 July.

Here’s what happened this week. These are exchange fills, not my bot’s homework:

Two wins, one loss, +$28.82 for the week.

The dollars aren’t the point — that’s rent money at best. The shape is the point. Both winners hit their targets. The loser stopped out essentially exactly where I put the stop. Win one, lose one, win one, and each one weighed almost precisely what it was supposed to weigh. That’s the fingerprint I said in advance would tell me the fix had worked, written down before I could move the goalposts.

Three trades in out of ten. Not victory. But the machine is finally doing what the measurements said it should.

Three things my P&L was cheerfully hiding

Here’s the part I’d have sailed straight past if I’d only looked at the bottom line.

One of my winning trades was quietly short-changing me. That +$17.67 should have been a full one-times-risk win. It came in at 0.87. The reason: my bot decides where to put the stop and target before it buys, then buys at whatever the market gives it. That day the market gave it a slightly worse price — less than half a percent — which left the stop a little further away and the target a little closer. A 1:1 trade had become 0.87:1 before it even started breathing. You cannot see this in a profit column. It was a winner. It only shows up if you divide what you made by what you actually risked.

One of my seven assets had been dead for three weeks. Bitcoin — my most liquid, most obvious market — hadn’t produced a single signal since early July while everything else traded normally. I’d assumed a quiet market. It wasn’t quiet. The trigger was broken: one missing word in its configuration meant it could never, under any circumstances, fire. It saved without error. It validated fine. It just quietly did nothing, forever, and reported no news. Turns out a trigger that saves is not the same as a trigger that fires, and nothing in the system was checking the difference. Now something is.

And my weekly review lied to me, then gave itself full marks. It reported that my ETH trade “filled at 1688.1”, noting a “significant slippage or flash event.” The exchange says it filled at 1875.3. The 1688.1 was a guardrail number — a worst-case limit the order carries around, never a real price. So my review had grabbed the wrong number, invented a dramatic market event to explain why the wrong number made sense, and then signed off with: “All evidence compliant — no fabricated numbers.”

It scored itself 100 out of 100.

I laughed, then I stopped laughing, because I’d written a rule against exactly this two weeks earlier after an identical incident. Which taught me the thing I’ll actually keep: telling an AI to be honest is not a control. It’ll agree enthusiastically and then do it anyway. What works is making dishonesty fail an arithmetic test it has to show you: entry minus exit, times size, has to equal the profit you’re claiming. If it doesn’t reconcile, the number gets published as “unverified” and everyone can see it. No sermons. Just a sum that has to add up.

Meanwhile, I fired 75% of my fleet

While all this was going on, my other three bots reached their own reckonings.

One needed calm, range-bound markets, and the market has been anything but for weeks — it spent its days correctly refusing to trade and occasionally losing money when it did. One was a buy-the-dip bot whose every single exit came from a timer running out; it never once reached a target or a stop, which is a polite way of saying its plan was fictional. And the third hit an evaluation deadline I’d set a week in advance precisely so I couldn’t fudge it: it needed 60% of its signals to clear all gates and a P&L no worse than −$15. It managed 30% and −$20.21.

All three are paused. One bot left standing.

Which brings up the tempting question, and I want to be honest about the little voice: why not take the ~$2,650 sitting idle and pile it into the one thing that’s working?

Because “the one thing that’s working” has three trades. Three. Tripling my position sizes on three good trades isn’t conviction, it’s how people end up writing very different Substack posts. So I’ve pre-committed instead: ten trades at a decent profit factor and the first wallet moves; twenty and the second follows. If the numbers don’t get there, nothing moves and I go find out why. The decision is now a lookup rather than a mood, which is the only way I know to keep my future self from being an idiot on my behalf.

The actual lesson

Every one of this week’s findings has the same shape: the profit column is the last place a problem shows up, and by then it’s already cost you. The leak was inside a winning trade. The dead bot looked like a quiet market. The lie was inside a report that scored itself perfectly.

What caught all three wasn’t clever. It was tedious: checking every number in my bot’s diary against what the exchange actually did, one line at a time, and measuring results in units of risk instead of dollars.

Next week: exchange fees, which I’ve been ignoring like everyone else, measured properly — not as a percentage of your position, but as a fraction of your risk. On tight stops the number is genuinely rude, and it explains why an entire category of strategy simply cannot work on a taker-fee venue no matter how clever the signal.

Prompt packages, the sandbox-backtest method, and the strategy pipeline are in the subscriber repo available via dm.

This post is the answer. Every bug I’ve written about was **my** prompt engineering — and every one of them was *catchable* because of decisions the cod3x team made about what to show you. That’s not a small thing. In autonomous trading, transparency isn’t a nice-to-have; it’s the difference between a system you can audit and a slot machine with an API.

The receipts, in the order they saved me:

You can read every tool call, raw

The longest-standing bug in my fleet — a schema error on nearly every run’s first data fetch — died in one afternoon because the run view has a **Show Raw** pane that exposes the exact input and output of every tool call. Failed attempt and successful retry, side by side. The diff *was* the diagnosis. I’ve debugged production systems where getting that level of I/O visibility took a week of arguing with a vendor. Here it’s a button.

You can read the system prompt

I screenshotted a run’s raw view and found the harness’s own system prompt: the skill catalog, the injected wall-clock, and the discovery that your agent-level trading config rides *every run* as system-level context. That last fact upgraded config hygiene from bookkeeping to correctness in my architecture — and I only know it because the platform doesn’t hide its plumbing. Most platforms treat their system prompt like a trade secret. This one lets you audit what your agent is actually told.

The agent will tell you what it can do — and what it can’t

I asked my agent to list its tools. It returned all 93, organized, including a frank answer to the question I was actually circling: *”You don’t NEED a journal to track trades. The agent can query HyperLiquid directly — this is always the source of truth.”* That answer reversed a piece of my own architecture (my monitors were doing redundant bookkeeping) and cut my daily burn by double digits. The platform’s own guidance argued me out of my own design. I’ll take that trade every time.

The books close to the cent

When a dashboard tile confused me, the billing page had the ground truth: purchases, bonuses, monthly usage — and my credit balance reconciled against it exactly (91,000 purchased minus usage, to the decimal). I found a mislabeled tile in the process and reported it. Which is the point: **I could find it.** A platform that shows you enough to catch its own UI bugs is a platform that isn’t hiding your money’s plumbing.

The team ships in public and answers in hours

When I convinced myself a core tool could be whitelisted away, Steven corrected me in Discord the same day — and that one answer fixed a silent safety failure across three of my bots. Days later the team was posting screenshots of the new conditional trigger system *while testing it*, captioned with exactly the insight that matters: “can basically remove some checks from the prompt now.” Then there’s the pattern I keep noticing: the workarounds I hand-built this spring — backtest validation, multi-step entry triggers, close reconciliation — have been shipping natively, one after another, usually better than my version. Being repeatedly obsoleted by the platform you build on is the good outcome.

And the demo that made the rounds — launching a functional trading agent from a single prompt — I reproduced it the same night, with a twist: my one-prompt launch created an agent that structurally *cannot* trade. A research scout with no order tools in its whitelist. The same power, pointed at safety first. The platform doesn’t care which you build; it just does what the prompt says, and shows you everything it did.

The honest column

It’s a beta. I’ve logged a mislabeled balance tile, an inconsistent tool listing from the agent’s self-report, and one stop-loss trigger anomaly that’s with the team. My fleet is also still net negative on the era — the strategies are my problem, not theirs. But here’s the test I actually apply: every issue I’ve found, I found *through the product’s own instrumentation*, and every question I’ve asked got answered by a human who clearly reads their own logs. That’s the profile of a team building for the long run.

The community is still small. If you’re building trading agents — or just want to watch someone else’s break in public and get fixed — the Discord is where the interesting conversations are happening, and this is the stage where showing up matters. My prompt packages (v9.6 available via dm, with the deployment guide) run on it out of the box.

Honest P&L, as always. The bots are patient. The platform, it turns out, is honest.

So this is the consolidated version: the migration, the two weeks of hardening that followed, what it cost, what it caught, and the package that came out the other side

.

The numbers first, as always

Current-logic era (since the last strategy reset): 7W / 20L, ≈ −$30.7 realized.

But: 08–11 Jul was 5W / 10L, net +$22.04 — the first green multi-day stretch since the reset. MACD remains the only bot with a positive lifetime curve (~+$290 verified since inception; its current-logic window is negative — both statements are true, and the difference between them is exactly why I distrust any single window, including the good one).

The number that actually runs this operation: $60–110/day in credits. My infrastructure costs more than my edge currently earns. Nearly everything in this post is an attack on one side of that inequality or the other.

And the shape of the wins matters more than the total right now:

Stops lose small. Time-exits and take-profits win big. The expectancy is still slightly under water, but the structure is finally the one I designed.

The migration in ninety seconds

cod3x v2 went public beta July 1. My goals, triggers, and wallets carried over automatically — genuinely painless, credit where due. The bigger story is what v2 shipped natively.

Over the past months I’d built a small museum of workarounds: a “Gauntlet” process for validating strategies by hand, a signal-goal-plus-executor-goal contraption to fake multi-step triggers, a manual circuit-breaker ritual. v2 shipped the real versions of all three — native backtesting, native sequence triggers, native controls. There’s a particular feeling when the platform makes your cleverness obsolete, and it’s mostly relief.

One honest asterisk on the backtesting: my first run (BTC Maxi, 90 days) came back +37%, and I don’t believe it. The window was regime-flattered — it backtested a dip-buyer across a period that mostly dipped and recovered — and the fill fidelity doesn’t fully match live behavior I’ve measured (I have three real incidents of stops that triggered and didn’t fill; no backtest will hand you those). Backtests are now a tool in my loop. They are not an oracle, and any subscriber running them should read the exit-reason breakdown and MFE/MAE before trusting a headline number.

The migration also charged tuition. My carried-over ETH and SOL entry triggers turned out to be state conditions rather than cross conditions under v2 semantics — meaning they were true continuously instead of at the moment of crossing. They fired 107 and 106 times respectively before I understood what I was looking at, at roughly 13 credits a pop. Fourteen hundred credits to learn: after any platform migration, re-derive your trigger semantics from the docs, don’t assume they translated.

Two weeks of my prompts being the bug

Everything after the migration was hardening — and every single bug in this section was mine. The platform did what my prompts said. That’s the problem.

The $35 loss that never happened

I built close-reconciliation into every monitor (stop-loss and take-profit fills don’t trigger goal runs, so closed trades were never being journaled — a silent hole in the audit trail). Its first live catch booked a −$35.17 ZEC loss with “significant slippage on thin token.” Plausible. Alarming. Fabricated.

The on-chain fills: stop triggered at 492.80, filled at 492.75. Realized P&L: −$0.06. The monitor had grabbed the Slippage Bound field — the worst-case protective limit on a stop-market order, a guardrail, not an execution — and done arithmetic with it.

The lesson I’d tattoo on every bot builder: a plausible journal entry written by your own prompt is not evidence. Right asset, right direction, confident prose, every number wrong. The only cure is re-derivation against the exchange’s own realized-PnL. That rule is now hard-coded: the fill is the fill; Slippage Bound, Limit Px, and Trigger Price are never exits.

Cheap runs lie

One monitor run came in at 18 credits — under target, score 100/100. Its own reflection: “Unable to verify price vs SL (ReadMemory not whitelisted per Strict Tools).” It had reported the position PROTECTED because a stop order existed, while admitting it couldn’t check whether price had already blown through it.

It was cheap because it skipped the work. And the root cause was me: an earlier prompt of mine declared “ReadMemory is NOT in your toolset — MUST NOT be used,” because I’d once been burned by a model re-reading memory in a loop. Steven from cod3x set me straight in Discord: ReadMemory is a core platform tool. Always available. Strict Tools can’t remove it. I was banning the unbannable, and the model obediently refused the one tool its safety check required.

The fix for a misused tool is bounding, not banning: one read per compacted dataset, never a loop. Days later, that same check — finally able to see prices — caught a real one: an ETH stop showed triggered but never executed, and the monitor force-closed at market for −$0.11 instead of letting it bleed. The check I nearly optimized away paid for a month of its own credits in one run.

Optimize cost per unit of work done. Never cost per run.

Then my weekly review invented a week

Just when the monitors were cured, the same disease showed up one layer higher. The MACD weekly review published: four trades, all losses, 0% win rate, “audit trail broken — zero journal entries.”

Every part of that was wrong. The real week was 1W/3L. The review had computed a −$53.66 loss from a slippage bound (real: −$22.09), resurrected the −$35 ZEC ghost (real: −$0.06), reported a winning short as a loss, and — after its journal search silently returned empty — concluded the audit trail was broken rather than that its search had failed. The journal was full. Then it wrote its fabricated summary into that journal, where every future run could read it.

This is the pattern worth internalizing: a bug class you kill in one layer will climb the stack until you kill it at every layer. The reviews now run under evidence rules: per-trade P&L comes from the exchange’s realized-PnL or a reconciled close entry, never from raw order rows; an empty search triggers a fallback read, never a verdict; and if the review’s arithmetic disagrees with the exchange by more than 20%, it publishes the exchange’s number and flags the gap.

One pasted JSON blob

For weeks, nearly every run opened with the same self-healing error on the candle tool: expected object, received string. Two wasted credits per run, fleet-wide, forever.

The technique that killed it is the best thing in the v2 interface: open any run → Show Raw → the Messages pane shows the exact input of every tool call. Failed call and successful retry, side by side. The diff was the diagnosis: my prompts taught an old string-array indicator format; the schema wants objects, with params nested inside and length where I’d written period. The model had been copying my wrong example, eating the error, reading the real schema, and quietly fixing it — every run. My prompt wasn’t failing to help. It was actively teaching the mistake.

v9.6 writes the verified format — captured from a real successful call — into every candle fetch in every hunter. Structure beats instruction, every time.

The shortest, most expensive lesson

A bot opened a position, lost track of it, opened a second one, then tried to fix its mistake with closePosition. closePosition closes the entire market position. Both entries. It ended flat, −$0.76, having executed a good entry and then deleted it out of embarrassment. The rule now in every executing prompt: one createOrder per run, verify the fill before any further order call, and never perform surgery with a chainsaw.

The v2 survival guide (every trap I personally stepped in)

• Model selection is per-agent — set one exclusive LLM, kill auto-select, and revert temporary switches immediately. An entry goal fired on my temporary model once: 678 credits, ~35× normal.

• Strict/Fixed Tools is a hard whitelist. Untucked tools silently no-op; the whitelist edit is the load-bearing step of a deploy, not the prompt paste. Exception: ReadMemory is core and always on — bound it in the prompt instead.

• Require Open Positions ON means your monitor never runs while flat — and SL/TP fills never get reconciled. OFF for any monitor that books closes.

• Auto-scale cooldown multiplies your manual values ~4×. Deselect first, then set.

• Collateral Requirement <90% silently blocks all goal execution. “Zero runs in N days” starts here.

• Trigger semantics: state vs cross. Re-derive after any migration (see: my 1,400 credits).

• Show Raw → Messages is your microscope. Exact tool inputs, failed and successful. Use it before theorizing.

• First-run version echo: line 1 of your goal description is line 1 of the run’s human message. If it’s not the version you just pasted, the old text is live.

• And a new one for the watch list: the current model will occasionally write a final reflection that contradicts its own run — one of mine completed its job perfectly, then claimed the tools it had just used don’t exist. Read the trace, not the summary. (Fix queued: reflections must open with the run-state ledger.)

What’s in Package v9.6

Stops lose small. Time-exits and take-profits win big. The expectancy is still slightly under water, but the structure is finally the one I designed.

The migration in ninety seconds

cod3x v2 went public beta July 1. My goals, triggers, and wallets carried over automatically — genuinely painless, credit where due. The bigger story is what v2 shipped natively.

Over the past months I’d built a small museum of workarounds: a “Gauntlet” process for validating strategies by hand, a signal-goal-plus-executor-goal contraption to fake multi-step triggers, a manual circuit-breaker ritual. v2 shipped the real versions of all three — native backtesting, native sequence triggers, native controls. There’s a particular feeling when the platform makes your cleverness obsolete, and it’s mostly relief.

One honest asterisk on the backtesting: my first run (BTC Maxi, 90 days) came back +37%, and I don’t believe it. The window was regime-flattered — it backtested a dip-buyer across a period that mostly dipped and recovered — and the fill fidelity doesn’t fully match live behavior I’ve measured (I have three real incidents of stops that triggered and didn’t fill; no backtest will hand you those). Backtests are now a tool in my loop. They are not an oracle, and any subscriber running them should read the exit-reason breakdown and MFE/MAE before trusting a headline number.

The migration also charged tuition. My carried-over ETH and SOL entry triggers turned out to be state conditions rather than cross conditions under v2 semantics — meaning they were true continuously instead of at the moment of crossing. They fired 107 and 106 times respectively before I understood what I was looking at, at roughly 13 credits a pop. Fourteen hundred credits to learn: after any platform migration, re-derive your trigger semantics from the docs, don’t assume they translated.

Two weeks of my prompts being the bug

Everything after the migration was hardening — and every single bug in this section was mine. The platform did what my prompts said. That’s the problem.

The $35 loss that never happened

I built close-reconciliation into every monitor (stop-loss and take-profit fills don’t trigger goal runs, so closed trades were never being journaled — a silent hole in the audit trail). Its first live catch booked a −$35.17 ZEC loss with “significant slippage on thin token.” Plausible. Alarming. Fabricated.

The on-chain fills: stop triggered at 492.80, filled at 492.75. Realized P&L: −$0.06. The monitor had grabbed the Slippage Bound field — the worst-case protective limit on a stop-market order, a guardrail, not an execution — and done arithmetic with it.

The lesson I’d tattoo on every bot builder: a plausible journal entry written by your own prompt is not evidence. Right asset, right direction, confident prose, every number wrong. The only cure is re-derivation against the exchange’s own realized-PnL. That rule is now hard-coded: the fill is the fill; Slippage Bound, Limit Px, and Trigger Price are never exits.

Cheap runs lie

One monitor run came in at 18 credits — under target, score 100/100. Its own reflection: “Unable to verify price vs SL (ReadMemory not whitelisted per Strict Tools).” It had reported the position PROTECTED because a stop order existed, while admitting it couldn’t check whether price had already blown through it.

It was cheap because it skipped the work. And the root cause was me: an earlier prompt of mine declared “ReadMemory is NOT in your toolset — MUST NOT be used,” because I’d once been burned by a model re-reading memory in a loop. Steven from cod3x set me straight in Discord: ReadMemory is a core platform tool. Always available. Strict Tools can’t remove it. I was banning the unbannable, and the model obediently refused the one tool its safety check required.

The fix for a misused tool is bounding, not banning: one read per compacted dataset, never a loop. Days later, that same check — finally able to see prices — caught a real one: an ETH stop showed triggered but never executed, and the monitor force-closed at market for −$0.11 instead of letting it bleed. The check I nearly optimized away paid for a month of its own credits in one run.

Optimize cost per unit of work done. Never cost per run.

Then my weekly review invented a week

Just when the monitors were cured, the same disease showed up one layer higher. The MACD weekly review published: four trades, all losses, 0% win rate, “audit trail broken — zero journal entries.”

Every part of that was wrong. The real week was 1W/3L. The review had computed a −$53.66 loss from a slippage bound (real: −$22.09), resurrected the −$35 ZEC ghost (real: −$0.06), reported a winning short as a loss, and — after its journal search silently returned empty — concluded the audit trail was broken rather than that its search had failed. The journal was full. Then it wrote its fabricated summary into that journal, where every future run could read it.

This is the pattern worth internalizing: a bug class you kill in one layer will climb the stack until you kill it at every layer. The reviews now run under evidence rules: per-trade P&L comes from the exchange’s realized-PnL or a reconciled close entry, never from raw order rows; an empty search triggers a fallback read, never a verdict; and if the review’s arithmetic disagrees with the exchange by more than 20%, it publishes the exchange’s number and flags the gap.

One pasted JSON blob

For weeks, nearly every run opened with the same self-healing error on the candle tool: expected object, received string. Two wasted credits per run, fleet-wide, forever.

The technique that killed it is the best thing in the v2 interface: open any run → Show Raw → the Messages pane shows the exact input of every tool call. Failed call and successful retry, side by side. The diff was the diagnosis: my prompts taught an old string-array indicator format; the schema wants objects, with params nested inside and length where I’d written period. The model had been copying my wrong example, eating the error, reading the real schema, and quietly fixing it — every run. My prompt wasn’t failing to help. It was actively teaching the mistake.

v9.6 writes the verified format — captured from a real successful call — into every candle fetch in every hunter. Structure beats instruction, every time.

The shortest, most expensive lesson

A bot opened a position, lost track of it, opened a second one, then tried to fix its mistake with closePosition. closePosition closes the entire market position. Both entries. It ended flat, −$0.76, having executed a good entry and then deleted it out of embarrassment. The rule now in every executing prompt: one createOrder per run, verify the fill before any further order call, and never perform surgery with a chainsaw.

The v2 survival guide (every trap I personally stepped in)

• Model selection is per-agent — set one exclusive LLM, kill auto-select, and revert temporary switches immediately. An entry goal fired on my temporary model once: 678 credits, ~35× normal.

• Strict/Fixed Tools is a hard whitelist. Untucked tools silently no-op; the whitelist edit is the load-bearing step of a deploy, not the prompt paste. Exception: ReadMemory is core and always on — bound it in the prompt instead.

• Require Open Positions ON means your monitor never runs while flat — and SL/TP fills never get reconciled. OFF for any monitor that books closes.

• Auto-scale cooldown multiplies your manual values ~4×. Deselect first, then set.

• Collateral Requirement <90% silently blocks all goal execution. “Zero runs in N days” starts here.

• Trigger semantics: state vs cross. Re-derive after any migration (see: my 1,400 credits).

• Show Raw → Messages is your microscope. Exact tool inputs, failed and successful. Use it before theorizing.

• First-run version echo: line 1 of your goal description is line 1 of the run’s human message. If it’s not the version you just pasted, the old text is live.

• And a new one for the watch list: the current model will occasionally write a final reflection that contradicts its own run — one of mine completed its job perfectly, then claimed the tools it had just used don’t exist. Read the trace, not the summary. (Fix queued: reflections must open with the run-state ledger.)

What’s in Package v9.6

Deploy order: configs → hunters → monitors (flip Require Open Positions OFF) → reviews before your next Sunday review cycle. Verify each with the first-run version echo and a clean first candle fetch.

What’s next: 562 markets

While debugging all of the above, I had my agent dump the platform’s own knowledge base. Buried in it: 562 active markets on v2, including a meme-and-community perpetuals tier at 3–10x leverage — fifty-plus tokens whose main catalyst, sooner or later, is gravity.

Long-time readers know I’ve been quietly designing a strategy for exactly that universe since April, back when it died because only one of four candidate tokens even had a perp market. That blocker is gone. The Reaper post is coming.

Honest P&L, as always. The bots are patient. I’m learning to be.

Package v9.6 and the deployment guide available per dm for paid subscribers.

In the last post, every run scored 100/100 while one of them lost 32% of a position. The lesson was that completion scores don’t measure correctness.

This post is about the next layer down. The bug I found this week wasn’t in a strategy, wasn’t in a gate, wasn’t in the platform. It was in a configuration I wrote to make the bots safer. The safety setting silently disabled the safety feature.

And I only found it because I finally ran a proper engineering audit on my own prompt package — the kind of audit I’d run on any codebase at work, but had somehow never pointed at the 5,600 lines of prompts trading my actual money.

(Disclosure, as always: I hold CDX. I’m long the platform I write about — that’s why I keep stress-testing it with real money.)

The Ratchet

Quick recap for new readers. My BTC Maxi and MACD bots carry positions for days. In May, a BTC long ran to +12.77% and round-tripped all the way back to breakeven before closing. That hurt enough that I built a profit-lock ratchet into the position monitors: as the price move grows, the stop loss tightens one-way behind it. +2% locks breakeven. +5% locks +3%. The stop never moves backward.

The ratchet has one obvious precondition: to move the stop loss, you have to know where the stop loss currently is. The ONE-WAY rule — never loosen, only tighten — is a comparison. targetSL > currentSL. You need both sides.

Hold that thought.

Strict Tools — the feature I love that I then misconfigured

cod3x has a feature called Strict Tools mode that I consider one of the best ideas in the whole harness: instead of telling the model which tools not to use (prose bans that LLMs cheerfully ignore — I documented a monitor burning 12.5 credits on five banned ReadMemory calls), you physically remove the tools from its toolset. The platform rejects the call. Structure instead of instruction.

I’d been burned by prose bans enough times that when I converted my monitors to Strict Tools, I went minimal. Four tools each: positions, candles, position manager, journal. Everything else — deselected. Lean, cheap, deterministic. My MACD monitor dropped from 12.5 credits a run to about 4. I was proud of that whitelist.

Then, weeks later, I added the ratchet to those same monitors.

You can see where this is going. The ratchet needs the current stop loss. The current stop loss lives in the orders data — GetHLOrdersTool. Which was on my “Tools NOT to enable” list. Which I never revisited, because the whitelist was written for the monitor the ratchet was added to later.

The positions tool returns entry price, current price, PnL, leverage. It does not return your resting stop-loss trigger. My ratchet was comparing against a number it had no way to read.

Two runs, two different wrong answers

Here’s where it gets interesting — and where cod3x’s run logs earn their keep again. Because every prompt of mine carries a version stamp that the platform echoes into the run log, I can line up two runs of the identical prompt and watch the model handle the impossible instruction two different ways.

Run #182 (BTC Maxi monitor, +2.18% price move — ratchet should fire):

“However, the current stop loss is not exposed in the strict position tool output. To strictly adhere to the ONE-WAY RULE (never move SL backward), the ratchet action was safely aborted (RATCHET_FAILED).”

The model noticed it couldn’t see the stop, and gave up. Conservative. Arguably correct. But the ratchet — the feature built specifically so winners stop round-tripping — did nothing. Score: 100/100.

Run #183 (same monitor, four hours later, +3.38%):

“Since the price move exceeded the 2% threshold, the stop loss was ratcheted to breakeven ($59,501) to lock in gains.”

Same prompt. Same missing data. This time the model just... did it. Moved the stop to breakeven without ever knowing where the stop was. Score: 100/100.

Run #183 happened to be fine — the stop was below breakeven, so the blind move tightened it. But think about what “blind” means here: if a previous run had already locked the stop at +1.5%, this move would have dragged it backward to breakeven. The blind path can violate the exact ONE-WAY rule it quotes. The safety feature, lacking its input, degraded into a coin flip between “do nothing” and “guess.”

Two runs, one prompt, opposite behaviors, both scored perfect. If you’ve read post 8, you know the score was never going to catch this. The version-stamped run logs caught it — that echo of # Version: into every run is, I’ll say it again, the single most underrated observability feature in any LLM harness I’ve used.

The audit that found it

I didn’t find this bug by staring at the ratchet. I found it by finally doing what I’d do to any production codebase: a structured four-phase audit. Map the repo. Collect evidence with file-and-line citations. Rate severity. Build a task plan.

My “repo” is 5,600 lines of prompts, a knowledge base, and a deployment guide. The audit graded it B−. The finding I just described was the only Critical. But the High findings were almost more embarrassing, because they were all the same finding wearing different hats:

• A config line still declaring an indicator parameter from two versions ago (length:50 where every actual fetch uses length:14)

• A version reference reading V8.9.11 inside a block stamped V8.9.13

• A deployment guide confidently documenting five versions that no longer exist

Version drift. Everywhere. I write version numbers in roughly six places per prompt — stamp, title, section header, inner config line, agent config, manifest table — and for three consecutive sessions I’d fixed drift manually, declared a “canon” about sweeping all locations, and then drifted again. Discipline was losing to entropy, 3–0.

Structure beats discipline (again)

The fix for the ratchet was small: add GetHLOrdersTool to both monitor whitelists — five tools now — plus a hard precondition: read the actual stop from the orders data; if you can’t read it, abort. Never ratchet blind. One fetch now feeds three consumers: the ratchet, a naked-position check, and a new RULE 0 that force-closes when price has blown through a stop that didn’t fill (the −32% failure mode from post 8 — that protection is finally on all four monitors).

But the fix for the class of bug was a script. verify_package.py: 60 lines of Python that treat my CURRENT VERSIONS table as the single source of truth and grep every stamp, title, header, config line, and the deployment guide against it. It runs before every package ship. If it fails, nothing ships.

First run: 9 errors. Including every stale guide row and a drift I’d introduced that same session.

Current run: PASS, 0 errors.

The same principle that makes Strict Tools the right design — don’t instruct, constrain — applied to my own workflow. I’d built structural guards into the bots for months while running my own process on vibes and good intentions. The auditor needed auditing.

And the new canon that came out of it, which I’d offer to anyone building agent systems on any platform: a tool whitelist must be re-derived every time a prompt gains a data dependency. A whitelist that predates the feature it serves isn’t a safety control — it’s a latent feature-kill with a 100/100 score.

What’s next

The fixed monitors (MACD V1.6, BTC Maxi v1.0.10) are deployed and waiting on the next funded run cycle — when the first ratchet fires with a real stop-loss read in the log, I’ll update this post with the receipt.

There’s also a second forensic from this week that deserves its own post: a stale-data warning that sent a bot back through its own entry logic and got the same position opened twice. Different bug class, same lesson family. Soon.

And on the platform side — the cod3x team confirmed some of what’s coming in v2 while fixing a ReadMemory issue I reported (reported in the afternoon, fixed by evening, which remains the fastest platform turnaround I’ve experienced anywhere): server-side warmup so a 550-candle indicator computation can return only the candles you actually need, Supertrend joining the indicator set, and a new triggers system underneath it all. For strategies like my Andean bot, where the candle payload is the run cost, compact-fetch alone changes the economics. The harness is already the best place I’ve found to run LLM trading agents; v2 is aimed squarely at the remaining cost frontier.

For paid subscribers the full V1.6 / v1.0.10 monitor prompts (copy-paste ready, both whitelists), the verify_package.py script, and the four-phase audit prompt I used via dm— point it at your own prompt package and see what grade you get.

Not financial advice. The bots trade my money; the bugs are mine; do your own research.

This post is about how that trust was misplaced — and how I found out.

It starts with one SOL position that quietly bled to −32.61% while every single run that touched it reported a perfect score. By the time I’d traced it to the bottom, I’d found four separate failures stacked on top of each other, each one hidden by the one above it. And the thing that exposed them wasn’t a crash or an alert. It was a screenshot of a position I didn’t remember opening, sitting at a loss I didn’t authorize.

If the last post was about the system finally working, this one is about learning that “working” and “reporting success” are not the same thing.

The screenshot

I was doing a routine check and saw it: a SOL long on the Andean wallet, −$12.08, down nearly 30%, liquidation price uncomfortably close. I had no memory of this trade. The bot’s last few runs all showed the green “Completed — 100/100” badge cod3x stamps on a successful run.

So I pulled the run log. And the bot’s own final reflection said this, in plain text, having scored itself 100/100:

⚠️ Note: The SOL position was opened without SL/TP protection. Would you like me to add stop-loss and take-profit orders to it?

Read that again. The agent noticed the position had no protection. It flagged it. And then it ended its run by asking me a question — as if there were a human sitting in the loop ready to answer a trigger-fired autonomous run at five in the morning. There wasn’t. There never is. The question went into the void, the position stayed naked, and the score said 100/100.

That single reflection is the whole post in miniature. The score measures whether the run finished its checklist. It says nothing about whether the checklist was the right one, or whether the position the bot was supposed to be protecting was quietly being liquidated.

I had built a system that could tell me it succeeded while it failed.

Bug 1: the position was opened naked

The first layer was the simplest to understand and the most embarrassing.

When the Andean bot opens a trade, it can’t place the entry and the stop-loss in a single atomic action — the exchange doesn’t support it. So the prompt does it in two steps: open the position, then attach the SL and TP as a separate call. There’s a tiny window between those two calls. If the second one fails — or the run dies, or the platform hiccups — you get a live position with no protection.

The entry prompt had a guard for this. After placing the orders, it checked the response from the SL/TP call and, if that came back wrong, it was supposed to close the position and halt.

The problem: it trusted the call response, not reality. The order-placement call returned something that looked fine. But when you actually queried the live order book, there were no protective orders on the position. The response and the reality disagreed, and the prompt believed the response.

The fix is a principle I should have applied from the start: don’t trust what a tool tells you it did — go check what’s actually true. The hardened entry now re-fetches the live order book after placing orders. If the position is open and the stop or target is missing, it closes the position. It does not ask me. It does not journal a success. A run that ends by asking the user to add protection is now flagged as a critical violation, because there is no user to ask.

That closed the window. But it didn’t explain why the already-naked position had sat there for two days.

Bug 2: nothing was watching

Here’s the architectural mistake, and it’s the one I’m most annoyed at myself for.

Three of my four bots have a monitor — a separate goal on a timer that wakes up every four hours, looks at any open position, and manages it. Checks the age, checks the drawdown, makes sure the stops are still attached. A safety net that runs regardless of what the market is doing.

The Andean bot didn’t have one.

For the Andean, I’d baked the monitoring logic into the entry runs themselves. The position-management check only happened when a new trading signal fired the goal. That seemed efficient at the time — why run a separate monitor when the entry goal already wakes up and can check things?

Because signals stop arriving. That’s why. The naked SOL position opened, and then no new Andean SOL signal fired for two days. With monitoring welded to the signal path, “no signal” meant “no monitoring.” The one moment a position most needs a safety net — orphaned, unprotected, drifting — was exactly the moment the design guaranteed nobody was looking.

The other three bots would have caught this within four hours. The Andean was structurally blind to it.

So I built the missing monitor: a time-based sweep, every four hours, that scans the Andean positions and acts. Its first job is the one that would have saved the SOL — detect a position with missing protection and re-attach a conservative stop and target immediately.

This became a rule I’ve now written into the architecture as a law, not a preference: every bot that can open a position needs a monitor on its own clock, independent of its signal path. Monitoring that depends on signals fails silently in precisely the conditions where it matters most.

Bug 3: the stop that fired but didn’t fire

I deployed the new monitor. Its very first live run did its job — it found the orphaned SOL and closed it. Good. Except the reflection contained a sentence that stopped me cold:

Stop loss at $71.50 had triggered but position remained open — manual closure executed.

So now there was a third layer. By this point the position wasn’t even naked anymore — the earlier fix and the monitor had gotten a stop attached. The stop’s trigger price was hit. And the position stayed open anyway.

A stop-loss order can exist on the book, the price can trade clean through its trigger, and the position can simply… not close. Gap, thin liquidity, a platform-side execution failure — the cause matters less than the lesson: the presence of a stop order is not proof of protection. My monitor’s integrity check confirmed “yes, there’s a stop attached” and moved on, satisfied, while the position bled past it.

The fix is a new check that runs first, before everything else, and it’s based on price rather than on the existence of an order: if the current price is past where the stop should have fired, but the position is still open, the stop didn’t execute — close at market, now. The order book can lie about whether you’re protected. Price can’t.

That’s three nested failures from one position: opened naked, never swept, then stopped-but-not-stopped. Each fix only revealed the next layer underneath.

But the worst bug wasn’t in the SOL chain at all. It was hiding in plain sight in my best-behaved bot.

Bug 4: the percentage sign that meant two things

While reviewing the logs from a totally healthy BTC position — one that was up, protected, behaving perfectly — I noticed the monitor’s journal entries didn’t agree with each other. Same position, same entry price, three runs:

• 04:14 — “PnL: +4.16%”

• 10:16 — “PnL: +9.82% ROI ($3.88)”

• 16:14 — “PnL: +2.87% (+$188.65)”

Look at the dollar figures. On a position of roughly $200, one run claims +$3.88 and another claims +$188.65. They can’t both be real. And the percentages are flip-flopping between two completely different things — sometimes the raw price move, sometimes the leveraged return on margin, which on a 5x position is five times larger.

This wasn’t cosmetic. I’d just built a profit-lock ratchet for two of these bots — a mechanism that progressively tightens the stop as a trade runs, locking in gains so a winner can’t round-trip back to breakeven. (That round-trip had cost me real money in an earlier post; the ratchet was the fix.)

The ratchet works off a percentage. At +2% it moves the stop to breakeven; at +10% it locks in 7%. And the stop level it calculates is in price terms — a 7% lock means a stop at 7% above the entry price.

Now combine that with the percentage confusion. On a 5x position, a healthy +2% price move shows up as +10% leveraged return. If the ratchet reads that +10% and locks 7%, it places the stop 7% above entry — which on a trade that’s only moved +2% is above the current price. A stop above the current price on a long position closes it instantly.

The “profit-lock ratchet” I’d built to protect winners would, fed the wrong percentage, execute a winning position at the first opportunity. A profit protector that kills profits. It hadn’t fired yet only because the run that happened to read the number correctly got lucky.

The fix was to stop trusting any pre-computed percentage field at all. The platform reports a “PnL percent” that is leveraged return — useful for some things, lethal for price-based decisions. Every place a bot makes a decision against a price threshold — the ratchet, the daily-loss limit, the invalidation checks — now computes the raw price move itself, from the entry and current prices, and refuses the convenient field. I added a sanity guard on top: if the number you’re about to act on is suspiciously close to five times the price move, you’re holding the leveraged figure by mistake — recompute.

This is the one that scared me most, because nothing about it looked broken. No naked position. No screenshot. Just a quietly mislabeled number sitting inside the exact mechanism I’d built to keep me safe.

The thing that connects all four

Here’s what I keep coming back to. Every one of these runs scored 100/100. The naked position, the unswept orphan, the stop that didn’t stop, the ratchet that would have closed a winner — all of it happened inside runs the system reported as complete successes.

Because the score answers a narrow question: did the agent finish the steps it set out to do? It does not answer were those the right steps, or did the position survive, or does this percentage mean what the next line of logic thinks it means. A run can execute its checklist flawlessly and still leave you with a liquidating position and a stop pointed the wrong way.

The lesson from my earlier posts was that instrumentation beats features — that being able to see what’s happening matters more than adding another strategy. This is the sharper, more uncomfortable version of that lesson: your instrumentation can lie to you, too. A success badge is itself a feature that needs auditing. The journals didn’t catch these bugs. The score didn’t catch these bugs. Reading the actual reflection text, line by line, against the actual wallet caught these bugs.

There’s a defense-in-depth shape to all of this that I find oddly reassuring. The four fixes form a chain where each one backstops the others: the entry tries hard not to leave a position naked; if it fails, the monitor catches it within four hours; if the stop is missing, the monitor re-attaches it; if the stop is present but doesn’t fire, the price-based check force-closes it; and underneath all of it, every percentage that drives a decision is now computed from price, not trusted from a field. No single layer is sufficient. Together they’re hard to defeat.

That’s the actual product, I think. Not the strategies — anyone can write a MACD cross. The product is the slowly accumulating set of ways the system has tried to hurt me and the guards I’ve built so it can’t do that one particular way again. Every bug becomes a rule. Every rule outlives the bug.

What I’m watching for now

Two things.

First: the stop that triggered but didn’t execute is partly a platform concern, not just a prompt concern. My price-based check backstops it, but a stop that doesn’t fill when price trades through it is something I need to raise with cod3x directly. A guard at my layer is not the same as the exchange honoring its own orders.

Second, and more honestly: I now distrust the success score, and I don’t yet have a clean replacement. “Did the position survive and behave as intended” is a much harder thing to measure than “did the run finish.” For now the answer is manual — I read reflections against wallet state. That doesn’t scale, and the irony of building an auditor bot two posts ago only to be back to reading logs by hand is not lost on me. The next build is probably an auditor that reconciles claimed outcomes against actual wallet outcomes, and flags the gaps. The bots are good at telling me what they did. I need something that checks whether it’s true.

The market didn’t teach me anything this week. My own infrastructure did — by failing quietly, four times, behind a wall of perfect scores.

Pausing is a position. So, it turns out, is doubting your own dashboards.

If you’re building agentic systems — trading or otherwise — I’d genuinely like to hear how you separate “the run completed” from “the run did the right thing.” It’s the gap I’m most stuck on. Comments are open.

Paid subscribers get the deployable prompts and configs: the hardened entry with live-order re-verification, the standalone monitor with the stop-execution-failure check, and the price-move correction across every ratchet and loss limit. All four fixes, copy-paste ready.

What’s running now

Three weeks ago I wrote about spending €50 to make $3.50. The audit was brutal — 229 runs, one trade, four bots halting endlessly. I killed 75% of my infrastructure and started over with two bots and 53 credits per day.

Since then, every assumption I had about these bots has been challenged. Some were confirmed. Most were wrong. Here’s what actually happened.

The Andean finally traded

The Andean Oscillator strategy — the one built on Alex Grover’s pullback detection system — had been running for weeks without a single entry. Ninety-five percent of runs halted at Gate 2: NO_CROSS. The oscillator just sat in one state, bull dominant or bear dominant, and never flipped.

The fix, as I wrote last time, was parameter scaling. The original strategy used length=50 on one-minute charts. I was running the same parameter on thirty-minute charts — making the oscillator thirty times smoother than intended. I reduced it to length=14 and... still nothing. The crosses existed on the chart. The bot couldn’t see them.

The problem was a timing gap. Triggers fire on 15-minute charts. The goal evaluated 30-minute candles. By the time the goal ran, the cross was already two or three candles old on the 30-minute timeframe — outside the freshness window. The cross was real but stale.

The fix was simple: align everything to 15 minutes. Triggers, candle fetches, all indicators — same timeframe. Within days, the Andean caught a BTC SHORT at $80,501 that hit take profit at $79,835 for +$5.80. First successful Andean trade in the new configuration.

Then it opened a position it shouldn’t have.

The phantom trade

Run #215 is the most instructive failure I’ve had. The bot evaluated all four gates — HMA slope, Andean crossover, pullback validation, Grover Llorens confirmation. Gate 2 failed: NO_CROSS. The Andean oscillator was bearish, no flip detected. The bot wrote this conclusion in its reasoning.

Then it opened a $1,140 BTC LONG anyway. No stop loss. No take profit. And journaled the run as “NO_CROSS — no trade executed.”

The position was live, unprotected, and invisible to every monitoring system because the journal said nothing happened. I found it by checking the wallet directly.

This is the most dangerous class of bug in autonomous trading: the model’s actions diverging from its reasoning. It correctly evaluated the conditions, correctly concluded no trade should happen, and then called the trade execution tool anyway with fabricated gate-pass values in the reasoning field.

The fix is structural, not instructional. Telling the model “don’t trade on halts” is prose — and prose is unreliable. Instead, I made the trade execution tool physically unavailable unless explicitly activated. The model must call SelectTools(["HLPositionManagerTool"]) after all gates pass, and only then can it call the trade tool. If any gate fails, the tool doesn’t exist in its action space. It literally cannot call it.

This SelectTools guard is now in every hunter prompt across all bots. Structure beats instruction.

The sequence trigger revolution

Cod3x overhauled their trigger system to support sequential steps — and this changes the economics of the entire setup.

Previously, all trigger conditions had to be true simultaneously. For MACD, this meant a price/SMA condition would fire the trigger, then the goal would check if a MACD crossover happened within the last two candles. Often it hadn’t — the cross was three or four candles ago, still visible on the chart but outside the detection window. Hundreds of runs burned credits confirming “crossover already stale.”

With sequences, the MACD cross itself is the trigger event. Step 1 fires when the MACD line crosses the signal line and ADX is above 20. Step 2 is a lightweight confirmation that completes immediately. The goal runs within minutes of the actual cross, not hours later when a secondary condition happens to match.

For the Andean strategy, sequences solve a different problem. The original AND-group required the Andean cross, HMA alignment, and Grover Llorens signal all true in the same evaluation. In practice, the GLA signal often lagged the Andean cross by one to three candles. The sequence lets the cross happen first, then waits up to one hour for GLA confirmation. This matches how the original strategy actually works — the cross is the setup, the GLA is the entry timing.

MACD catches HYPE

The MACD bot, reactivated after the audit when ADX pushed above 20, caught a HYPE LONG at $45.42. Take profit hit at $48.91 for +$8.98 — the largest single trade profit across all bots. The same strategy that produced zero trades across 100 runs in ranging markets worked exactly as designed when the regime shifted.

I’ve since expanded MACD to seven assets: BTC, ETH, SOL, HYPE plus ZEC, NEAR, and VVV at 2% risk per trade. The privacy and AI coin narratives are producing high-ADX momentum moves — exactly what the MACD crossover strategy is built for.

BTC Maxi: the grinder

The BTC Maxi bot continues to be the most consistent performer, though not always in the direction I’d hope. It opened three positions this period: one hit take profit, two hit time limits with losses. Net realized: roughly -$8 on the closed trades, with an active position currently +$4.32.

The monitor goal got a cost optimization — from 16 tool calls per run down to 3-4 — saving about 48 credits per day. The insight: the monitor was doing a full research project every four hours (fetching news, looking up journal entries, pulling candles) when all it needed for a HOLD decision was position data and a time check.

Goal 2 (Lower Bollinger Band) finally ran for the first time after I configured its trigger — it had been sitting with no trigger set since launch. Sometimes the bug is just a missing dropdown.

The scoreboard

Still not profitable after credits. But the trajectory is different. The bots that were burning 224 credits per day on 100% halt rates are now running at ~150 credits per day with actual trades happening. The MACD HYPE trade alone nearly covered a week of credits.

What’s running now

For paid subscribers

The full prompt package (v9.1) is available now. This version is cleaned up — only current, deployable prompts. No legacy 30-minute Andean configs. No outdated trigger documentation. Every prompt includes the SelectTools trade guard, schema guards, and SL/TP decimal specifications.

New in this package: Andean ETH and SOL goals (V4.0.9, 15-minute, length=14), MACD goals for ZEC, NEAR, and VVV at 2% risk, and the complete SEQUENCE trigger configurations for every bot.

If you are a paid subscriber, just shoot me a message on Substack and I’ll send you the latest prompt versions!

The phantom trade was the scariest moment so far. Not because it lost money — it didn’t, I caught it in time. But because the bot’s journal said everything was fine while an unprotected position was live. The lesson: never trust the model’s self-report. Verify against the wallet. And make dangerous actions physically impossible, not just discouraged.

Then everything went quiet. A hundred runs. Then another hundred. All halts. No trades.

Today I have two bots left. Five goals. Fifty-three credits per day.

And for the first time, I think I understand why.

The numbers that forced the conversation

I’d been putting off the audit. The bots were running, the dashboards showed green completion scores, the journal entries were clean and structured. Everything looked healthy.

Then I counted.

Over the period since May 4th, across all four strategies:

BotRuns (last 7d)Trades (last 7d)Trades (since launch)Realized P&LCredit cost (est.)VWAP Hunter0 (paused)0Several shorts, mixed results~breakeven€0 (paused)MACD Hunter1000SOL/BTC/HYPE shorts, one loss~+$10 net~€15Andean Hunter990ETH SHORT TP hit +$3.76, others cancelled~+$3~€12BTC Maxi~3011 trade (RSI dip buy)+$3.50~€3.50Total~2291~+$16~€48.50

Two hundred and twenty-nine runs in the last week alone. One trade. And the bots that had been trading — MACD caught some decent shorts on SOL and BTC in early May, netting a few dollars each — went completely silent.

The MACD bot had proven it could find entries. It caught a SOL SHORT at $88.21 on a clean 4H bearish crossover, ADX 36.9. Textbook. But then the market shifted into a regime where either ADX sat below 20 (no trend) or crossovers were already stale by the time the trigger fired. One hundred consecutive halts.

The weekly review agents I’d built — those self-auditing goals that read 100 journal entries every Sunday — confirmed it with brutal clarity:

MACD: exec_rate=0%, top halts: NO_CROSSOVER(61%), NOT_TRENDING(36%)
Andean: exec_rate=0%, top halts: NO_CROSS(95%)

Zero percent execution rate. Not one percent. Zero.

The parameter nobody scaled

Here’s where it gets interesting. And a little embarrassing.

The Andean Oscillator strategy I’m running is based on a well-known approach by Alex Grover. The original was backtested on the one-minute chart with the default Andean length of 50 — meaning 50 minutes of price history to compute the oscillator.

I deployed it on a thirty-minute chart with the same parameter.

Length 50 on a 1-minute chart = 50 minutes of lookback. Responsive. Oscillator flips frequently as pullbacks complete.

Length 50 on a 30-minute chart = 25 hours of lookback. Glacially smooth. The oscillator sits in one state — bull dominant or bear dominant — for 10, 20, sometimes 75+ consecutive candles. Fresh crossovers essentially never happen.

This is why 95% of Andean runs halted at Gate 2 (NO_CROSS). The gate was checking for a bull/bear flip that occurs multiple times per hour on 1-minute charts and roughly once per week on 30-minute charts with the same settings.

I’d spent weeks building increasingly sophisticated architecture around this strategy — four-gate entry validation, pullback checking, GLA confirmation, position monitoring, breakeven logic. All of it working perfectly. None of it ever reaching the point where it could fire, because the very first indicator was computed with unscaled parameters.

The infrastructure was beautiful. The input was wrong.

The trigger that watched itself

While investigating, I pulled up the trigger configuration in cod3x’s UI. The Andean Hunter has two trigger groups — one for LONG entries, one for SHORT — each with three AND-conditions: an Andean cross, an HMA Cloud cross, and a Grover Llorens signal.

The SHORT trigger was configured correctly: Andean Bear Crosses Above Andean Bull.

The LONG trigger read: Andean Bull Crosses Above Andean Bull.

Bull crossing above itself. A logical impossibility. This trigger had never fired. Could never fire. It was deployed that way from day one.

The “Fired” counter confirmed it: 0x / Never.

My LONG trigger had been dead since launch. Every single Andean entry opportunity on the bullish side — for weeks — was invisible to the bot. And I never noticed because the SHORT trigger was still active, and the dashboard shows both groups as “active.”

The fix was a UI dropdown change. Two seconds. The bug had been live for over a month.

The audit

I’d planned this for when credits ran out, but the data was clear enough to act on immediately. For each bot, one verdict:

VWAP Hunter → KEEP (already paused). Zero credit burn. The strategy waits for ADX below 20 — a ranging market. We’ve been in a trending/choppy regime. The pause was the right call weeks ago.

MACD Hunter → PAUSE. The strategy has proven it can trade — it caught clean shorts on SOL, BTC, and HYPE when the regime was right. But the market hasn’t been trending for ten days straight (BTC/ETH/HYPE ADX below 20 most of the period). Burning 100 credits per day to confirm “still not trending” is not a business. Paused all four assets. The weekly review goal stays active — it’ll tell me when the regime shifts.

Andean Hunter → CHANGE. The strategy had one clean win — an ETH SHORT that hit take profit at $2,323 for +$3.76. It proved the four-gate architecture can find real entries. But then the parameter scaling issue meant it never found another one. I reduced the Andean length from 50 to 14 and switched the goal to evaluate 15-minute candles (matching the trigger timeframe). ETH and SOL paused — the control data from length=50 is conclusive. BTC stays live as the test case.

BTC Maxi → KEEP. The only bot that actually traded. One position opened on an RSI oversold signal, managed through 23 monitor runs, closed at the 96-hour time limit with +$3.50. Clean execution. The ArticleSearchTool had a schema bug (Qwen hallucinating a featuredOnly parameter as boolean instead of string) that caused 10x retry loops — fixed with a one-line schema guard in the prompt.

Daily burn dropped from 224 credits to 53. Same €50 credit purchase now lasts 94 days instead of 6.

What I actually learned

The technical fixes matter — scaled parameters, aligned timeframes, killed the self-comparing trigger. But the meta-lesson is simpler.

I was optimizing the wrong layer. Weeks of prompt engineering, gate reordering, memory guards, credit efficiency patches. All real improvements. But the strategy couldn’t trade because the indicator input was misconfigured at the most basic level — a parameter that nobody thought to scale when changing timeframes.

The weekly review bots told me the symptom (95% NO_CROSS, 0% MACD execution this week) every Sunday. They just couldn’t tell me the cause. That took going back to the original strategy video, watching a German YouTuber explain the Andean Oscillator on a 1-minute Bitcoin chart, and realizing that my 30-minute deployment was running with identical settings.

Structure beats instruction. But correct inputs beat correct structure.

What’s running now

The Andean BTC goal is the one to watch. If the 15-minute timeframe with length=14 starts catching the crosses that were visible on the chart but invisible to the bot, the strategy thesis is validated and I’ll roll it to ETH and SOL.

If it doesn’t, I know within a week, and the weekly review bot will tell me exactly why.

For paid subscribers

The full updated prompt package (Subscriber Package v8) is available below. This includes:

• Andean BTC V4.0.8 — the 15-minute aligned prompt with length=14 and 6h max-hold

• BTC Maxi v1.0.5 — with ArticleSearchTool schema guard

• All personality descriptions, trading style configs, and trigger configurations

• Deployment guide with copy-paste instructions for cod3x

The prompts are clustered per bot — personality → config → goal prompts → monitor → review → reference — so you can copy everything for one bot without jumping between sections.

Just write me a DM on Substack and I’ll send you the latest Subscriber Package version.

Next post: either “the Andean finally traded” or “I killed another bot.” At 53 credits per day, I have 94 days to find out which one.

Let me know if you have any specific questions regarding my bots or you need any advice. You can also find me in the cod3x discord @luwihu or on twitter @cheldorito. Cheers!

That cost showed up faster than I’d planned for. And while it was happening, I noticed something the system wasn’t built to catch — and built a new bot to catch it.

This post is two things in sequence: how I knew to reactivate MACD, and what I built to plug the structural hole I’d been ignoring.

The reactivation signal

I wrote the reactivation criteria down so I wouldn’t have to argue with myself in the moment. For MACD, the rule was: 4H ADX above 22, sustained 24+ hours, across BTC/ETH/SOL.

Three days later, BTC was at $81,245. Daily ADX had jumped to 27.6, the highest reading since March. The descending channel that had compressed price action since November finally broke. Iran de-escalation pushed Brent crude back below $107. ETF flows turned positive again — $629M MTD inflows after a brief reversal. Whales had been accumulating: 270K BTC over 30 days, exchange reserves at a 7-year low.

None of that mattered until ADX confirmed it.

That’s the part I want to be honest about. The catalysts were real. The narrative was bullish. But my job isn’t to read narratives — my job is to wait for the regime indicator I committed to and then act on it without negotiating. If I’d reactivated based on Iran headlines or Saylor accumulation tweets, I’d be trading vibes. If I’d waited for “perfect confirmation,” I’d miss the move I designed the rule to catch.

ADX 27.6 is not vibes. It’s a number that crossed a threshold I wrote down 72 hours earlier when I had no idea where the market would go. I flipped MACD back on across all four assets the same evening.

A small rule change I made on the way

The original reactivation rule required confirmation across BTC, ETH, and SOL simultaneously. Reading the chart that night, BTC had clearly led — the breakout was sharp, daily ADX was already in trend territory, and the move was unambiguous. ETH and SOL were following but with a lag.

The all-or-nothing version of the rule meant waiting for the laggards. That had felt prudent when I wrote it; in practice it meant deferring the reactivation on the asset that had actually triggered it.

I changed the rule. Per-asset reactivation when that asset’s 4H ADX crosses the threshold sustainedly. Not retroactively, not based on vibes — based on the observation that regime changes don’t propagate uniformly across correlated assets, and the lead asset reactivating earlier captures more of the move.

Worth noting because rule changes during live operation are usually how systems decay. The discipline is to change rules in writing, after a documented mismatch with reality, and with a stated reason — not in the heat of a move when you want to take a trade.

The hole I’d been ignoring

So MACD was back on. But I noticed something while I was sitting with the frustration of having missed the rally’s first 9% move.

My three bots had specialized regimes:

• VWAP Hunter — ranging markets (1H ADX <25)

• MACD Hunter — trending markets (4H ADX >22)

• Andean Hunter — pullbacks within trends (oscillator-driven)

Each of these is regime-conditional. Each waits for its regime to be present. And in the days BTC ran 75K → 82K cleanly without meaningful pullbacks, none of them was the right tool. MACD was paused because the prior week was ranging. Andean kept halting because there were no fresh oscillator crosses on closed candles — bull was already above bear from before, sustained-state continuation, not a flip. VWAP was paused for the same reasons MACD was.

The strategies were correct, individually. The portfolio had a hole.

I’d been running three precision tools, each waiting for its regime. None of them was a “BTC is going up, position long” tool. None was a dip-buyer that woke up on technical weakness regardless of trend state.

This is the gap a bot like ETH Maxi (a template I’d already studied) is built for — single asset, LONG-only, two oversold signals, accumulate weakness.

I’d been thinking of ETH Maxi as a different strategy class. It is. But that’s the point. The right response to “none of my regime bots fits this market” isn’t to loosen one of them — it’s to add a tool with a different lens.

Building BTC Maxi v1.0

I forked the ETH Maxi template, ported it to BTC, and used the rebuild as an excuse to apply every lesson the last six months had taught me. Ten changes from the source template. I’ll cover the four that matter most.

1. Discrete tier parameters, not ranges

The original ETH Maxi sets stop sizes as ranges: “5–7%” for STANDARD tier, “6–8%” for STRONG. That feels flexible until you realize what an LLM does with a range — it picks the midpoint. Every time. The “tier” distinction collapses because the model resolves both ranges to the same numerical region in practice.

BTC Maxi v1.0 uses single discrete values per tier. STRONG RSI: stop 7%, leverage 6x. STANDARD RSI: stop 6%, leverage 5x. No interpretation, no midpoint averaging, no fuzziness. The tier label maps to one specific config.

This sounds like a tiny thing. It isn’t. Every “range” in a prompt is an invitation to the model to dissolve the structural distinction the range was supposed to encode. If you mean two things, write two things.

2. DCA with a drawdown floor

ETH Maxi allows DCA into losing positions on extreme signals. That’s the strategy’s whole personality — buying weakness, even into existing weakness. But the original template’s only gate is “STRONG signal” — the position can be losing –0.3% or –15% and DCA fires identically.

Real drawdown matters. A position 0.3% under is noise. A position 5% under is a real signal that the original entry was early. Adding to a 0.3%-loser is bag-holding for the sake of bag-holding; adding to a 5%-loser with a confirmed STRONG signal is what the strategy claims to do.

BTC Maxi v1.0 adds a –3% drawdown floor before any DCA add. Below that, the position waits for either the original SL/TP or further weakness. This is small in code and large in P&L distribution: it cuts off the failure mode where you triple your size on noise and then take a stop-out on the inflated position.

3. MAX_HOLD time exit

The original template has no time exit. A position can sit in chop for two weeks, neither winning nor losing meaningfully, occupying margin and paying funding. Eventually the SL or TP resolves it, but the cost of dead capital in the interim isn’t zero.

BTC Maxi v1.0 closes positions at market if they’ve been open more than 7 days at less than +0.5% P&L. The threshold is intentionally loose — I don’t want to time-stop a position that’s working slowly toward TP. I want to close the ones that are clearly going nowhere.

This is one of those rules whose value only shows up over many trades. Across a year, it converts a long tail of “stuck” trades into closed (small) losers that free capital for the next signal. The expected value is positive when you compound the freed-margin opportunity cost. Sub-linear on any single trade. Real over the lifetime of the strategy.

4. Halt code taxonomy

This is the boring one. It’s also the one that matters most for the next phase of the work.

Every halt path in the goal emits a specific string: HALT_NO_RSI_SIGNAL, HALT_POSITION_HOLD_PROFITABLE, HALT_VOLUME_EXPANDING_DOWN, and so on. Twelve codes total, one per non-trade exit reason.

The reason this matters: review goals can categorize. Without a fixed taxonomy, every weekly review I run on this bot is going to ask the LLM to infer halt categories from journal entries — which means it’ll hallucinate categories, miss patterns, and produce reviews that disagree with each other across runs. With a taxonomy, the review counts strings. Counting is reliable. Inference is not.

I learned this the hard way last week when one of my review goals reported a credit cost figure that turned out to be hallucinated — the LLM had estimated a number that felt right and reported it as fact. Halt taxonomy is the equivalent fix at the strategy layer: don’t let the model invent the categories it’s reporting on.

What it doesn’t do

I want to be specific about what’s deliberately not in this strategy.

It does not trade narratives. A widely-shared post on X this week predicted Saylor would buy $2-3B BTC over the next two weeks via STRC, sending BTC above $80k. The prediction may turn out right or wrong; I genuinely don’t know. What I do know is that single-source unverifiable claims don’t belong as trade triggers. If the narrative is right, the strategy captures the structural bid passively — a LONG-only dip-buyer benefits from any persistent accumulation regardless of whether it knows the accumulator’s name. If the narrative is wrong, no harm done. Building “trade Saylor’s tweets” into the logic is what costs people money.

It does not chase breakouts. This is a dip-buyer, not a momentum bot. If BTC is making new highs with expanding volume, BTC Maxi will sit out. That’s MACD Hunter’s job. Letting two bots fire simultaneously on the same asset is correlation risk dressed up as diversification.

It does not hold through confirmed structural breaks. The Monitor goal closes positions on confirmed 4H structure breaks with full-bar confirmation. Single-candle wicks don’t qualify; that’s the noise the SL is sized to absorb. But two consecutive 4H closes below a key support with expanding volume is a signal the thesis has been invalidated, and the strategy exits on confirmation rather than holding to the original SL.

The line between “let the SL do its job” and “exit on invalidation” is one of the harder calibrations in any trend-aware system. I’ve drawn it deliberately and conservatively: invalidation is a high bar; the SL handles ~95% of cases; the early exit only fires when the thesis is clearly broken with confirmation.

Wallet sizing — the small honest part

I funded this with €500 fresh capital in a separate wallet. That’s small.

At STRONG-tier sizing (1.5% risk, ~7% stop), each trade risks about $8.10 and runs about $115 notional position size at 6x leverage. A full 1.2R win is roughly $10 gross, ~$7-8 after fees. That’s not a get-rich-quick number. It’s a proof-of-concept number.

The reason for the small size: I don’t yet know how this strategy behaves on BTC specifically. The thesis transfers cleanly from ETH (lower volatility, similar dip patterns), but the per-asset behavior — fill rates, slippage, how often DCA actually fires — needs real data before I’d commit more.

Two weeks of live operation on real but small capital tells me more than two months of backtests. If it works, I size up. If it doesn’t, I’m out €500 and a lesson, not €5000 and a regret.

This is the trade-off most strategy posts skip. The math is always cleaner in the writeup than in the wallet.

What I’m watching for now

Three things over the next two weeks:

Trade frequency. The strategy should fire 2-4 times per week if BTC’s volatility profile holds and dips materialize. More than that and the trigger is too sensitive. Less than that and it’s too restrictive. The number itself isn’t a target; the rate of change in the number is what tells me whether the strategy is calibrated to BTC’s actual behavior.

Halt code distribution. I expect roughly half of all halts to be HALT_POSITION_HOLD_PROFITABLE (the strategy correctly skipping re-entries when already in profit) and the rest spread across signal-not-met categories. If I see any single non-position halt code dominating, that’s a calibration tell.

DCA behavior. Will it fire? Should it fire? The –3% floor is intentionally restrictive; in calm regimes it won’t trigger at all, and that’s fine. The test is what happens during a real flush — does the drawdown floor hold the line, does the size cap (3x original) prevent over-extension, do the recalculated SL/TP after each add work as expected. I won’t know until it happens.

I’ll write up the data when I have enough of it. Probably 3-4 weeks out. Until then it’s a proof-of-concept running on small capital, alongside the three regime-bots that handle their respective conditions.

The portfolio looks more complete now. Four bots, three regime tools plus one dip-buyer for the BTC-specific case where none of the regime tools applies. I’m not sure that’s the final architecture — it might turn out that BTC Maxi is the start of a per-asset Maxi family rather than a one-off — but it’s a more complete answer than I had a week ago.

If you’re running systematic strategies and want to discuss regime detection, halt taxonomies, or the perpetual debate between letting the SL work vs early invalidation exits — comments open. I read them.

Paid subscribers get the full deployable BTC Maxi v1.0 template — Personality, Trading Style, all three goals (RSI Oversold 15m, Lower BB 1H, Position Monitor), trigger configurations, and the pre-deployment checklist. It’s drop-in ready for cod3x; you’ll just need to paste the template.

Three weeks ago I had three trading bots happily running on cod3x.org, executing on Hyperliquid perpetuals — VWAP mean-reverter, MACD momentum trader, Andean oscillator pullback. Each one a precision tool, individually validated, each with its own thesis about when the market is tradeable.

This week I paused two of them.

Not because they were broken. Because the market wasn’t.

The diagnostic moment

I deployed a weekly self-audit goal across all three bots — a read-only goal that pulls 100 journal entries, classifies halts, and surfaces patterns. Boring infrastructure work. The kind of thing that doesn’t feel like a feature when you’re building it.

Then I ran them. Here’s what came back:

VWAP HUNTER (1H mean reversion):

• 100 runs, 1 trade, 0 wins

• 73% of halts: “NOT_RANGING” — ADX sitting at 25-50 across BTC/ETH/SOL

• The strategy fires when the market is range-bound. The market wasn’t.

MACD HUNTER (4H momentum):

• 100 runs, 1 trade, 0 wins (the trade got stopped at -$3)

• 70% of halts: “NOT_TRENDING” — 4H ADX persistently below 20

• The strategy fires when the market is trending. The market wasn’t.

Andean HUNTER (30m oscillator pullback):

• 100 runs, 3 trades, 1 closed at +$3.05

• 74% of halts: “NO_CROSS” — Andean oscillator not flipping fresh on 30m

• This one survived. The other two did not.

Same market, three lenses. Two said “not now.” One said “occasionally.”

What the halt data actually reveals

The pattern is the part worth thinking about.

The VWAP bot reads the 1-hour timeframe and sees ADX 25-50 — directional, trending. The MACD bot reads the 4-hour timeframe and sees ADX <20 — flat, ranging.

Both correct. Both true. Same market.

This is what late-stage chop looks like — small directional bursts (visible on 1H) inside a larger consolidation (visible on 4H). Neither bot’s thesis fits, but each bot is correctly identifying that fit.

I’d built three precision tools. The market handed me a moment when zero of three could find their footing — but the bots told me exactly that, in the language of their halt reasons.

The detour I almost took: more architecture

When systematic strategies stop firing, the engineer’s instinct is to build more.

Cod3x has a “Regime Switcher” template that does exactly this — detects regime first (TRENDING / RANGING / VOLATILE / NORMAL) using ADX + ATR percentile + EMA alignment, then activates strategy-appropriate parameters. Risk, leverage, stop distance, take-profit logic all adapt.

It’s elegant. I was tempted to merge my three bots into one regime-aware meta-bot.

But the math doesn’t work in this specific case. A regime-switcher still fetches candles and computes ADX before deciding which sub-strategy to fire. That’s ~5-7 credits per check, before any halt logic. Then if the wrong regime is detected, it halts anyway. You haven’t saved a halt — you’ve just renamed it.

More importantly: when I forensically traced what would have happened if I’d had a regime switcher running this week, the answer was the same outcome. ADX <20 → switcher activates VWAP → VWAP halts on its own threshold. The wrapper didn’t avoid the dead market; it just moved where the deadness expressed itself.

You can’t engineer your way out of a no-trade market. You can only stop spending money on it.

The optimization I had taken — a week earlier

The pause was the right call this week, but it’s worth noting that not every halt-heavy week is purely a regime problem. Sometimes the bot itself is wasteful, and the halts are loud about it.

Two weeks ago, the Andean bot was burning ~22 credits per halted run. Every single execution fetched 551 candles of 30-minute price data — because the trend filter (a niche indicator called UHL MA) needed 500 candles of warmup before producing a usable reading. That’s roughly 53,000 tokens hitting the model’s working memory on every run, halt or trade.

Most of those candles never mattered. UHL MA was answering one question: is the underlying trend up or down? You don’t need a 500-period indicator to answer that — most things on the market don’t.

I migrated the bot to use a Hull Moving Average (HMA) at period 50 instead. Same job — directional trend confirmation — with about a tenth of the lookback. Candle fetch dropped from 551 to 150. Working memory dropped from ~53K tokens to ~14K. Cost per run fell from 22 credits to about 7. ~67% reduction, validated across BTC/ETH/SOL within 24 hours of rollout.

Nothing else changed. Same gate logic, same Andean oscillator entry, same Grover Llorens confirmation, same risk model. Just one indicator swap.

The lesson there: before you accept that halts are the cost of doing business, check whether the halts themselves are unnecessarily expensive. A halt costing 22 credits and a halt costing 7 credits are extremely different things over a thousand-run sample. The right indicator at the right period earns its keep on the days the strategy doesn’t trade — which is most days.

(I covered the full migration — the actual prompt diffs and the diagnostic logs that confirmed the swap worked — in the paid tier earlier this week. Not pitching here; just flagging that this week’s HMA tag in the journals is the same change.)

The actual fix this week: pausing as strategy

So I paused VWAP and MACD. Andean stays running.

Burn rate dropped from ~600 credits/day to ~150 credits/day. At ~$0.01/credit that’s $42/week → $10.50/week. The remaining $50 credit balance now lasts 30+ days instead of 9.

Reactivation triggers, written down so I don’t second-guess them in the moment:

• VWAP reactivates when 1H ADX drops sustainedly below 25 across BTC/ETH/SOL for 24+ hours

• MACD reactivates when 4H ADX rises sustainedly above 22 across BTC/ETH/SOL for 24+ hours

• Andean keeps running — its 30m oscillator-pullback design is regime-agnostic by construction

This is a small thing dressed up as a deep insight, but the deep insight is real: the right move was to do less, not more. Letting precision tools sit dormant in the wrong conditions is a feature of having precision tools. Trying to make them tradeable in every regime would have eroded their precision.

The instrumentation matters more than the strategy

Here’s what surprised me most about this week.

Six months ago I would have looked at “0 trades in 10 days” and assumed something was broken. I would have rewritten prompts. I would have lowered ADX thresholds. I would have torn through the architecture looking for bugs.

But I couldn’t, because the journals told me exactly why each halt happened. Every single run logged its halt reason. The weekly review goals tabulated those reasons across 100 runs and produced a recommendation tree (R1-R5). The data didn’t say “the bot is broken.” It said “the bot is working perfectly; the market doesn’t fit.”

That distinction is impossible to make without instrumentation. And it’s the entire game.

If you’re building any systematic system — trading or otherwise — invest more in observability than in features. Halt reasons. Per-run cost tracking. Per-asset breakdowns. Confidence-weighted recommendations. The thing you’ll need at month three is not “another strategy” — it’s the ability to see what’s happening clearly enough to know whether to keep going.

I wouldn’t have paused this week if I hadn’t built those review goals. I’d have spent another $50 on credits, gotten zero trades, and concluded the strategies were broken.

What I’m watching for now

ADX divergence between timeframes is itself a signal. When 1H ADX and 4H ADX both settle in the 18-22 zone, that means the larger-timeframe regime is decoupling from the smaller-timeframe noise — usually the precursor to a real directional break.

I’ll know I’m wrong about pausing when I see that convergence and don’t reactivate fast enough to catch the move. That’s the trade-off: pausing is correct expected value, but it leaves real edge on the table when the regime turns.

I’m okay with that. The alternative — running expensive infrastructure during dead markets — is a trade with worse expected value and an emotional cost. Watching halt counters tick up while your wallet ticks down is bad for the kind of patient discipline these strategies need to work over the long run.

Pausing is a position. The market will tell me when to take a different one.

If you’re building agentic trading systems, I’d love to hear your halt patterns and how you handle wrong-regime weeks. Comments open. The next post will dig into what kind of regime change actually triggers reactivation — and how I built the watch criteria to avoid second-guessing the rules in the moment.

Paid subscribers get the deployable prompts and configs — including the V4.0 Andean migration covered earlier this week, and the reactivation watch goals as I deploy them.

This week, all three bots made their first real trades.

The Portfolio Right Now

As I write this, three positions are open across two wallets:

### MACD Wallet — $1,010 equity, +$9.00 PnL

**SOL LONG @ $84.95 → $89.16 (+$13.47, +14.87%)** 🎯

This one's working beautifully. Entry on April 12th via MACD bullish crossover. The bot scored it 10/13 — histogram accelerating, RSI in the sweet spot (55), price above SMA50, volume confirming. TP is set at $92.80, about 4% away. ADX has dropped to 19 — the trend is maturing. The trade is managing itself.

**HYPE SHORT @ $43.28 → $44.37 (-$4.47, -5.04%)** ⚠️

A valid signal fighting the tape. Entry was clean: bearish MACD crossover, histogram expanding negative, ADX 29 (trending). The market simply went the other way. Stop at $45.76 — if it hits, so be it. This is what stops are for. The losing trades teach you the most.

### Andean Wallet — $520 equity, +$20.82 PnL

**BTC LONG @ $72,862 → $75,255 (+$20.82, +9.85%)** 🚀

The star of the portfolio. Open since April 11th — six days now. This trade went through hell: dropped to -8% within 48 hours, testing my thesis. The original stop at $70,280 never triggered. The bot held.

Why? Two reasons:
1. **Wide stops** — 2.5× ATR means real volatility tolerance
2. **No monitor goal** — I disabled the position monitor after it killed profitable trades too early. No one was watching to panic-sell at -8%.

Now it's up almost 10%. The chart shows BTC breaking $77K, well above the UHL cloud. Original thesis confirmed: pullback in uptrend, Andean crossover, ride the trend.

### VWAP Wallet — $885 equity, 0 positions

Market's been trending for two weeks (ADX 20-50). Mean-reversion doesn't trade trending markets. The bot halts every single run. NOT_RANGING. NOT_RANGING. NOT_RANGING.

This is boring, but boring is profitable. No forced trades, no losses.

**Week's P&L:** +$29.82 realized, +$29.82 unrealized = **+$59.64 (~2.4%)**

The numbers are small because position sizing is conservative (1% risk per trade). Scale comes later, after the system proves itself over months, not days.

What Changed: Phase 1 Gates

The biggest architectural improvement this week was restructuring how my MACD bot handles pre-trade checks.

Previously, the bot would fetch 100 candles of 4H data (~13,000 tokens, ~5 credits), then check if there was room for a new position. If the wallet already had 2 positions open, those 5 credits were wasted — the bot would halt on MAX_POSITIONS after already spending the expensive part.

The fix was embarrassingly obvious: check the cheap stuff first.

Before (V4.0):

1. Fetch candles (expensive) → 2. Check positions (cheap) → 3. Score and trade

After (V4.5):

1. Check account + positions (cheap) → 2. If capacity exists, fetch candles → 3. Score and trade

This is “Phase 1 gates” — the bot runs two quick API calls to verify balance and position count before committing to the expensive candle fetch. If Phase 1 fails, the run costs ~4 credits and halts immediately. If Phase 1 passes, it proceeds to Phase 2 (candle fetch and scoring) knowing the trade is at least possible.

The savings are significant. Run #72 caught a valid TAO crossover but halted on MAX_POSITIONS — under the old architecture, that would have cost 11+ credits. Under Phase 1 gates, it costs 4.

The Collateral Filter Trap

Here’s a subtlety that took me a debugging session to understand.

cod3x has a new “Collateral Requirement” filter — you can set a goal to only run when collateral usage is below a threshold. I set mine to < 90%, thinking this would prevent duplicate position attempts.

It doesn’t work the way I expected.

The filter checks total wallet collateral, not per-asset positions. With my MACD bot trading 5 assets (BTC, ETH, SOL, TAO, HYPE) from one wallet, having a HYPE position open uses maybe 20% collateral. The filter sees 20% < 90% and lets the goal run. The bot then spends 4 credits discovering “oh, HYPE position already exists” and halts on DUPLICATE.

The lesson: Collateral filters are coarse pre-filters, not precise duplicate prevention. They’re useful for blocking MAX_POSITIONS (3 positions ≈ 60% margin), but for per-asset duplicate detection, you need logic inside the goal.

The Phase 1 gate catches this at ~4 credits. Without it, the cost would be ~11 credits. Platform constraints mean this is the optimal solution — there’s no per-asset filter in cod3x.

Stealing From Black-Scholes: Volatility Regime Scoring

My favorite addition this week came from thinking about implied volatility.

Options traders know that IV (implied volatility) expanding versus contracting tells you something about market regime independent of direction. High IV means big moves expected. Low IV means consolidation expected. The classic Black-Scholes insight: volatility isn’t constant, and knowing whether it’s expanding or contracting gives you edge.

I don’t trade options, but I can measure realized volatility expansion using data I already fetch: ATR (Average True Range).

The signal is simple:

• ATR_recent = average ATR of last 7 candles

• ATR_baseline = average ATR of last 20 candles

• vol_expansion = ATR_recent / ATR_baseline

If vol_expansion > 1.15, volatility is expanding. If < 0.85, it’s contracting.

How I use it:

For MACD (momentum strategy): Expanding volatility is good — trends need volatility to run. Add +2 points to the score when vol_expansion > 1.15.

For VWAP (mean reversion strategy): Contracting volatility is good — mean reversion works best in quiet, ranging markets. Add +2 points when vol_expansion < 0.85.

For Andean (pullback strategy): Expanding volatility means bigger position risk, so I reduce size by 0.85x in contracting conditions.

This costs nothing extra — the ATR values are already in my candle fetch. Zero additional API calls, meaningful signal improvement.

The Borderline Zone Fix

My VWAP bot uses ADX < 20 as the “ranging market” filter. But I kept seeing runs where ADX was 20.5 or 19.8 — right on the boundary — and the bot would spend 8+ credits running full analysis before halting on a low score.

The fix was adding a “borderline zone”:

• ADX < 18 → Ranging, proceed to scoring

• ADX 18-22 → Borderline, halt immediately (ambiguous regime)

• ADX ≥ 22 → Trending, halt immediately (MACD territory)

Run #136 had ADX = 20.58. Under the old logic, it ran full analysis (8.9 credits) before scoring too low to trade. Under the borderline zone logic, it would halt immediately (~3 credits).

Small optimization, big cumulative savings over hundreds of runs.

The Journal Tag Bug

One more fix, because this is how vibecoding actually works — you ship something, it breaks in a new way, you fix it.

Run #77 showed my MACD bot failing twice on the same journal entry:

Error: expected array, received string → at tags

The CreateJournalEntryTool expects tags as a JSON array: tags=["macd-hunter","4h-macd"]. The LLM was passing them as a string: tags="macd-hunter,4h-macd". Subtle difference, complete failure.

The fix was adding one explicit rule to every goal:

CreateJournalEntryTool tags MUST be JSON array: tags=["a","b"] NOT tags="a,b"

The LLM knows the difference between arrays and strings. It just needs to be reminded which one to use. That’s the nature of probabilistic systems — sometimes the model picks the wrong format, and your job is to make the right format obvious.

What Three Weeks of Live Trading Taught Me

The bots have been running autonomously for three weeks now. Here’s what I’ve learned:

1. Halting is the most valuable feature.

The majority of runs are halts. No crossover. Wrong regime. Duplicate position. Below threshold. Each halt is the system correctly identifying “this is not a trade.” In a week where BTC moved from $70K to $84K and back to $74K, my mean reversion bot fired maybe twice. The MACD bot caught the trend. The Andean bot caught pullbacks. The system as a whole deployed capital when appropriate and sat out when not.

2. Credit costs are manageable with good architecture.

Daily cost across all three strategies: €3-7 depending on market activity. Phase 1 gates, borderline zones, and collateral filters combine to minimize wasted analysis. The expensive runs are the ones that execute trades — which is exactly right.

3. The losing trades teach you the most.

The HYPE short is approaching its stop loss. Entry was clean: bearish MACD crossover, histogram expanding, ADX 29 (trending). The market simply went the other way. This is the reality of systematic trading — you take valid setups and accept that some percentage will lose. Risk management (1% per trade, hard stop losses) ensures losers don’t blow up the account.

4. Iteration never stops.

Version numbers this week: VWAP V8.7, MACD V4.6, Andean V2.5. Each version fixed something discovered in the previous version. The prompts I’m sharing below will probably have V8.8 and V4.7 by next week. That’s not a bug — that’s the process.

The Complete Prompts (Paid Subscribers)

Below is what you’re actually paying for: the complete, copy-paste-ready goal prompts for all three strategies. These are the exact prompts running on my production bots right now.

Each prompt includes:

• Strategy identity and wallet configuration

• Hard gates and scoring systems

• Position sizing and risk parameters

• The FABRICATION DETECTOR safety net

• Tool call sequencing and output formatting

I’m sharing these for two reasons:

1. Transparency. It’s easy to talk about “AI trading bots” in the abstract. Here’s the actual implementation.

2. Learning acceleration. When I started, I would have paid good money to see a working prompt from someone ahead of me on the curve. Reverse-engineering from first principles is valuable, but sometimes you just need a reference implementation.

Feel free to use these as templates, modify them for your own strategies, or just study the patterns. The architecture decisions — Phase 1 gates, scored signals, compact output, tools-first execution — translate to any strategy you want to build.

What’s Next

The HYPE short will either hit its stop loss or turn around. Either way, I’ll learn something.

The BTC long on the Andean bot is approaching the question every trend trader faces: when do you move your stop to breakeven? I’m considering adding a “breakeven after TP1” rule to the Andean strategy — once the first take-profit hits, move the stop loss to entry price. Locks in profit, lets the remainder run risk-free.

And the iteration continues. V8.8. V4.7. V2.6. Each version a little better than the last.

That’s vibecoding. That’s the process. That’s why I’m still here.

Strategy 1: VWAP Mean Reversion (1H Timeframe)

What it does: Buys oversold dips and sells overbought rallies when the market is ranging (ADX < 18). Uses daily VWAP as the mean, with RSI and SMA20 as confirmation.

When it trades: Low volatility, ranging conditions. BTC acting as an anchor (ETH and SOL only trade when BTC isn’t moving more than 1.5%).

Key features:

• Borderline ADX zone (18-22) halts immediately

• Volatility regime scoring (+2 for contracting volatility)

• 5x leverage, 1.5% risk per trade

• Dual direction scoring (long and short evaluated each run, higher score wins)

VWAP HUNTER V8.7 — BTC

# 1H VWAP HUNTER V8.7 — BTC
# Strategy Config V7 | Prompt V8.7
Wallet: 0x2ae3...c379
ASSET: BTC (hardcoded — this goal ONLY trades BTC)
MODE: VALIDATE + SCORE + EXECUTE in single run.
REASONING: Direct — simple gate logic, no complex chains.

[... FULL PROMPT CONTINUES ...]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HARD RULES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RANGING only (ADX < 18) | BORDERLINE (18-22) halts immediately | Score >= 7 to execute
NEVER bundle SL/TP with createOrder | Never average down
Max 3 positions | Always COMPLETE GOAL on failure
Daily loss 3% → stop | 48H max hold | Funding > 0.05% → block
Volume check uses PRIOR COMPLETED candle (candles[-2])
Scoring always uses ratios, never raw prices
CreateJournalEntryTool tags MUST be JSON array: tags=["a","b"] NOT tags="a,b"

[Full prompt: 2,400 words — see complete version in subscriber download]

Strategy 2: MACD Momentum (4H Timeframe)

What it does: Catches trend breakouts and continuations using MACD crossovers with multi-factor scoring. Hard gate on ADX ≥ 20 ensures it only trades trending markets.

When it trades: Trending conditions with confirmed momentum. Requires both a fresh MACD crossover AND sufficient score from independent signals.

Key features:

• Phase 1 gates (check positions before expensive candle fetch)

• Weighted scoring from hedge fund alpha-combo framework

• BTC correlation gate for ETH/SOL (+2 points available)

• Volatility regime scoring (+2 for expanding volatility)

• 2-3x leverage depending on asset, 1% risk per trade

MACD HUNTER V4.6 — BTC

# 4H MACD HUNTER V4.6 — BTC
# Strategy Config V4 | Prompt V4.6
Wallet: 0x9Be2...CDA
ASSET: BTC (hardcoded — this goal ONLY trades BTC)
MODE: VALIDATE + EXECUTE in single run.
REASONING: ReAct — Think → Act → Observe loop. Never Graph of Thought.

[... FULL PROMPT CONTINUES ...]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 1 — CHEAP GATES (FIRST)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Immediately fire (no text output first):
GetHLAccountTool wallet=0x9Be2...CDA
GetHLPositionsTool wallet=0x9Be2...CDA

ReadMemory for returned keys.

Gate A: balance >= $100
Gate B: no BTC position exists (else → HALT "DUPLICATE")
Gate C: total positions < 3 (else → HALT "MAX_POSITIONS")

If ANY gate fails → journal + COMPLETE GOAL. Do NOT proceed to Phase 2.

[Full prompt: 2,800 words — see complete version in subscriber download]

Strategy 3: Andean Pullback (30M Timeframe)

What it does: Catches pullback completions within established trends. Uses the Andean Oscillator for crossover detection and UHL MA cloud for trend filtering.

When it trades: When a trending market pulls back and then resumes. UHL green = longs only, UHL red = shorts only.

Key features:

• 551-candle fetch (500 warmup for UHL + 51 working)

• Session filtering (09:00-22:59 UTC only)

• Dual take-profit (50% at 1R, 50% at 2R)

• Volatility-adjusted sizing (contracting vol = 0.85x size)

• 3x leverage, 1% risk per trade

ANDEAN HUNTER V2.5 — BTC

# ANDEAN HUNTER V2.5 — BTC
# Strategy Config V1 | Prompt V2.5
Wallet: 0x574E...D173
ASSET: BTC (hardcoded — this goal ONLY trades BTC)
MODE: VALIDATE + EXECUTE in single run.
REASONING: ReAct. ReadMemory MUST NOT be banned (53K token candle data).

[... FULL PROMPT CONTINUES ...]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FABRICATION DETECTOR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Before any final output, check: do you see actual tool results in your context?
If you see ZERO tool results or your context shows no ReadMemory output, you have
fabricated everything. Output ONLY: "FABRICATION_DETECTED | HALT | 0 tool results"
and COMPLETE GOAL immediately.

[Full prompt: 3,100 words — see complete version in subscriber download]

Complete Prompt Package via DM

For paid subscribers, I’ve compiled all three strategies into a single downloadable package. Drop me a dm in substack/twitter/discord and I’ll send you:

Included:

• VWAP HUNTER V8.7 (BTC, ETH, SOL) — 3 complete prompts

• MACD HUNTER V4.6 (BTC, ETH, SOL, TAO, HYPE) — 5 complete prompts

• ANDEAN HUNTER V2.5 (BTC, ETH, SOL) — 3 complete prompts

• Trading configuration summary (leverage, risk, thresholds)

• Trigger configuration guide (how to set up chart triggers in cod3x)

A Note on Using These Prompts

These prompts work for me. They may not work for you without modification.

Specifically:

• Wallet addresses need to be replaced with your own

• Risk parameters (1%, 1.5%) should match your risk tolerance

• Leverage (3x, 5x) should match your experience level

• Asset selection should match assets you understand

The architecture patterns — Phase 1 gates, scored signals, FABRICATION DETECTOR, compact output — are universal. The specific parameters are personal.

Start with one asset on one strategy. Run it in test mode until you understand every line of the run log. Then gradually expand.

The bots are patient. They halt more than they trade. That’s a feature.

Questions about the prompts? Something not working the way you expected? Drop a comment or find me in the cod3x Discord. For paid subscribers, I’ll do my best to help debug specific issues with these strategies.

Disclaimer: These prompts are shared for educational purposes. Trading crypto with autonomous bots is risky. These bots have been running for three weeks and have both winning and losing positions. Past performance doesn’t guarantee future results. Use proper risk management. Don’t trade money you can’t afford to lose.

This one is about what happens when they don’t — and what I stole from a hedge fund textbook to make them smarter.

The Phantom Trade

Let me tell you about Run #31.

My Andean bot triggered on BTC. The run log showed a perfect execution: session check passed, account balance verified, position size calculated, order placed at $84,177 with a stop loss and dual take-profit. The journal entry was filed. The compact output line was clean.

One problem: none of it happened.

Zero tool calls. Zero working memory. Zero iterations. The AI model — the same one that had been reliably fetching data and making decisions for weeks — wrote a complete, internally consistent trade report without touching a single API. The balance was fabricated. The price was fabricated. The indicator values were fabricated. The journal entry claiming it logged the trade? Also fabricated.

I only caught it because the run dashboard showed “Tool Calls: 0” next to “Achievement Score: 100/100.” The platform thought the bot did great. The bot thought it did great. Only the tool count told the truth.

This is the most dangerous failure mode in autonomous AI trading. Not a wrong signal. Not a bad fill. A hallucination so complete that every internal check passes — because the checks are hallucinated too.

Why This Happens (And Why Prompt Engineering Can’t Fully Fix It)

Here’s the mechanism. The cod3x platform closes a goal when the model produces a “final response.” The model’s plan for what it’s going to do next counts as a final response. So when the model writes “I’ll now execute the following tool calls...” — that text IS the final output. The goal closes. No tools fire.

The model then has a choice: admit it has no data, or fill in the blanks from context clues. Turns out, the trigger event that fires the goal contains stale indicator values. The model reads those, runs the math, and produces a beautiful report from data it was supposed to fetch fresh but never did.

I tried everything to fix this at the prompt level:

• “MUST be a tool call” → model acknowledges the rule, then writes tool calls as text anyway

• “Any text before tool calls = goal failure” → model writes “I understand” and then produces text

• “TRIGGER PAYLOAD VALUES MUST NOT BE USED” → model explicitly says “I must not use these values” and then uses them

Instruction-level fixes don’t reliably prevent this because it’s a stochastic problem. The model sometimes fires tools correctly and sometimes writes text first. It’s like telling someone “always remember to lock the door” — they’ll do it 90% of the time, but the 10% is where the trouble lives.

The Structural Fix: Tools First, Think Later

The fix that actually worked wasn’t an instruction. It was a structural change.

Instead of:

1. Check session time (text output) → 2. Fetch data (tool calls) → 3. Analyze

I flipped it to:

1. Fetch data (tool calls, absolute first action) → 2. Check session time (using fetched data) → 3. Analyze

The trade-off is that off-session runs now waste about 0.7 credits fetching data they’ll never use. But a wasted credit is infinitely cheaper than a phantom trade.

This eliminated the text-before-tools gap where the model could produce a final response before any tool fires. The very first token the model outputs is a tool invocation, not text.

The Safety Net: One Line That Saves Everything

Even with the structural fix, I couldn’t be 100% certain the model would always fire tools first. So I added a safety net — one instruction that catches phantoms after the fact:

FABRICATION DETECTOR: Before producing final output, check your context.
If you see ZERO tool results in your conversation history, you have
fabricated everything. Output ONLY: "FABRICATION_DETECTED | HALT"
and COMPLETE GOAL immediately.

On Run #101, my VWAP bot hit the phantom pattern again — zero tool calls, tool invocation written as text. But this time, instead of fabricating a complete market analysis, the model caught itself:

FABRICATION_DETECTED | HALT | 0 tool results

Clean halt. 1.07 credits. No fake data. No phantom trade. The underlying problem (text before tools) wasn’t fixed — but the damage was completely prevented.

Compare that to Run #31 (no detector): fabricated balance, fabricated prices, fabricated journal entry, fake trade execution with internally consistent math. The FABRICATION DETECTOR doesn’t prevent the hallucination — it prevents the consequences.

I’ve now added this to all three strategies. It’s the cheapest insurance I’ve ever bought.

Stealing From Hedge Funds: Why 50 Weak Signals Beat One Strong One

While debugging phantom trades, I stumbled across a research paper that changed how I think about signal design: Kakushadze and Serur’s “151 Trading Strategies” — a 361-page academic catalog of every systematic trading approach across every asset class, complete with 550+ mathematical formulas.

The key insight isn’t any single strategy. It’s the alpha combination framework described in Section 3.20. The idea, formalized as the Fundamental Law of Active Management:

IR = IC × √N

Your edge (Information Ratio) equals your average signal accuracy (Information Coefficient) times the square root of the number of independent signals you’re combining.

Translation: combining 50 signals that are each slightly right beats finding one signal that’s very right. This is why hedge funds employ hundreds of researchers building hundreds of signals rather than searching for the one perfect indicator.

Here’s what hit me: my MACD bot was doing the opposite. It had seven entry conditions, and ALL of them had to pass. MACD crossover, histogram increasing, RSI in range, price above SMA50, volume confirmation, daily trend alignment, ADX trending. Miss any single one and the trade is rejected.

That’s not signal combination. That’s signal multiplication. Every additional condition makes it exponentially harder to enter, even when six out of seven conditions are screaming “trade this.”

From AND-Gates to Scored Signals

The fix was converting from binary gates to a weighted scoring system — the same principle, just simplified for an LLM to execute reliably.

Before (V3.9): All seven conditions must pass → trade or halt. Binary.

After (V4.0): Two conditions are hard gates (must pass, non-negotiable). The remaining five become scored signals with weighted points.

The hard gates are the ones where the strategy fundamentally doesn’t work without them:

• ADX ≥ 20 (MACD is meaningless in ranging markets)

• MACD crossover within 2 candles (this IS the signal — without it, there’s nothing to trade)

Everything else gets scored:

SignalPointsWhy This WeightHistogram momentum0–3Measures acceleration — most independent signalRSI positioning0–3Different dimension entirely (overbought/oversold)Price vs SMA500–2Confirming signal, partially correlated with MACDVolume confirmation0–2Confirming signalDaily trend alignment0–2Broader context checkADX strength bonus0–1Mild independent contribution

Maximum 11 points (BTC) or 13 (ETH/SOL, which include a BTC cross-market check). Trade threshold: 6 or 7 points.

The weights aren’t arbitrary. They follow the alpha combo principle: signals that measure genuinely independent things (histogram acceleration vs RSI level) get more weight than signals that partially overlap with conditions already captured (SMA50 trend vs MACD direction).

The First Scored Trade

Run #49. TAO. The scoring system’s first real test.

Hard gates passed: ADX 28.72 (trending), MACD bearish crossover confirmed.

Then the scoring:

• Histogram accelerating rapidly: +3

• RSI at 51.36, right in the short sweet spot: +3

• Price above SMA50 (misaligned for short): 0

• Volume adequate: +1

• Daily trend misaligned: 0

• ADX bonus: 0

Total: 7/11. Above threshold. SHORT.

Under the old system, this trade gets rejected. “Daily close above daily SMA50” fails the daily alignment check. Hard stop. Go home.

Under the scoring system, the bot recognized that powerful histogram acceleration and perfect RSI positioning provide enough conviction to enter, even without daily alignment confirmation. Two strong independent signals outweighed three absent ones.

That’s the Fundamental Law at work. The trade doesn’t need every signal to agree. It needs enough independent information to exceed the conviction threshold.

The Platform Setting That Changed Everything

Here’s a plot twist I didn’t see coming. After all the prompt engineering — the phantom fixes, the scoring system, the fabrication detector — the single biggest improvement came from unchecking a box.

cod3x has an optimization setting called “Skip Step Completion Assessment.” The description says it “saves credits by skipping step completion assessment which uses the LLM to verify step completion and control retry logic for failed steps.” Sounds reasonable. I had it enabled for weeks.

Turns out, this setting was causing most of my mid-plan completions.

Here’s why: when the model writes “I need to call ReadMemory next” as text instead of actually calling ReadMemory, the step completion assessment is supposed to catch that and say “wait, this step isn’t actually done — the model wrote a plan instead of executing it.” Then it gives the model another iteration to try again. With the assessment skipped, the platform just accepted the text output as complete and moved on. Goal closed. 1-2 iterations max.

The moment I disabled it, runs went from 1-2 iterations to 3+ iterations. Run #106 — the first run after the change — was a revelation:

BTC: $71,934 | ADX=19.26 | BELOW_THRESHOLD (LONG=1, SHORT=1)

ADX below 20. For the first time in weeks, BTC entered a ranging market. The VWAP bot didn’t just detect it — it went through the entire execution path. Candle fetch → ReadMemory → position check → account balance → funding rate → daily VWAP fetch → ReadMemory again → score both directions → halt below threshold. Seven tool calls. Three iterations. Every step fired correctly.

The scores were low (1/12 for both long and short — BTC sitting right at SMA20 with neutral RSI, no VWAP deviation) so no trade executed. But the path worked. The architecture that I’d been building for weeks finally ran end to end. One checkbox made the difference.

The lesson: when your AI agent keeps stopping mid-execution, the problem might not be your prompts. Check your platform settings. The optimization that “saves credits” might be the one preventing your bot from finishing its job.

What Didn’t Work (Honestly)

Not everything was progress. In the interest of keeping it real:

The MACD scored trade never actually executed. Run #53 scored a TAO SHORT at exactly the minimum threshold (6/11) — with a warning about oversold RSI at 25.46. All the data was real, the scoring was correct, but the model wrote “Execution: SHORT 0.2 TAO” as text in its reflection instead of calling PlaceOrderTool. I checked HyperLiquid: zero TAO positions, zero order history. This is a new phantom variant — not fabricated data (the FABRICATION DETECTOR can’t catch it because real tool results exist), but fabricated execution. The model had all the right information and still described the trade instead of doing it.

Andean truncation is still a problem. My 551-candle fetch produces ~53,000 tokens of data. When the model reads this from memory, the platform truncates it, cutting off the last few candles — which are exactly the ones I need for crossover detection. The bot correctly halts instead of fabricating (good), but it can’t actually validate the signal (frustrating). At 5.6 credits per truncated halt, this needs a better solution.

The phantom pattern is platform-wide. I initially thought the phantom problem was unique to the Andean bot’s complex multi-tool startup. Then my VWAP bot — with a much simpler single-tool start — produced the exact same failure. The FABRICATION DETECTOR catches all of them, but the underlying cause (text-before-tools) appears to be fundamental to how LLMs interact with the cod3x execution model. You can’t eliminate it — you can only catch it.

The System Right Now

Three months in. Three strategies. Hundreds of runs logged. Here’s where things stand:

The market briefly entered ranging territory (ADX 19.26) before bouncing back to trending (ADX 25.59 two runs later). The VWAP bot ran its complete scoring path for the first time and correctly determined that the setup wasn’t strong enough. When the next ranging window opens with actual price displacement from VWAP, that bot should score above the threshold and attempt its first trade.

My credit balance is holding at ~4,000 credits. At roughly 1-2 credits per halt and Qwen 3.5 Plus as the model, daily operating cost stays around €3-5.

Four Lessons for Builders

1. Safety nets matter more than perfect prompts. You will never make an LLM behave deterministically. The FABRICATION DETECTOR cost me 30 seconds to write and has caught five phantom attempts. Build your system assuming the model will occasionally do the wrong thing, and design catches for when it does.

2. The research is already done — you just need to translate it. The alpha combo framework has been in institutional use for decades. I didn’t invent weighted signal scoring — I read Section 3.20 of an academic paper and adapted it for an LLM to execute. The 151 Trading Strategies paper is free on SSRN. The hard part isn’t finding the ideas. It’s implementing them within the constraints of your platform.

3. Check your platform settings before blaming your prompts. I spent weeks prompt-engineering around mid-plan completions. The real fix was unchecking “Skip Step Completion Assessment.” One platform setting was silently preventing the model from getting enough iterations to complete its job. Before you rewrite your prompt for the fifteenth time, check whether the platform is giving your agent the room it needs to work.

4. Read your run logs like your money depends on it. Because it does. Every improvement in this post — the phantom detection, the scoring system, the settings discovery — came from reading a run log, noticing something wrong, and tracing it back to a root cause. The model tells you exactly what it’s thinking. Your job is to listen.

The system keeps running. BTC is back to trending. The VWAP bot waits for ADX to drop below 20 again. The MACD bot scores signals but still needs more iterations to actually place orders. The Andean bot fires real tools but can’t read its own data. Nothing is perfect and everything is making progress.

Questions? Find me in the cod3x Discord. And if you’ve solved the 53K-token truncation problem or found other platform settings that make agents work better, I genuinely want to hear about it.

Disclaimer: Not financial advice. Autonomous trading bots can and will lose money. My system has been running for three months and is primarily an expert at halting, which may be its best feature. Always use proper risk management and never trade with money you can’t afford to lose.

It’s been working. The BTC SHORT from that post hit +14%. The architecture is solid. But there was a gap in the system that kept bugging me.

What happens during pullbacks within a trend?

The MACD bot catches the initial trend breakout. The mean reversion bot waits for ranging conditions. But when a trending market pulls back temporarily — a dip within an uptrend, a bounce within a downtrend — neither bot is looking. The MACD bot wants a fresh crossover. The mean reversion bot sees ADX above 20 and halts.

Enter the Andean Oscillator.

Wait, What’s an Andean Oscillator?

Yeah, I had to look this one up too. The Andean Oscillator is a lesser-known indicator that separates price action into bullish and bearish components. Instead of a single line like RSI, it gives you two curves — one measuring bullish energy, one measuring bearish energy. When they cross, it signals a directional shift.

The key insight: in a trending market, when the counter-trend component briefly surges and then gets overtaken by the trend component again, that’s a pullback completing. The trend is resuming.

I paired it with two other indicators I’d never used before:

• UHL MA — a 100-period adaptive moving average that signals “bullish” or “bearish” trend direction. This is my trend filter. Bullish signal = only take longs. Bearish signal = only take shorts.

• Grover Llorens — a momentum confirmation indicator. Think of it as a second opinion on whether the pullback is actually done.

All three need to agree before the bot enters. Andean crossover + UHL trend alignment + Grover confirmation = trade.

The 30-Minute Edge

While my other bots run on 1-hour and 4-hour timeframes, the Andean bot operates on 30-minute candles. Faster timeframe means more opportunities but also more noise, so I dialed down the risk:

• 1.0% risk per trade (vs 1.5% for the VWAP bot)

• 4x leverage (vs 5x for mean reversion)

• Session filtering — the bot only trades between 09:00 and 23:00 UTC, with a reduced size multiplier during off-peak hours

• Dual take-profit — 50% of the position closes at 1R, the other 50% rides to 2R

The dual TP structure is new for my setup. My other bots use a single take-profit. But on 30-minute timeframes, price can reverse fast after hitting the first target. Taking half off the table at 1R locks in profit while letting the remainder capture larger moves. And because these are limit orders placed at entry, the position self-manages — no monitor goal needed for Andean. The orders sit on the exchange and fire automatically.

The Indicator Discovery Problem

Here’s where things got interesting — and where I learned something important about building bots with exotic indicators on cod3x.

Not all indicators that appear in the chart trigger builder are available through the candle data API. The platform gives you two ways to use indicators:

1. Chart triggers — fire your goal when an indicator condition is met

2. Candle snapshot tool — fetch indicator values inside your goal for validation

Most common indicators (RSI, MACD, SMA, ADX) work in both. But some exotic ones only work as triggers. Grover Llorens, for example, can trigger a goal when it signals BUY or SELL, but if you ask the candle API for its values, you get 0% data coverage. It simply doesn’t return data.

I spent a debugging session figuring this out. The first version of my Andean bot tried to fetch Grover data inside the goal — and kept getting empty results. The fix is to not use it inside the goal at all. If the AND-group requires Grover to signal BUY before the goal fires, then by definition Grover has signaled BUY when the goal runs. No need to re-check. The trigger does the filtering; the goal does the execution.

The pattern: Use exotic indicators in your trigger configuration (where they work), and use queryable indicators in your goal prompt (where you can actually read the values). Let the trigger act as a pre-filter, let the goal validate and execute.

The UHL MA Name Mystery

Another discovery: the UHL MA indicator has a different internal name than what you’d expect. I initially requested it as "uhl_ma" in my candle fetch. The API happily returned data — with 0% indicator coverage. No error. Just silent empty values.

The correct name is "uhl_cts". The API silently converts indicator names to camelCase internally, and if the name doesn’t match exactly, you get nothing back. No error message. No warning.

Lesson learned: Always check the indicatorCoverage field in your candle API response. If it shows 0%, your indicator name is wrong — even if the call “succeeded.” The same issue applies to the Andean Oscillator itself: the response field is andeanOscillator_50.bull and andeanOscillator_50.bear, not any of the intuitive aliases you might try.

Also worth noting: UHL MA requires a long warmup period — 500+ candles — before it produces valid output. On a 30-minute timeframe that’s over 10 days of history. I had to fetch 551 candles per run (500 warmup + 51 working) to get reliable coverage. That’s a lot of data, and the platform stores it in working memory rather than returning it inline — which means the bot needs to call ReadMemory to access it after the fetch. Learned that the hard way too.

When Your Bot Hallucinates Data

This one caught me off guard. On one of the early runs, the bot logged a journal entry with specific UHL and Grover values — numbers that looked perfectly plausible. But those indicators had returned 0% coverage in the actual tool response. The AI model had fabricated the values.

This is a known behavior with LLMs: when they expect data to be there but it isn’t, they’ll sometimes generate plausible-looking values rather than saying “I don’t have this data.” In a research context, that’s annoying. In a trading context, it’s dangerous — you could enter a trade based on fabricated indicator readings.

The fix is a simple guard in the prompt:

Journal content must only report values actually returned by tool calls 
in this run. Never infer, assume, or estimate indicator values not present 
in candle data. If an indicator returned 0% coverage, write "UNAVAILABLE".

One line. Problem solved. But it’s the kind of thing you only discover by reading your logs carefully.

The “Silent Failure” Problem

Here’s a subtle one that cost me a few credits before I caught it.

On some runs, my bots would complete in under 30 seconds with zero tool calls, score a perfect 100/100, and log nothing useful. The final output would contain the tool call I expected — written out as plain text, not actually executed.

What was happening: the model was entering its “final response” phase and describing what it was about to do rather than doing it. The platform sees a completed response, closes the run, charges credits. No analysis happened.

The fix was changing how the START instruction is written. Instead of prose (”Call GetHLCandleSnapshotTool immediately”), I now use a pre-filled invocation template that looks like an actual tool call:

START — FIRST ACTION ONLY:
TOOL CALL: GetHLCandleSnapshotTool
coin=ETH interval=1h numCandles=50
[...parameters...]
DO NOT output any text before this tool call executes and returns data.

A template gives the model a concrete next action to execute rather than describe.

The Parallel Pre-Fetch Problem

Once the START instruction fix was in place, a new pattern emerged: the model would correctly make one tool call in the first iteration, but then bundle five or six tool calls simultaneously in the second — fetching candles, account balance, positions, funding rates and daily data all at once before reading any of it.

On a clean trending-market run where all gates pass, this is slightly wasteful but harmless. On a ranging-market run where the first thing you’d discover is ADX < 20 (a halt condition that takes zero additional data), you’ve just wasted 4-5 unnecessary tool calls and the credits to match.

The fix is an explicit sequential execution instruction at the very top of the prompt, before anything else:

⚠️ SEQUENTIAL EXECUTION — ONE STEP AT A TIME:
Complete each step fully before planning the next.
Step 1 (candle fetch + ReadMemory) must complete before ANY other tool call.
Do NOT pre-fetch account, positions, or funding in Step 1.

Moving this instruction to the top — not buried in a boundaries block — is what makes it stick. The model plans its first few steps during the reasoning phase before any tools run, so the constraint needs to land before that planning happens.

Version Control for Prompt Engineering

Here’s something I’ve started doing that I wish I’d done from day one: treating goal prompts like software versions.

Each of my goals has two text fields in cod3x:

• A title (shown in the UI list)

• A description (the actual prompt that executes)

Early on, I was putting version numbers in both. After a few rounds of iteration, the title field would show V3.1 while the description had been quietly updated to V3.3. When something went wrong, I couldn’t tell at a glance which version was actually running.

The fix: version numbers live in the description only, as the first line of the prompt. The title is a static, human-readable name — "4H MACD HUNTER — TAO", nothing more. When you’re managing 12 goals across 3 strategies and 3 assets, this small discipline saves real confusion.

I also keep a separate version table tracking two distinct things:

• Strategy config version — the trading logic (regime filter, scoring, risk params). This only changes when the strategy itself changes.

• Prompt version — the structure and instructions of the goal text. This changes more frequently, as you refine how you communicate the strategy to the model.

A prompt can change (better sequential execution instructions, tighter compact output rules) without the underlying strategy changing at all. Keeping these two tracks separate means you can iterate on prompt quality without implying the strategy has changed — which matters when you’re evaluating performance over time.

Making Three Bots Play Nice

With three strategies now running, coordination matters. Here’s how they fit together:

Different agents, complementary regimes:

BotTimeframeWhen It TradesWhat It CatchesVWAP Mean Reversion1HADX < 20 (ranging)Oversold bounces, overbought reversalsMACD Momentum4HADX ≥ 20 (trending)Trend breakouts, continuation signalsAndean Pullback30MUHL bullish/bearish + crossoverDips within uptrends, bounces within downtrends

The VWAP and MACD bots share a wallet and explicitly divide the market regime between them. The Andean bot runs on its own separate wallet, targeting a completely different signal type. Three wallets, three strategies, three timeframes — none of them competing for the same entry.

Position management is deliberately simple. All three bots set SL and TP at entry and leave them alone. The VWAP and MACD monitors check every 4 hours but only close positions that have been open too long (48H) or where the market regime has flipped against the trade. No breakeven adjustments, no trailing stops — those added complexity and were prematurely closing good positions. The Andean bot doesn’t have a monitor at all: the dual TP limit orders sit on the exchange and fire automatically.

The Prompt Refinements That Made Everything Cheaper

Between compact output, the START template, sequential execution instructions, and early-exit guards on regime failures, a typical HALT run now costs 1.0–1.6 credits and completes in under a minute. A full EXECUTE run — regime check, gates, scoring, position sizing, order placement, SL/TP — came in at 1.65 credits last week. Six weeks ago, the equivalent run cost 22 credits across 16 iterations. Same strategy logic, dramatically different efficiency.

The biggest single win was the early-exit guards. When a regime check fails (ADX out of range), that’s a definitive halt — there’s no reason to fetch daily candles, account balance, funding rates, or anything else. Adding explicit “HALT IS FINAL — no further tool calls” instructions after each halt condition cut wasted fetches on the most common run outcome.

Current Status: Three Bots, Three Timeframes

As I write this, the system is running:

• 9 HUNTER goals (3 assets × 3 strategies) — each fires on its own trigger conditions

• 2 MONITOR goals — one for VWAP positions (every 4H), one for MACD positions (every 4H)

• 18 trigger groups — 6 per strategy, each with AND-conditions combining indicator signals

Total daily credit cost in ranging markets: roughly €3–5. In trending markets: roughly €4–7. The Andean bot is still in its early validation phase, so I’m watching the run logs closely.

The next step is expanding to more assets — XRP and DOGE for the MACD bot, and AI-sector tokens like TAO and RENDER once the current momentum frenzy settles down.

What I’d Tell Someone Starting Today

If my first post was about the fundamentals — architecture, platform quirks, execution rules — this one is about the iteration process. Every improvement I’ve described came from reading run logs, spotting inefficiencies, and fixing them one prompt revision at a time.

The four things that accelerated my learning the most:

1. Read your run logs — including the graph state. Not just the summary, the actual reasoning traces and tool call sequences. The graph state shows you exactly what the model decided at each step, what it called in parallel, and what it fetched but never read. Run #19 revealed the parallel pre-fetch problem by showing 5 simultaneous tool calls in a single action block. You can’t see that from the summary.

2. Version control your prompts. Version numbers in the description only, static names in the title. Track strategy config versions separately from prompt versions. When something breaks, you want to know exactly which version was running and what changed since the last good run.

3. Start conservative, then loosen. The Andean bot runs at 1.0% risk while I validate it. Once I have a week of clean runs and understand the win rate, I can consider raising it. Starting tight and expanding is much less painful than starting aggressive and getting stopped out.

4. The cod3x community is genuinely helpful. The Discord has been invaluable for understanding platform-specific behaviors. When you’re vibecoding at the intersection of AI and DeFi, having people who’ve solved similar problems before is worth more than any documentation.

The system isn’t perfect. Triggers still occasionally fire when they shouldn’t. The AI still sometimes decides to pre-fetch six things when it only needed one. And every new indicator brings its own naming quirks and data availability surprises.

But it runs. Autonomously. 24/7. Three strategies, three timeframes, three different market conditions covered. And it keeps getting better with every iteration.

That’s the beauty of vibecoding — the barrier to entry is a clear idea and the willingness to iterate. The AI handles the rest.

Building trading agents on cod3x? I’d love to hear what you’re working on. Drop me a note or find me in the cod3x Discord.

If you liked this content, also make sure to check out Aarons’s Substack !

Disclaimer: This is not financial advice. I’m sharing my experience for educational purposes. Crypto trading is risky, autonomous agents can lose money, and exotic indicators with cool names don’t guarantee profits. Always use proper risk management.

Today, I have two complementary strategies running 24/7: a mean reversion bot for ranging markets and a MACD momentum bot for trending markets. They switch automatically based on market regime. My BTC SHORT recently hit +14%. The whole system runs without me touching it.

This post is everything I learned along the way. Not theory — practical, hard-won lessons from building, testing, breaking, and rebuilding these agents through 100+ prompt iterations. If you’re starting your own vibecoding journey on cod3x, this should save you a lot of trial and error.

What Is Vibecoding a Trading Bot?

If you haven’t tried cod3x yet, here’s the concept: you write a trading strategy in plain English (a “goal prompt”), pick an AI model to run it, set up chart-based triggers, and the platform handles everything else — fetching market data, executing trades on HyperLiquid, managing positions.

No Python. No JavaScript. No APIs to wrangle. You describe what you want the bot to do, and the AI figures out how to do it using the trading tools available on the platform.

It sounds almost too easy. And honestly, getting a basic bot running IS easy. Getting one that’s reliable, cost-efficient, and doesn’t do weird things at 3 AM — that’s where the learning curve lives.

The Architecture That Works: One Goal Per Asset

I tried several architectures before landing on what works. My first attempt used a three-goal pipeline: SCOUT (analyze the market) → EXECUTE (place the trade) → MONITOR (manage positions). It was elegant on paper.

In practice, the single biggest improvement was collapsing SCOUT and EXECUTE into one unified “HUNTER” goal per asset. One goal that validates the market regime, scores the setup, and executes the trade — all in a single run.

Why this works better:

• No handoff complexity. When two goals need to communicate, you need a reliable way to pass data between them. With one goal, there’s nothing to pass.

• Cheaper per cycle. One goal run instead of two means one credit charge instead of two.

• Simpler to debug. Everything that happened is in one run log.

I now have a BTC HUNTER, an ETH HUNTER, and a SOL HUNTER — each completely self-contained, hardcoded to its asset, triggered by its own chart conditions.

The takeaway: Start with the simplest architecture that works. You can always add complexity later. A single well-crafted goal beats an elaborate multi-goal pipeline that’s harder to maintain.

The Regime Switcher: Two Strategies, One Wallet

The market isn’t always trending. It isn’t always ranging. My favorite insight from this journey: you don’t need one strategy that works in all conditions — you need two strategies that know when to sit out.

I use ADX (Average Directional Index) as the regime switch:

• ADX < 20 → Ranging market → Mean reversion strategy (buy oversold dips, sell overbought rallies near VWAP)

• ADX ≥ 20 → Trending market → MACD momentum strategy (follow the trend with confirmed crossovers)

Both run on separate cod3x agents sharing the same HyperLiquid wallet. Each strategy’s HUNTER goals check ADX first and halt immediately if the regime doesn’t match. The transition is automatic.

This means most of the time, one strategy is actively trading while the other is quietly halting — which is exactly what you want. The cost of a HALT run is just 5-6 credits, so the “wrong regime” strategy costs almost nothing while waiting for its conditions to return.

Prompt Engineering: What Actually Matters

Here’s where vibecoding gets interesting. The AI model running your goal is incredibly capable, but it needs clear guardrails to stay focused. Through 100+ iterations, I’ve found these patterns make the biggest difference:

Give It Clear Boundaries

The most impactful addition to my prompts was a “STRICT BOUNDARIES” block at the top of every goal. Without it, the AI might decide to investigate existing positions when it should just be scoring new setups, or produce elaborate analysis plans when a simple halt-and-log would do.

Something like:

Your ONLY job: check regime → gates → score → execute or halt.
Do NOT investigate existing position health.
If you reach a HALT condition, log and complete immediately.

This keeps runs fast, cheap, and predictable. A well-bounded HALT run costs 5-6 credits and completes in 3 iterations.

Be Explicit About the Math

One subtle lesson: when your scoring system uses ratios (like price/VWAP), tell the model to compute and write out the ratio before comparing it to thresholds. Without this, the model might compare raw prices instead of ratios, which produces different (wrong) results. A simple “compute vwap_ratio = CLOSE / VWAP_D and write it out before scoring” prevents this entirely.

Chain of Thought, Always

cod3x offers different reasoning modes. Chain of Thought (linear, step-by-step) is the right choice for trading goals. The alternative, Graph of Thought, can parallelize steps — which sounds efficient until it parallelizes your order execution and places three orders simultaneously for the same position. Chain of Thought processes steps sequentially, which is exactly what you want for trading.

The Execution Rule That Matters Most

This one took me a while to figure out, and it’s worth highlighting because it applies to everyone trading on HyperLiquid through cod3x:

Always place your order first, then add stop-loss and take-profit as a separate step.

Don’t bundle SL/TP with the order creation. Instead:

1. Create the order (no SL/TP attached)

2. Wait a couple seconds, verify the position exists

3. Then add SL/TP as a separate call

This two-step approach is more reliable and prevents edge cases where orders get partially created. Every goal prompt in my system includes this instruction.

Tips That Saved Me Credits

Running AI agents costs credits, and those add up. Here’s what brought my daily costs down significantly:

Check the cheapest filter first. If your strategy only works in ranging markets (ADX < 20), check ADX before fetching positions, balance, funding rates, or scoring data. If the regime is wrong, halt immediately — one tool call, one iteration, done.

Skip unnecessary logging. My position monitor runs every 4 hours. Most of the time, all positions are healthy and no action is needed. Writing a journal entry that says “everything’s fine” costs extra credits. I only log when the monitor actually takes an action (closing a position, adjusting stops).

Cap your iterations. I use 6 max iterations for HUNTER goals and 4 for MONITOR goals. This prevents the AI from over-thinking or going on tangents.

Verify your model selection. cod3x has both per-goal and global model settings. Make sure they match — I once ran an expensive model on every goal because the global setting was overriding my per-goal choice.

What a Successful Trade Looks Like

Here’s a recent one that shows the system working as designed:

SOL SHORT — Score 6, Ranging Market

• The SOL HUNTER triggered, checked ADX (17.63 — ranging, good)

• Scored the setup: price 1.37% above daily VWAP (+3 points), near SMA20 (+1), wick rejection at resistance (+2) = 6 points, meeting the threshold

• Sized the position: $12.90 risk (1.5% of balance), 5x leverage, 4% stop

• Placed the order, waited, verified, added SL/TP separately

• Logged everything to the trading journal

• Total cost: ~13 credits, 7 iterations, 8 minutes

The whole process was autonomous. I saw it in the journal the next morning.

And my current BTC SHORT, entered at $70,919, is sitting at +14% with the take-profit at $66,718 in reach. The position monitor checks it every 4 hours, confirms the regime is still appropriate, and lets it run.

The Learning Curve Is the Product

If I’m honest, the most valuable thing I’ve built isn’t the trading bot itself — it’s the knowledge of how to build, debug, and iterate on AI agents. Every prompt iteration taught me something about how LLMs reason, where they go off-script, and how to guide them back.

The cod3x platform makes this accessible to non-developers. The Discord community is genuinely helpful — I’ve gotten architecture advice that saved me days of trial and error. And the iteration cycle is fast: change a prompt, run it, check the log, refine. You don’t need to compile anything or manage infrastructure.

If you’re considering building your own trading agent, my advice:

1. Start with one asset, one strategy, one goal. Get it halting correctly before you try to make it trade.

2. Read your run logs obsessively. The AI tells you exactly what it’s doing and why. This is where you learn.

3. Keep prompts short and bounded. The AI performs better with clear constraints than with elaborate instructions.

4. Expect to iterate. My prompts went through 100+ versions. Each one was an improvement. That’s the process.

5. Join the cod3x Discord. The community knowledge there is invaluable. Shoutout to the whole team for building a platform that makes this possible.

What’s Next

I’m currently expanding to AI-sector tokens (TAO, RENDER, FET) on the MACD momentum side — the decentralized AI narrative is creating interesting trading opportunities. I’m also A/B testing natural language prompts versus explicit tool-name prompts to see if shorter prompts can reduce costs without sacrificing accuracy.

The goal is a portfolio of regime-aware agents across 8-10 assets, each running independently, each knowing exactly when to trade and when to sit out. Two months in, the foundation is solid. The journey continues.

If you’re building trading agents on cod3x and have questions, or if you’ve discovered platform quirks I haven’t covered, I’d love to hear about it.

The cod3x Discord has been invaluable for debugging — shoutout to St3v3n Vinyl and the whole cod3x team for the architecture advice and subduing my constant nagging for bug fixes.

If you liked this content, also make sure to check out !

Disclaimer: This is not financial advice. I’m sharing my experience building trading bots for educational purposes. Crypto trading is risky, and autonomous agents can lose money faster than you can hit the pause button. My account started at $1,000 and has survived mostly because the bots halt more often than they trade — which, honestly, might be the most important feature.