Claudeto handle BTC and ETH, and the results have been a fascinating study in prompt engineering versus quantitative ML.
The core problem with using a single LLM for trading is "reasoning shallowing." If you feed one mega-prompt with technical indicators, sentiment, and portfolio data, the model tends to over-weight the most recent piece of information. To fix this, I moved to a decoupled multi-agent pipeline.
The Architecture: 4-Hour Decision Cycles #
The system operates on a strict 4-hour loop. Instead of one prompt, it triggers a sequence of specialized agents and a quantitative ensemble. Here is the data flow:
-
Data Aggregation: The bot pulls 20+ technical indicators (RSI, MACD, VWAP, Ichimoku), derivatives data (funding rates, open interest, long/short ratios), and the Fear & Greed Index.
-
Parallel Analysis:
-
Agent A (Market Analyst): Purely technical. It looks at the charts and the numbers.
-
Agent B (Sentiment Analyst): Purely contextual. It processes news, on-chain whale flows, and macro data (DXY, S&P 500).
-
The Synthesis: A third agent, the Decision Maker, receives the reports from A and B, plus a prediction from a separate ML ensemble trained on historical candles.
-
Risk Layer: A hard-coded Python layer calculates position sizing and checks "circuit breakers" (e.g., if volatility exceeds a specific ATR threshold, the trade is blocked regardless of the AI's confidence).
Technical Implementation & Config #
To keep the agents from drifting, I use a strict JSON output format. If the LLM returns a conversational response instead of a schema, the system rejects it and retries.
Here is a simplified example of the DecisionMaker
prompt structure I use to force structured reasoning:
{
"analysis_input": {
"technical_report": "Bullish divergence on 4H, RSI 62",
"sentiment_report": "Mixed, whale accumulation detected on-chain",
"ml_prediction": "Upward trend probability: 64%",
"portfolio_state": "30% BTC, 70% USDT"
},
"required_output_format": {
"action": "BUY | SELL | HOLD",
"confidence_score": "0.0-1.0",
"reasoning": "string",
"stop_loss_pct": "float"
}
}
For the deployment, I'm running this on a VPS with a Next.js dashboard for visualization and a Telegram bot for manual approvals. The tech stack is:
LLM: Claude 3.5 Sonnet (best balance of reasoning and speed for this)Database: MySQL (to log every prompt and response for backtesting)Backend: Node.js / PythonExchange: Binance Testnet (Paper trading)
Claude vs. Quantitative ML: The "Second Opinion" #
One of the most interesting parts of this build is the tension between the Claude agents and the ML ensemble. I noticed that Claude is excellent at identifying "regime changes" (e.g., noticing that a news event has invalidated a technical support level), whereas the ML model is better at spotting repetitive price patterns.
Claude's Strength: Contextual synthesis. It can tell mewhya funding rate spike is dangerous.ML's Strength: Statistical probability. It doesn't care about the "narrative," only the candles.
When the two disagree, the Risk Management layer defaults to "HOLD." This has saved the bot from several "fake-out" breakouts in my testnet runs.
Current Benchmarks & Lessons #
I'm currently running this in a paper-trading environment. The engineering is solid, but the profitability is a work in progress. The biggest hurdle isn't the AI's ability to predict price, but the "slippage" and "fee" calculations that often eat the margins of 4-hour trades.
A specific bug I hit: Claude would occasionally suggest a stop-loss that was too tight for the current ATR (Average True Range), leading to getting stopped out by noise before the actual move happened. I fixed this by adding a volatility_buffer
variable to the prompt, forcing the agent to reference the current ATR before setting the stop-loss price.
npm run bot:sync-market-data -- --force-refresh
This setup transforms the LLM from a "chatbot" into a reasoning engine within a larger deterministic system. By stripping the AI of the power to actually execute trades—and instead making it a "recommendation engine" filtered through a risk layer—the system becomes significantly more reliable.
Next Multi-Agent AI Safety: Why Model Isolation is No Longer Enough →