Building an LLM Strategy That Monitors X (Twitter) Feeds

What if your trading bot could read a tweet, weigh it against current market conditions, and decide — on its own — whether it's worth a trade? That's the idea behind this strategy: an LLM-powered bot that monitors Elon Musk's X (Twitter) feed, cross-references it with live BTC/ETH/FLOKI prices, and only acts when a post is both relevant and significant.

This post walks through exactly how it works, piece by piece, using the real production prompt as the reference.

The full working strategy from this tutorial is available here: Elon Musk Feed Momentum

---

The Core Idea

Instead of manually refreshing a timeline hoping to catch the next market-moving post, the strategy runs on a fixed interval (e.g. every 30 minutes) and does three things every single time it executes:

1. Reads the tweet feed for anything new
2. Checks it against live prices to see if the market has already reacted
3. Manages any existing position before even considering a new one

The tweet is never the whole decision — it's one input evaluated alongside price action and prior context.

---

Step 1: Turning a Twitter Feed Into Structured Data

Raw HTML scraping is fragile and unnecessary here. The strategy uses RSS.app to convert an X account into a clean JSON feed, pulled in with a single template call:

{{toon: {{get:https://rss.app/feeds/v1.1/myh5cEW1qUo9H6zv.json}} }}

The {{get:...}} fetches the raw feed; wrapping it in {{toon:...}} compresses that JSON into a more token-efficient format before it ever reaches the model. The LLM receives structured posts — no parsing, no guesswork.

Step 2: Pairing the Tweet With Live Market Data

A tweet alone tells you sentiment, not opportunity. So every run also pulls current prices for the three tracked assets:

BTCUSDT: {{price:binance:spot:btcusdt}}
ETHUSDT: {{price:binance:spot:ethusdt}}
FLOKIUSDT: {{price:gateio:spot:flokiusdt}}

This matters more than it might seem. Consider two scenarios with the same tweet:

• Tweet: "Bitcoin will become part of our future financial system." BTC has already moved +15% in the last 24h. → Market likely already priced this in. Low-confidence, no trade.
• Same tweet, but BTC has been flat. → Fresh information, real edge. Higher-confidence candidate for a LONG.

The price data is what lets the model tell the difference between "old news" and "an actual catalyst."

Step 3: Never Trading the Same Tweet Twice

Without memory, a strategy re-reading the same feed every 30 minutes would see the same tweet repeatedly and could fire duplicate trades. This is solved with two fields in persistent storage:

"last_seen_tweet_id": "189456789",
"processed_tweet_ids": ["189456789", "189456700", "189456650"]

Before analyzing anything, the model checks: is this tweet ID already in the list? If yes, skip it — permanently. This turns the strategy from something that reacts to a rolling feed into something that reacts to discrete events, each handled exactly once.

Step 4: Confidence Scoring, Not Blind Reaction

Not every tweet deserves a trade — arguably, almost none do. The strategy scores each new post's relevance and market impact on a 1–10 scale, and only acts above a threshold:

{{val:min_confidence=7}}

A few examples of how that plays out:

Tweet	Confidence	Outcome
"Tesla will start accepting Bitcoin payments again."	9/10	Open LONG BTC
"Great day today."	1/10	No trade
"Something interesting is coming soon."	5/10	Monitor only, no trade

That threshold is the single biggest lever against noise. Lower it, and the bot trades on almost anything vaguely crypto-adjacent. Raise it, and it waits for genuinely high-signal posts.

Step 5: Managing the Position Before Looking at New Tweets

Position management always runs first, every cycle — before any new tweet is even considered. The rules:

{{val:take_profit_pct=1.5}}
{{val:stop_loss_pct=1.0}}
{{val:trail_lock_pct=0.5}}

• Close if profit hits +1.5%
• Close if loss hits -1.0%
• If profit ever peaked and has since pulled back 0.5% from that peak, lock it in and exit — the trailing-lock

That third rule is worth pausing on. Without it, a position that ran up +1.4% and then reversed could ride all the way down to the stop-loss, turning a near-win into a loss. The strategy tracks a peak_pnl_pct value in storage specifically so it always remembers the best the trade ever looked, not just where it stands right now.

And critically: while a position is open, no new trades are considered at all. One position at a time, full stop.

Step 6: A Storage Schema That Actually Persists

This is the part that's easy to get wrong — and worth calling out for anyone building their own version. It's not enough to describe what should be remembered; the model needs to actually see the current state and be explicitly told to save the full object back every run.

The storage object carries everything the strategy needs to stay coherent across cycles:

{
  "last_seen_tweet_id": null,
  "processed_tweet_ids": [],
  "position": {
    "open": false,
    "symbol": null,
    "direction": null,
    "entry_price": null,
    "entry_time": null,
    "trigger_tweet_id": null,
    "reason": null,
    "peak_pnl_pct": 0
  },
  "trade_log": [],
  "monitoring_notes": ""
}

A few design choices here matter more than they look:

• trade_log is append-only. Nothing is ever deleted, so the bot (and you) can always see the full decision history — what was traded, when, and why.
• trigger_tweet_id is stored on every trade, linking each position directly back to the post that caused it. That traceability is what makes the strategy auditable after the fact instead of a black box.
• The full storage state is shown directly in the prompt — not just referenced — so the model is reading its own memory before making any decision, not guessing at it.

The Full Execution Sequence

Every run, in order:

1. Load storage — read the last known state in full
2. Manage any open position — check P&L, apply take-profit/stop-loss/trail-lock
3. Fetch the latest tweets — pull the feed
4. Filter for new, unprocessed posts — skip anything already seen
5. Score relevance and confidence — decide if anything clears the bar
6. Execute — LONG, SHORT, EXIT, or no action
7. Save the complete updated state — tweets processed, position status, trade log, notes

That last step is non-negotiable. If the model updates its reasoning but never writes it back to storage, the next run starts from scratch — no memory of the position, no record of which tweets were already handled, and a real risk of duplicate trades.

Where This Can Go From Here

Once the core loop is solid, the same pattern extends naturally:

• Multiple accounts — compare a founder's account against an exchange's or a news outlet's before deciding
• News APIs — layer in breaking-news feeds as a second event source alongside social posts
• On-chain data — combine whale-wallet movement with sentiment and price action for a fuller picture

The Takeaway

What makes this strategy work isn't any single clever rule — it's the combination of five things working together: an external event feed, LLM interpretation of that event, a confidence filter to cut out noise, persistent memory so nothing repeats, and disciplined position management that runs independently of whatever new information shows up. Strip out any one piece — say, the dedup logic or the trailing-lock — and the whole thing gets noticeably less reliable.

It's a good template for a broader pattern: LLM strategies that react not just to price charts, but to real-world events happening around them.