06-reference/research

alpaca paper trading harness library comparison

2026-05-22·research-brief·source: deep-research·! medium
investingautoinvalpacapaper-tradinglumibotvectorbtbacktraderlibrary-comparisonbuild-vs-buy

Alpaca Paper-Trading Harness — Library Comparison for autoinv

The question

What's the simplest Alpaca-Python paper-trading harness for phase-marker-based entry/exit rules on equity positions, and do existing libraries (zipline-reloaded, backtrader, vectorbt, lumibot) already handle the strategy-registry + bookkeeping shape autoinv would otherwise build from scratch? (Source: curiosity, High priority, auto-promoted 2026-05-18 at 13/15 — direct gap in active autoinv build, library comp saves weeks.)

What we already know (from the vault)

What the web says

Convergences and contradictions

Convergence: vault gap list (paper-trading registry + BrokerageExecutionHandler for Alpaca + order state tracking + fills reconciliation) maps almost exactly to what Lumibot's Strategy + Broker + Trader classes provide out of the box. Web confirms Lumibot is the closest fit for the autoinv use case shape. The build-vs-buy answer is: borrow Lumibot's Strategy abstraction + Alpaca broker class; keep autoinv's BiasAudit, permutation_test, BrierScore, and strategy-handoff schema; build the persistent strategy-registry layer on top of Lumibot's file outputs.

Convergence: vault's strategy-vs-execution boundary (founder authorizes via /decisions/, Ray executes locked parameters) is compatible with Lumibot's lifecycle hook pattern. Each Strategy can be configured to require an explicit external authorization signal before on_trading_iteration actually places orders. Lumibot doesn't obscure the order pathway; orders flow through the Broker class explicitly.

Contradiction (sharp): the vault strategy.md still names "BrokerageExecutionHandler for equities" as an autoinv gap to build, implicitly suggesting from-scratch implementation. The web research says this is wasted weeks — Lumibot's Broker abstraction + Alpaca implementation is already production-tested. Recommend updating strategy.md to remove BrokerageExecutionHandler from the build list and add "wire autoinv's strategy candidates into Lumibot's Strategy class" instead.

Contradiction (mild): vault's "single-threaded staged build now" discipline could argue for picking the thinnest possible wrapper (TradeSight, or even rolling a 200-line custom Alpaca-py wrapper) rather than adopting Lumibot's full framework. Counter-argument: Lumibot's multi-strategy orchestration via Trader class is exactly the topology autoinv strategy.md describes for Stage 2 (multi-agent same interfaces). Adopting Lumibot now buys the eventual multi-strategy shape without locking in custom plumbing. The thinnest wrapper choice optimizes for today and pays the framework-cost later.

Synthesis for RDCO

Recommendation: adopt Lumibot's Strategy + Broker + Trader abstractions; keep autoinv as the surrounding research/validation/registry layer.

The split:

Layer Provider Why
Strategy lifecycle (initialize, on_iteration, on_fill) Lumibot Production-tested; standard interface; backtest-to-live parity
Broker abstraction (Alpaca, IB, others) Lumibot Built; would take weeks to replicate
Multi-strategy orchestration (Trader class) Lumibot Exactly the Stage 2 shape autoinv vision targets
Backtest replay engine Lumibot Strong; minute-bar granularity; slippage + commission baked in
Bias audit, permutation test, Brier scoring autoinv RDCO-specific discipline gate; not in Lumibot
Phase-marker / phase-aware entry-exit logic autoinv strategy-candidate code Domain-specific; reuses founder's mental models
Persistent strategy registry across runs autoinv (NEW) Lumibot only produces per-run files; centralized DB is RDCO-specific
Founder-authorization gate (/decisions/) autoinv wrapper around Lumibot Strategy Lumibot doesn't model this; wrap it externally
1Password credential pull existing alpaca-env-paper.sh Already done; just source-and-launch the Lumibot process

Migration cost estimate: 1-2 sessions. Existing autoinv code that lives in autoinv.engine.Backtest becomes thin orchestration around Lumibot's backtest function. Existing strategy-candidate code (currently Polymarket-shaped) gets a parallel Lumibot Strategy subclass for equity work. The autoinv package keeps its discipline-gate + research-loop semantics; Lumibot keeps its execution + backtest plumbing.

Implication 1: kill BrokerageExecutionHandler from the autoinv build list. It was a strawman build target; Lumibot already implements it well. Update strategy.md to remove this gap and replace with "Lumibot integration spike."

Implication 2: the strategy-candidate handoff schema (Apr 23 audit item #10) becomes Lumibot-shaped. A candidate strategy is a Lumibot Strategy subclass + a YAML config + a discipline-gate spec (Brier ≤ 0.12 + permutation test + bias audit PASS). This is a tighter spec than the current free-text shape and tractably automatable.

Implication 3: this unblocks the autoinv L3 curriculum step. L3 (linear algebra: S&P 500 PCA + Markowitz from scratch with cvxpy) doesn't need Lumibot — but the execution test of L3 results (does the Markowitz-derived portfolio actually paper-trade well?) becomes near-free once Lumibot is wired in.

Implication 4: this also accelerates investing-backtest-thesis skill v2. That skill already uses Alpaca; standardizing on Lumibot's Strategy class means future backtest-thesis runs can produce drop-in Lumibot Strategy subclasses that paper-trade live without rewriting.

The deeper strategic point: autoinv's L4-L5 value is in the RDCO-specific discipline (Brier gates, bias audits, permutation tests, vault writeups) AND in the multi-agent loop topology (research agent → paper-test agent → execution agent → monitor-risk agent → reporting agent). Lumibot supplies neither. Lumibot supplies the boring infrastructure (broker abstraction, lifecycle hooks, multi-strategy orchestration, backtest-to-live parity) that autoinv would otherwise grow as plumbing. Adopting it is a force-multiplier on the bet that the discipline + topology is the moat, not the plumbing.

The 4-8 weeks the question's notes estimated for save-vs-build is plausible at the high end if the work would have included Alpaca broker class, fills reconciliation, order state tracking, slippage modeling, and multi-strategy orchestration. Even the conservative estimate (2 weeks saved on broker class + fills reconciliation alone) clears the bar to recommend the swap.

Open follow-ups

Sources