A real system, running today on the same server as this website. This is an engineering story, not investment advice - nothing here is a recommendation to buy or sell anything.
The most interesting thing about our AI trading research system is not the AI. It is the scaffolding that assumes the AI will be wrong - because sometimes it is - and makes wrong cheap.
What it actually is
Three pieces on one Linux box:
- A portfolio tracker (Ghostfolio, open source, self-hosted) - the boring, reliable ledger of what is actually held.
- An AI research layer - local and API language models that write morning briefings, research notes on watchlist symbols, and a daily "market weather" read (dollar, rates, volatility, gold → risk-on / risk-off / mixed).
- An autonomous paper trader - an agent that manages simulated pots by rules, so strategy ideas can be tested with fake money and real discipline.
The GPU is a second-hand Tesla V100 - an ex-datacentre card you can buy for the price of a mid-range gaming GPU. It runs the local models; heavier research calls go to cheap API models through a self-hosted router, so a full month of AI research costs pennies.
The guardrails are the product
Everything below exists because we assume every layer will eventually fail or hallucinate:
Paper first, gates before promotion. No strategy touches real money on a good backtest alone. It needs a minimum number of real (non-housekeeping) closed trades in the forward log, and an unreadable trade journal fails closed - if the system cannot prove what happened, the answer is no.
Intent journaling. Before the agent places any order it writes an INTENT record; afterwards it reconciles the outcome or VOIDs it. The night a data feed served us a NaN price at 00:30, the order failed, the reconcile contained it, and the morning log showed exactly what happened and why. Root cause fixed the same day (never price from the latest row; use the last finite close). Design for the bad night, because the bad night comes.
Honest uncertainty. When input data is missing, the market-weather module outputs UNKNOWN - not its best guess. An AI system that is never allowed to say "I don't know" will lie to you on schedule.
Signals must earn their place. We built a detector for unusual off-exchange volume. Before it was allowed to influence anything, we replayed its exact live code over three years of history: the edge was positive but not statistically proven (p ≈ 0.11). So it is journalled as context-only - every flag logged, no trading path reads it - until the forward evidence earns it a promotion. Most retail systems do this backwards: trade first, validate never.
Adversarial review as routine. One AI builds; a different model audits. One audit round found three high-severity issues - a crash window in a spend cap, a path-sanitisation hole, and a stored-XSS vector via external data displayed on the dashboard. All fixed with regression tests, and the test suite grew from 101 to well over 180 along the way. A second model does not share the first model's blind spots; that is the entire trick.
Running models on one mid-sized GPU
A 32 GB card sounds big until three services want it at once. What works:
- A VRAM proxy in front of the model server, so callers queue instead of colliding.
- Sequential, not parallel, agents for heavy jobs.
- Local models for interactive questions; API models for long research runs.
- One patch we must re-apply after every library upgrade - pinned in the operating manual, because "I'll remember" is not a system.
The homelab economics
The server draws about 126 watts - roughly £14–23 a month in electricity. For that you get a research desk that reads filings, writes briefings, watches risk conditions, and tests strategies around the clock. Whether the strategies make money is a separate, harder question the gates exist to answer honestly. The infrastructure, though, pays for itself in saved subscription fees alone.
Steal this checklist
- Separate the ledger of truth (portfolio tracker) from the layer of opinions (AI research). Never let opinions write to the ledger directly.
- Paper-trade with real discipline: journal intent before action, reconcile after.
- Make every component allowed to say UNKNOWN, and make unreadable state fail closed.
- Backtest the exact live code, not a reimplementation - then keep a forward log, because backtests flatter.
- Have a second model audit the first. Budget for fixing what it finds.
- Write the operating manual as you go, including the gotchas you will otherwise re-discover quarterly.
Again: engineering story, not advice. The system's most valuable output so far isn't a trade - it's a habit of demanding evidence.
Tried it? Improved it?
Tell the forum what worked and what didn’t: real experience beats recommendations, and the best answers get folded back into this guide with credit.
Related guides
Launch day, with a brain that rehearses disasters
The site went public today. This is the honest half of the story: the graveyard of finished-but-unshipped projects, fear dressed as engineering, and how making every disaster boring did what courage never could.
6 min read
What you actually buy when you buy a domain name
This week the site got its name. A plain-language tour of domains and DNS: the internet's phone book, why you rent a name rather than own it, what the dots mean, and why the name is worth more than the machine.
6 min read