Open-Source-Toolkit prüft Copy-Trader vor dem Kopieren mit Claude Code
Wer einen Trader kopiert, erhält nicht automatisch dessen Ergebnisse. Ein neues Open-Source-Toolkit auf Basis von Claude Code soll Copy-Trader vorab auf seine Verlässlichkeit prüfen.

Signup Write New Story I Built a Claude Code Toolkit That Checks Copy Traders Before You Copy Them by Ben Ryan by Ben Ryan | @ benryan Copy trader and developer. I publish my real results, losses included, and the tools I use to pick traders. Open source at github.com/benryandev
Copy trader and developer. I publish my real results, losses included, and the tools I use to pick traders. Open source at github.com/benryandev
Disclosure: I use Strike Finance for copy trading, hold its token, and earn referral fees from Strike. I'm not affiliated with Strike. This article has no referral links, and the toolkit is free and MIT-licensed.
Copy trading sounds simple. Find a good trader, copy them, get their results.
I've done it with my own money every day since late August, and the copy is never the same trade:
The week of 5 October showed how much this matters. The trader I copy lost about 4% of their account. My copy of them lost about 28%.
Strike Finance is a perpetual futures exchange. Perpetual futures, or "perps", are leveraged bets on a price with no expiry date. Strike can copy any Hyperliquid wallet by address. Hyperliquid's positions and trades are public, so any wallet can be copied, and the trader doesn't have to sign up.
That makes choosing the trader the whole game. The usual tool for it, a leaderboard, answers the wrong question. It shows the trader's whole account. A copier only gets their perps trades on the markets Strike lists, after fees.
This week, someone in a trading Discord recommended a wallet with over $20M of all-time profit. On the markets a copier could actually follow, it was down about $3M since July.
It's a folder on your computer. There's no server and no tracking. It talks only to Strike's and Hyperliquid's public APIs, plus GitHub to check for updates and Strike's published API spec.
The most useful design choice was keeping the AI out of the arithmetic. Claude picks the right script, reads its output, and explains it. Every number comes from a script, so it can be checked and it comes out the same each time.
Strike's API uses a key pair: a private key that signs requests and a public key that Strike stores. Strike's website can create one for you, but then the private key sits in your browser, and you'd have to paste it into the tool.
Instead, the toolkit creates the key pair on your computer and shows you only the public half, which you paste into Strike yourself. The private key is saved in a hidden file only your user account can read, and it's never printed.
Each request is signed locally, like this:
message = METHOD:path:timestamp:nonce:sha256(body) headers: X-API-Wallet-Public-Key, X-API-Wallet-Signature, X-API-Wallet-Timestamp, X-API-Wallet-Nonce
The exchange adds two more limits: Strike's API keys can trade but can't withdraw, and you can set an expiry date. The toolkit suggests 90 days.
A small lesson from building it: Strike's published spec gave one header a different name from the one the server accepts. Only a live test found it. I now treat every spec as a claim to check, and the weekly review watches for spec changes.
The toolkit can change only four kinds of things:
Before any change, Claude shows the exact request, marked "DRY RUN: nothing sent", and explains it in a line. Then it offers four choices: make this change, skip it, explain more, or stop. None is marked as recommended.
That's slower than letting an AI act on its own, and that's the point. When money is involved, a person should see each change first.
Every change that goes through is also written to a local log, with the values before and after, in a folder outside the toolkit so updates never touch it. "Show my recent changes" reads it back. When something looks wrong a week later, the first question is always "what did I change?", and the log answers it.
A sweep checks about 5,000 Hyperliquid wallets that Strike already scores, plus Strike's own traders, in 20–30 minutes. A wide sweep covers Hyperliquid's whole leaderboard, about 45,000 wallets, in about an hour.
Each filter is there because skipping it cost me money:
If nobody passes, it says so. No trader is better than a bad trader.
The key question isn't "what did the trader make?" but "what would I have made?"
The replay rebuilds the trader's trades from Hyperliquid's API and copies them the way Strike would: your amount per trade, your leverage, your limits, and excluded markets. When the trader closes part of a position, the copy closes the same share.
Open positions are valued at hourly prices, and every copied close is assumed to land 0.10% worse than the trader's, to allow for delay. It also checks every hourly high and low against Strike's margin rules, so a copy that would have been liquidated counts as liquidated.
I checked it against my real account. Over two weeks, the replay put the worst drop at −$577. The real figure was −$586. That's close enough to compare settings, though not to predict profit.
It compares the two ways Strike sizes copies:
The winner is the one with the most profit per dollar of its biggest drop, over 90 and 30 days. If the two are within 10%, the smaller drop wins, because it's easier to sit through. If both lose money, it recommends neither.
It runs the whole comparison at 10x, 5x, 3x and 2x leverage and picks one per trader. An earlier version suggested 10x without modelling liquidations at all, and a copy with more leverage than the trader's own gets liquidated on moves the trader rides out.
On 26 October I ran it on the trader I copy myself, at 10x: a $7,000 account, up to half of it in copies, the last 90 days.
At 10x, fixed margin had the biggest drop and 27 liquidations, for less than half the profit of 5x. The verdict was "neither": no leverage passed, and at 2x, the safest tested, both modes lost money over the last 30 days. My own setting failed my own check. That's the check doing its job, and it's why setup now starts at 5x.
The same replay also tests limits on how much a copy can hold, side by side.
The hardest part wasn't the code. Strike changes fast.
On 12 October, it changed what happens when a copied trader is liquidated: your copy now closes too, where before it stayed open with nothing behind it. A day later, API routes that had refused my key started working.
So the weekly review does more than report profit. It checks for a newer version of the toolkit and for spec changes, and it flags anything that needs a decision:
If nothing needs attention, it says so in one line.
A separate risk check asks what a sudden move would do to the open book: price shocks of 5%, 10%, and 20%, the weekend gap on stock and gold positions (their prices can jump between Friday's close and Monday's open, against the worst of the last 12 weekends), and copies holding opposite sides of the same market.
When a copy is close to liquidation, the fix is one request: "Add $50 margin to my BTC position", which shows the new liquidation price before you say yes. Adding margin moves the liquidation price away, but it also puts more money into that one position.
The toolkit is free on GitHub: github.com/benryandev/strike-copilot. It isn't financial advice, and it can't turn a bad trader into a good one. What it does is turn choosing a trader, a sizing mode, leverage, and limits into decisions based on numbers. A longer setup guide, skill by skill, is on X.