Reamer Server
A live execution server for your mid-frequency strategies. It holds order state and sequencing, runs the pre-trade decision path between your strategy and your venue, and publishes every intent, fill, and reject on a shared-memory event bus. You link it against a stable C interface (ABI), wire in your gate and your broker connector, and that call is your server process. The gate and connector are C, C++, Rust or Go, with starting points for each in the kit; strategies connect over a documented socket protocol, from any language, plain Python included.
Integrated by Claude Code in about 19 minutes
Claude Code (Claude Sonnet) was given the Reamer Server kit and nothing else: no source code and no earlier exposure. Working from the C header, the protocol specifications and the Go reference connector, it wrote a trading server in C++: its own FIX 4.4 session and broker connector, a gate with an instrument allowlist and a position limit, and an event bus reader, all linked into the core. Against the kit's simulated venue it submitted 6 orders: 5 filled across AAPL, SPY and QQQ, and the gate rejected 1 with its exact reason, confirmed through the metrics endpoint. A wall clock runs throughout: about 19 minutes of real time.
The kit documents are enough for a coding agent to write the gate and the connector, so the learning curve is the agent's, not yours. What follows is your broker's own protocol dialect, sequence persistence and certification, which depend on your broker rather than on Reamer Server.
What happens in the recording
Chapter times are video time. The recording is sped up; the wall clock in the frame shows real elapsed time. Recorded 13 September 2026 against Reamer Server 4.2.1. Watch page → · YouTube →
- 0:00The task
- 0:20Verify the kit, activate, read the C header
- 1:00Run the reference end to end
- 1:20Event bus, wire protocol and config
- 2:00Planning the C++ layout
- 2:20FIX 4.4 message codec and session
- 3:00Broker connector
- 4:40Checking struct layouts against the header
- 5:40Gate: allowlist and position limit
- 6:00Event bus reader and strategy client
- 6:40main(), Makefile and build
- 7:40Live run against the simulated venue
- 8:00Debugging the event tail
- 8:40Verified end to end
- 9:00Summary
- 9:20Issues found, licence deactivation
The clean-latency region tracks your core count.
A full 1→512 concurrent-strategy sweep. Throughput here means orders per second — the number of order intents the core accepts or rejects each second. Latency here is measured per order, end to end: from the moment a strategy submits an order intent to the moment the core returns its acknowledgement. Throughput plateaus across the core band, and every order matched its accept-or-reject event exactly once at every point.
Selected points from a 130-point sweep, 1→128 in steps of 1 plus 256 and 512. Throughput (orders per second) plateaus through about one strategy per physical core, then falls steadily under oversubscription while the latency tail widens. Every order matched its accept-or-reject event exactly once at every point through 512. Latency is per order, core to a local acceptor on the same machine, with no network or venue time included. One rented single-socket box, stub broker. Verify absolute numbers on your own hardware. Method and the full sweep are in the whitepaper; the raw output is published alongside it.
Measured cost, layer by layer
Don't conflate the layers. The boundary is ~1% of per-order core cost. Your gate and broker logic dominate, not the ABI. All figures below are the AMD EPYC 9575F run.
Single rented single-socket box. Verify absolute numbers on your own hardware.
Every order leaves a trail you can read
The core writes the flow as it runs. A live event stream, scrape targets your orchestrator already speaks, and a one-command bundle for a support request. Nothing to bolt on.
The core broadcasts each pipeline event on a shared-memory ring. Any number of reader processes attach independently and replay from a sequence number. Accepted, rejected, filled, cancelled, each with its reason.
A Prometheus /metrics surface and a liveness/readiness /health route your orchestrator scrapes directly. Order counts, rejection reasons, table saturation, broker and relay connectivity.
reamer-diag-bundle scrapes health, metrics, and the retained event history into a single JSON file, stamped with the build. The auth token is never written to it. Attach it to a support email as is.
Every line the core writes is one JSON object, ready for journald, ELK, or Datadog. Set REAMER_TIMING_DEBUG=1 and the main loop reports poll latency, batch size, and outlier dispatch, inert until you ask.
Two vtables and a socket, in your language
The core links into your process. You implement a gate and a broker connector as C structs of function pointers, connect your strategy over a socket, and call reamer_server_run(). Reference skeletons run before you write anything real.
One pre-trade decision per intent. Pass or reject, given the intent and the venue's last known state.
Your venue session. Reports fills back and is the sole source of venue state: positions, open orders, connection status.
A local Unix domain socket, or a remote relay for a strategy in another process or host. Both wire protocols shipped in full.
A plain C callback API. A C++ implementation closes over its object through a trampoline; Go connects through cgo. Both documented.
An accept-all gate and in-memory paper broker, in C++ and Rust. The smallest thing that runs, to confirm your wiring first.
A FIX 4.4 session, broker connector, and strategy relay driven to a fill in one command. Reference material, not a supported surface.
What's in scope
The gate, broker connector, and OEMS are customer-built, not pre-wired extension points. Platform: linux_x86_64, glibc 2.39, ABI 4.
Per seat, per year. Start with a 30-day trial at $900; key and kit arrive by email within minutes.
Start a 30-day trial