Changelog
PitBridge is in development. This log records build milestones, not public releases. Every entry here is real. When something is in dogfood and not live, it says so.
Live execution in production, behind the operator arm ritual
Live order routing is now in production on a funded futures account. How it got there is the part worth reading. A one contract smoke test on that account was refused by the open core with LIVE_NOT_ARMED, because live execution requires three separate things to be true: a LiveExecutionProvider plugin is installed, its licence entitles live, and an operator has completed the arm ritual at the command line. The product refused its own author until all three held.
The arm outcome is written to the hash chained audit log, operator acknowledgement included. A running daemon never arms mid flight, so a restart is the final step of the ritual, and every other path fails safe to not armed. There is still no MCP tool, REST route or config setting an agent can reach that arms live execution.
The first real order through the complete stack ran on 30 July 2026. The confirm gate parked it for supervised approval, the fill on that order came back in 0.52 seconds, the protective stop was attested WORKING against the REST orderbook rather than scraped from a log file, and the flatten was clean. Autonomous cycles have run through the same guardrail engine since. This is one account and a short history, not a track record.
- daemon
- live
- audit
Broker truth on reconnect and a day ledger that survives a restart
On reconnect the daemon now adopts the broker's positions from the snapshot as the source of truth, instead of relying only on the executions it happened to see. If the daemon's own view disagreed, a position_mismatch entry is written to the audit log so the divergence is visible rather than silent. Position guardrails then compute on broker truth.
The day ledger, meaning the day's realized profit and loss, the sticky day-halt latch, and the set of booked execution ids, is now persisted to disk and restored on startup, but only for the current trading date. A daemon restarted in the middle of a session no longer forgets the day's losses, so the daily loss halt and profit lock keep enforcing across a restart. A prior day's ledger is rolled over, never resurrected.
- daemon
- reconcile
Guardrail hardening: in-flight-aware position cap and a stale account state guard
The position cap is now in-flight-aware. max_position counts the account's own working and pending orders alongside the filled position, so two concurrent orders, or a resting limit next to a market order, cannot sum past the cap by racing each other.
A new STALE_ACCOUNT_STATE guard blocks new entry orders when an account's account_state feed, the source of unrealized profit and loss, goes stale past a configurable window. The daily loss halt and profit lock now fail closed against a dead feed instead of running on frozen numbers, and de-risking with close or flatten stays allowed. The window is account_state_staleness_s under [daemon], default 60 seconds.
- daemon
- guardrails
MCP over HTTP at /mcp, with bearer-token auth
The daemon now serves MCP over streamable HTTP at /mcp, next to the existing stdio server. Any MCP-over-HTTP client, Hermes included, can attach at http://127.0.0.1:8873/mcp. The nine tools, the guardrail pipeline, and the audit log are identical across both transports, and stdio keeps working unchanged.
A bearer-token guard now covers the whole agent surface. Generate a token with pitbridge token new, set it as agent_token under [daemon], and every REST call and /mcp request must then send Authorization: Bearer <token> or get a 401. On a localhost bind the token stays optional. Setting mcp_http = false turns the HTTP endpoint off.
The bind stays fail-closed: a non-localhost bind refuses to start without paired mode, a pairing token, and an agent token. The order route is still local, and no path skips the guardrail engine.
- daemon
- mcp
- auth
Public site, docs, and design system
The marketing site went public: the product pages, the safety pages, the learn cluster, and the first comparison pages.
The security model doc is up, covering the localhost bind, pairing tokens, the arm-live ritual, and the kill switch.
The design system reached v1.1. Color stays semantic: green means an order is permitted to proceed, red means it was refused, and nothing decorative uses either.
- site
- docs
Local-first daemon and guardrail engine in dogfood
The local-first daemon runs the frozen order pipeline: schema check, permission check, guardrails, confirmation, submit, audit. No MCP or REST path skips it.
The guardrail engine enforces the twelve v0 guardrails, including the kill switch, the daily loss halt, and the max position cap. Limits load from a config file the agent cannot read or write.
Every decision writes to a hash-chained append-only audit log, so a dropped or altered line is detectable after the fact.
This runs in shadow mode against a NinjaTrader 8 simulation account. It is not public yet, and no account is armed for live orders.
- daemon
- guardrails
- audit
NinjaTrader 8 add-on and local MCP server paired
The NinjaTrader 8 add-on pairs with the daemon over the local network. The add-on connects out to the daemon, so there are no inbound firewall rules on the Windows side.
The daemon serves an MCP server over stdio for a local client; custom agents get a localhost REST API and WebSocket event feed. Tool names are still settling.
Reduce-only order verbs (close, flatten) stay reduce-only even under the kill switch, so de-risking is always possible while opening intent is not.
- addon
- mcp
PitBridge is in development. NinjaTrader 8 is first.
Tell us your platform and we email you when your setup is supported. Nothing else.