Backtesting

Five tools that run against a vike-datahub server at --addr (default 127.0.0.1:7878). Three of them run a strategy over history (run_backtest, run_sweep, run_walk_forward); two answer what the server has to run it with (list_strategies, list_series). All five are read-only — a backtest mutates nothing — and all five report an unreachable server as a clean tool error (cannot connect to datahub at …), never a panic.

The three run tools take the same input: a backtest profile TOML, optionally with a Rhai script injected into it. Unless you pass script, which makes the client parse and re-serialize the TOML to inject it (inject_script_src), the profile is shipped to the server verbatim; and either way the server is the only thing that reads its shape (crates/vike-backtest/src/harness/profile.rs's from_toml_str, which parses and validates in one step) — which means a profile-shape error (no [sweep] table, a bad range, an unknown strategy) surfaces from the server after the connect, not before it. One schema, one error source.

[data]
venue = "binance"
symbols = ["BTCUSDT"]
kind = "bar"
from = "0"
to = "100000"

[strategy]
name = "buy_hold"

[sweep]
fast = [5, 10]

run_backtest

Run one backtest on the datahub from a profile TOML and return the report.

Returns report — the BacktestReport JSON as the server produced it.

The script argument is what lets an agent test a strategy it just wrote without ever writing a file: author, validate_strategy, then hand the same source straight to this tool. An unparsable profile is caught locally by the injection step; everything else is the server's answer.

Backtest this SMA-cross script on BTCUSDT bars and show me the report.

run_sweep

Run a parameter-grid sweep. The profile carries a [sweep] table whose every key overrides strategy.params.<key> across a grid of values, and the server ranks the results.

Returns sweep — the SweepReport JSON: one row per grid point, each carrying its own BacktestReport, best first. Rows whose run failed always sort last, so the head of the list is always a real result.

Sweep fast over 5, 10, 20 and slow over 50, 100 and rank by Sharpe.

run_walk_forward

Run an anchored out-of-sample walk-forward. The split count rides in the profile's [walkforward] table (n_splits), not in an argument.

Returns walkforward — the stitched WalkForwardReport JSON: the OOS windows plus oos_sharpe and wf_consistency.

The mode is always anchored (vike_backtest's run_walkforward). Each window runs fresh at engine.cash and the out-of-sample curves are rebased onto one running equity by the walk_forward_strategy stitch. It is bar-mode over a single series by construction — a tick-mode or multi-symbol profile comes back as a clean validation error, never a silent fall back to the first symbol.

Run this before believing a sweep. A grid search returns its best row whether or not the edge survives out of sample; this is the tool that asks.

Walk this strategy forward over 6 anchored splits and tell me if the edge holds out of sample.

list_strategies

The compiled native backtest strategies the server offers — the names a profile's strategy.name can resolve (vike_backtest::harness::STRATEGIES, served over RPC). The list comes from the server itself, so it reflects that build rather than this page. Takes no arguments.

Returns strategies, a list of names.

Native strategies and Rhai scripts are two different routes to the same engine: this tool answers the first, list_templates the second.

Which built-in strategies can I name in a profile?

list_series

Every stored data series the server holds, with its coverage — what a profile's [data] table can actually name. Takes no arguments. It reads the datahub's Inventory verb, the coverage-carrying superset of a plain series list, so an agent can pick a from/to range instead of guessing one.

Returns series, one row per series: kind, venue, symbol, interval, first_ts, last_ts and rows.

What data do we have for BTCUSDT, and over what range?