Skip to content

Strix Python SDK

Incident detection, reconciliation, and replay for live trading bots. Instrument your bot with a few function calls; Strix records every order, execution, and position, reconciles your bot's view against the broker's actual state, and lets you replay exactly what happened — without ever sitting in your order path. Built for Python equity traders running live bots.

Strix follows a standard instrumentation-SDK convention: the package namespace carries the brand, function names are short verbs (strix.init, strix.order, strix.ingest_execution, strix.reconcile).

import strix
from strix import Side, Execution

strix.init(transport=strix.LocalTransport(data_dir="./strix_data"))

with strix.order(symbol="AAPL", side=Side.BUY, qty=100) as o:
    broker.submit(o.order_id, o.symbol, o.side, o.qty)

strix.ingest_execution(Execution(
    order_id=o.order_id, symbol="AAPL", side=Side.BUY, qty=100, price="150",
))

# Later: reconcile your recorded view against the broker's truth.
result = strix.reconcile(broker_adapter, on_mismatch="warn")

That's enough to record orders and fills, then catch any divergence from your broker. Pre-trade risk checks are opt-in and passive by default — see Risk controls. The full Record → Reconcile → Replay walkthrough is in Getting started.

What's in v1

  • Order lifecycle tracking — PENDING_NEW → NEW → PARTIALLY_FILLED → FILLED, plus REJECTED for risk blocks (in on_breach="raise" mode) or broker-submission exceptions, and PENDING_CANCEL → CANCELLED for cancellations.
  • Position math — signed quantities (long positive, short negative), VWAP avg-price across adds/reductions/flips.
  • Pre-trade risk checks — qty, count, position, notional, and price-threshold limits on RiskSettings. Passive by default (a breach records a RiskBreach and the order proceeds); opt into hard-gating with on_breach="raise".
  • Continuous-risk stop-losses — SessionStopLoss (session-wide P&L) and CostBasedStopLoss (per-position drawdown), firing on executions and on user-supplied marks. Halt blocks exposure-adding orders; reducing orders pass through. Manual override via strix.resume_trading().
  • Market-data port — MarketDataAdapter Protocol for the prices Phase 2 checks need; StaticMarketData ships for tests, user writes the live adapter.
  • Sessions — sequential analytics windows you control with init / resume.
  • Persistence — pluggable; ships with InMemoryTransport (default) and LocalTransport (JSONL on disk, crash-safe).
  • Broker reconciliation — BrokerReadAdapter port + strix.reconcile(...) pulls missed executions and sanity-checks resumed positions/open orders against the broker.

What's not in v1

  • Analytics dashboard (computation seam exists; product is post-v1).
  • Cloud sync / hosted dashboard.
  • Time-in-force semantics (DAY, GTC, IOC, …) and expire lifecycle. (Cancels are supported via strix.cancel(order_id=...).)
  • Order routing or execution (Strix observes; it does not send orders to a venue).

Where to next

Standalone by design — and how this project is funded

Strix's SDK is Apache-2.0, fully functional standalone, and will stay that way. Local storage, the risk controls, reconciliation, and the documented event schema are not teasers — they're the complete product, no account required, nothing phones home.

We plan to fund development with an optional hosted service built on the same events: live dashboards, alerting, session history across machines. That's the roadmap, stated plainly, so you can decide with eyes open.

If you'd rather build your own tooling from the JSONL event log, that is a supported use case, not a loophole — start with Build your own analytics from the event log. The schema is a public contract: events carry a schema_version, and changes will be explicit in the changelog.

Status

v0.0.1. The public surface is stable for v1 scope; the persistence on-disk format carries a format_version so future migrations are explicit. See DESIGN.md in the repo for the architecture rationale.