Using the Claude API to Generate Trading Signals: A Practical Walkthrough

LLMs aren't good at predicting price. They're not faster than markets, they don't have access to non-public data, and their outputs are non-deterministic in ways that don't suit pure quantitative trading. Anyone who tells you they have an "AI trading model that beats the market" is selling something.

What LLMs are good at: reading unstructured information — news, filings, social posts, transcripts, narrative — and producing structured signals from it. That's the actual use case.

This article walks through using the Claude API to do exactly that: take a stream of qualitative inputs, produce a structured trading signal, hand it to deterministic execution code.

What this is and isn't

This is **not**: an LLM running a self-directed trading account.

This **is**: a pipeline where the LLM acts as an intelligent parser. It takes inputs like the past 24 hours of crypto news, recent X posts about a token, or a SpaceX press release, and returns a structured JSON object describing what kind of signal (if any) those inputs contain. The signal then gets fed into a deterministic strategy that decides whether to act.

The separation matters. The LLM has discretion over reading and interpreting; deterministic code has the final say on whether to place an order.

The pipeline

Five components:

1. **Data collector** — pulls news headlines, X posts, exchange announcements on a schedule

2. **Prompt builder** — formats the inputs into a Claude API request with a clear schema

3. **API caller** — sends to Anthropic, handles errors and rate limits

4. **Signal validator** — checks the LLM output meets the expected JSON schema

5. **Strategy adapter** — converts the signal into actual order parameters

The first and last are domain-specific; the middle three are reusable across signal types.

A working implementation

import os
import json
import anthropic

client = anthropic.Anthropic(api_key=os.getenv('ANTHROPIC_API_KEY'))

SIGNAL_PROMPT = """You're analyzing crypto market news for trading signals. Given the inputs below, return a JSON object with the following schema:

{
  "signal_type": "bullish" | "bearish" | "neutral",
  "strength": 0.0 to 1.0,
  "time_horizon_hours": integer,
  "confidence": 0.0 to 1.0,
  "key_drivers": [list of short strings],
  "risks": [list of short strings]
}

Important constraints:
- Output ONLY valid JSON, no other text
- 'strength' is your assessment of how big a move this news could drive
- 'confidence' is how sure you are about the signal direction
- If the news is ambiguous or neutral, set signal_type to "neutral" and confidence < 0.4
- Never invent information not in the inputs

INPUTS:
{inputs}
"""

def get_signal(news_items, symbol):
    inputs_text = "\n".join(f"- {item}" for item in news_items)
    
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=500,
        messages=[{
            "role": "user",
            "content": SIGNAL_PROMPT.format(inputs=inputs_text)
        }]
    )
    
    text = response.content[0].text.strip()
    
    try:
        signal = json.loads(text)
    except json.JSONDecodeError:
        return None
    
    # Schema validation
    required = ['signal_type', 'strength', 'time_horizon_hours', 'confidence']
    if not all(k in signal for k in required):
        return None
    
    if signal['signal_type'] not in ('bullish', 'bearish', 'neutral'):
        return None
    
    if not 0 <= signal['strength'] <= 1 or not 0 <= signal['confidence'] <= 1:
        return None
    
    return signal

The strict JSON schema and validation matter. LLMs occasionally add a friendly preamble ("Sure, here's the JSON: ...") that breaks downstream parsing. Validation catches these.

Connecting to execution

The LLM produces signals; deterministic code decides whether to act:

import ccxt

exchange = ccxt.lmex({'apiKey': '...', 'secret': '...'})

def maybe_trade(signal, symbol='BTC-PERP', account_value=10000):
    # Hard filters
    if signal['signal_type'] == 'neutral':
        return None
    if signal['confidence'] < 0.6:
        return None  # too uncertain
    if signal['strength'] < 0.5:
        return None  # too weak
    
    # Position sizing scales with confidence × strength
    risk_pct = 0.003 * signal['confidence'] * signal['strength']
    risk_dollars = account_value * risk_pct
    
    ticker = exchange.fetch_ticker(symbol)
    current_price = ticker['last']
    
    # 2% stop distance as default
    stop_distance = 0.02
    qty = risk_dollars / (current_price * stop_distance)
    qty = float(exchange.amount_to_precision(symbol, qty))
    
    side = 'buy' if signal['signal_type'] == 'bullish' else 'sell'
    
    # Place market order
    order = exchange.create_order(symbol, 'market', side, qty)
    
    # Set hard stop based on signal time horizon
    exit_side = 'sell' if side == 'buy' else 'buy'
    stop_price = current_price * (1 - stop_distance) if side == 'buy' else current_price * (1 + stop_distance)
    exchange.create_order(
        symbol, 'stop', exit_side, qty, None,
        {'stopPrice': stop_price, 'reduceOnly': True}
    )
    
    return order

The hard filters are the safety layer. Even if the LLM hallucinates a confident bullish signal from neutral news, the deterministic checks reject signals below the confidence threshold. The position sizing scales smoothly with the LLM's stated confidence.

Costs

A realistic monthly bill for this kind of pipeline:

The cost-to-edge ratio depends entirely on whether the signals actually inform profitable trades. \$25/month is trivial if the bot adds 5% annual return; it's expensive if the LLM signals are no better than coin flips.

Where this falls apart

The honest list of failure modes:

**Hallucination on edge cases.** The LLM occasionally invents details from inputs it doesn't quite understand. Strict schema validation catches structural hallucinations; semantic hallucinations are harder. Mitigation: include "never invent information not in the inputs" in the prompt, and cross-check key claims against the original sources before trading.

**Latency.** Each API call adds 1-5 seconds. For event-driven strategies where speed matters, this latency can erase the edge. Use LLMs for medium-frequency signals (hourly, not sub-minute) where the analysis quality matters more than raw speed.

**Non-determinism.** Run the same prompt twice with the same inputs, get slightly different signals. This is a feature for chat applications and a bug for trading systems. Mitigation: set `temperature=0` in the API call (or as close as the model supports) and average multiple runs for high-stakes decisions.

**Prompt brittleness.** Small wording changes can shift signal distribution meaningfully. Treat the prompt as a critical configuration file — version it, test changes against historical inputs before deploying, monitor signal distribution for drift after updates.

**Over-reliance on the model.** The temptation is to feed more and more context until the LLM is making most of the strategic decisions. Resist this. The model is a parser; deterministic code is the strategy. Keep the boundary clean.

Frequently Asked Questions

Q: Which Claude model should I use?

Sonnet for the main signal generation — best balance of cost and reasoning quality. Haiku for cheap routing or filtering. Opus for periodic deep analysis where cost is less of a factor. Mix them in a tiered architecture.

Q: How much edge can this realistically add?

For most retail traders, modest — maybe 1-3% additional annual return when integrated well with a base strategy. The edge is greater for traders who don't already follow news closely. For algo-only strategies that ignore news, even a small news layer can meaningfully reduce drawdowns around major events.

Q: Is this allowed by exchange ToS?

Yes, on every major exchange including LMEX. Algorithmic trading is explicitly supported. The LLM is just generating signals — orders still go through standard API endpoints with rate limits.

Q: Should I open-source the prompts?

Probably not the production prompts (they're part of the edge). The general approach and schemas are fine to share. Use any examples from public papers or open-source projects as a starting point, then iterate privately.

Related Articles