Where the numbers come from

The rule

No number on this site is typed by hand. The tables below are printed by one script from the bot's own runtime files plus a single public price request:

python scripts/results_report.py

Inputs: data/trading/statistics.json, data/trading/api_costs.json, data/trading/trade_history.db, data/trading/metrics/cycles.jsonl, and one Binance klines request for the benchmark. When the ledger changes, the site changes with it — including the numbers that look worse. The figures on this page are the output of a run on 2026-10-27; the cost totals grow with every cycle, so the live dashboard is the place to read them.

The window

The ledger

Two of the twelve rows are excluded from statistics and from the brain's learning: their sandbox exits printed below the real market low in the same minute, which is a fill divergence, not a market move. They stay in execution history. The 41.67% win rate uses the full row count as its denominator (5 / 12), which is conservative: the excluded rows cannot count as wins.

Inference cost

Costs are the provider rate-table estimates the bot records while running (config/model_pricing.json, config/peak_rates.json), not invoice reconciliation. Per cycle, across the 50 recorded cycles: mean $0.0117, median latency 266 s.

Inference cost is not a footnote here: the expected-value rule that the model is given reads from the same trade history, and $6.02 of model usage against $13.95 of gross paper profit is most of the result.

The benchmark

The difference is about 1.6 percentage points over five weeks. It is the kind of gap that a single trade, a fee assumption or a different start date can erase, and it is why the comparison is stated with its window and never as a result. The benchmark deliberately stops at the last bar that closed inside the window — counting the bar the exchange is still forming makes the same window read −1.6%, −1.7% or −1.8% depending on the minute.

The gaps

• Twelve trades cannot separate skill from noise. Any statistic here has an error bar wider than its value.
• Fees are configured but not booked. transaction_fee_percent = 0.00075 (0.075% per side) is the rate the expected-value block uses when it argues with the model. The paper ledger stores fee = 0.0 on booked rows and NULL where a fill fee is unknown, and the close path refuses to substitute the configured rate for an unknown fee — so the P&L above is gross of trading costs. At 0.075% per side and roughly 8% of capital per position, a round trip costs about 0.15% of the position (≈ $1.20 at $10,000 across 12 trades ≈ $14), which is the whole gain.
• Simulated fills. Paper exits are modelled, not matched. The two excluded rows are a small demonstration of how far a sandbox fill can be from the real market.
• One instrument, one exchange, one month. No cross-sectional test, no regime test, no out-of-sample period.
• Costs are estimates. Provider rate tables, not invoices.

What this does not prove

It shows that the pipeline runs, records its own decisions and can be re-derived from files. It does not show that the system is profitable, that the strategy generalises, or that the same numbers would survive fees and live liquidity. The page is here so the numbers can be checked and attacked, not so they can be quoted as a track record.