Ausi-Trader

The problem

Most retail trading systems die one of two deaths. They're backtest fantasies that never survive live fills, or they're live cowboys with no statistical evidence behind them.

I wanted to hold both bars at once: strategies discovered by automated research, promoted only through hard out-of-sample validation, and executed live with institutional-style risk controls. And I wanted the judgment calls — is this regime tradeable, does this edge make sense, should this strategy stay live — handled by something smarter than a threshold in a config file.

The build

Ausi-Trader is a multi-agent system built on Python 3.12 and asyncio. Agents run concurrently: data ingestion, strategy research, risk, execution, and monitoring, each doing one job and talking over a shared event loop. Live market data comes from Databento; live orders route through Interactive Brokers over ib-async.

The heart of it is the strategy gauntlet. A candidate strategy has to clear, in order: a full backtest, walk-forward analysis, Monte Carlo permutation testing to prove the edge isn't luck, then a stretch of paper trading. Only after all four does it earn real capital — and if it decays in production, the system auto-demotes it back down the ladder. Promotion is earned; demotion is automatic.

Regime detection decides when to trade, and a congressional-trade tracker feeds the research agents an extra signal. Every decision, fill, and position lands in a SQLite ledger, and two aiohttp dashboards show the system's state in real time.

Stack decisions

Why Claude in the loop. The mechanical parts of trading are easy to code; the judgment parts aren't. I use the Claude API — Sonnet for the high-volume research passes, Opus for the calls that matter — to evaluate strategy candidates, read regime context, and make the qualitative research judgments that would otherwise be a pile of brittle heuristics. This is the part I point to when a startup asks whether I actually know how to build on Claude: I've had it making decisions with money attached.

Why asyncio over threads. Trading is I/O-bound — waiting on market data, waiting on the broker. A single event loop keeps the whole system coherent and debuggable, with no lock soup.

Why SQLite. One operator, one machine, append-heavy writes. A server database would be ceremony. SQLite is the ledger, and it's never been the bottleneck.

Outcomes

The system runs autonomously and executes live on Interactive Brokers today. It's roughly 148,000 lines across 240-odd files, under active daily development. More than a trading result, it's the proof behind the rest of this site: I build serious, tested software, and I build it with AI — not as a gimmick, but as a component I trust with the hard calls.