RLX Backtester is a native macOS app built for AI-powered quantitative research. Connect Claude, Cursor, or any MCP-compatible agent to design, backtest, optimize, and stress-test trading strategies locally. Unlike traditional backtesting tools, RLX combines a high-performance Rust engine, reinforcement learning workflows, and an AI-native interface that lets autonomous agents iterate on strategies in real time. Free tier included, with Pro for unlimited research.
No reviews yetBe the first to leave a review for RLX Backtester
Maker
π
π Hi Product Hunt!
Iβm Serhii, the solo developer behind RLX Backtester.
I built RLX because I was frustrated with existing backtesting tools. They were either too slow, difficult to extend, or disconnected from the way modern AI agents work.
RLX started as my own high-performance research engine written in Rust. Over time it evolved into a native macOS application where Claude, Cursor, or any MCP-compatible agent can build, optimize, backtest, and stress-test trading strategies locally.
My goal wasnβt just to make another backtester. I wanted to build a tool that feels like a real development environment for quantitative research - where AI can iterate on ideas while developers stay in control.
This is only the first public release, and Iβd genuinely love your feedback.
What feature would make this indispensable for your workflow?
Thanks for checking it out! π
Report
How does the RLX engine handle walk-forward validation versus simple in-sample fitting, especially when the reinforcement learning loop starts overfitting to historical regimes?
"Great question. The RLX engine handles this through a combination of strict walk-forward cross-validation (WFCV) and deterministic policy freezing:
### 1. Walk-Forward Validation vs. In-Sample Fitting
β’ Sliding/Anchored Windows: Instead of a single train/test split, the engine runs walk-forward analysis ( walk_forward tool) across multiple rolling windows. The model
(whether rules-based or a neural policy) is optimized/trained strictly on an In-Sample (IS) window and then executed on an adjacent, completely unseen Out-of-Sample
(OOS) window.
β’ Walk-Forward Efficiency (WFE): We evaluate robustness using the WFE metric:
If WFE is close to or above 1.0, the edge is robust. If it decays significantly (e.g., below 0.5), the system flags the configuration as overfitted to local
When using the RL engine (e.g., DQN or Actor-Critic):
β’ Deterministic Policy Evaluation: During training, the RL agent uses stochastic actions (via Ξ΅-greedy or entropy-regularized policy distributions) to explore. However,
during validation and walk-forward OOS testing, the policy is frozen and evaluated deterministically using the argmax of policy logits. All exploration noise is
disabled.
β’ Non-Stationary State Space Normalization: To prevent the neural network from memorizing nominal price levels (which leads to regime overfitting), the RLX engine
processes inputs through statistical normalization. Features are converted into stationarity-adjusted metrics such as return z-scores ( ret_z_24 ), drift scores, and
Shannon price entropy. This forces the model to generalize patterns of market structure rather than specific historical price zones.
β’ Benchmark Comparison: The engine benchmarks OOS performance directly against passive Buy & Hold and randomized baseline agents to ensure that the RL model is capturing
actual alpha rather than riding beta or overfitting to a specific market direction."
Report
Curious how the RL loop actually works in practice here, like is the agent running full training cycles on past data or more of a prompt-driven parameter sweep? Also wondering what kind of latency you are seeing from the Rust engine when iterating with Claude live.
Report
Maker
@savas_teki53713Β "Great questions! Here is how the system is architected under the hood:
### 1. How the RL Loop Works
It is a hybrid, two-level system:
β’ Under the Hood (Deep RL): Yes, we run full training cycles on historical data. When we trigger training, the engine spins up PyTorch/LibTorch pipelines (running models
like Actor-Critic A2C or DQN) directly on chronological feature datasets. The neural network trains over multiple episodes (e.g., 10β30 episodes) to learn optimal action
policies (Buy/Sell/Flat) based on normalized feature inputs (like return z-scores, fractal efficiency, and Shannon entropy).
β’ At the Agent Level (Strategic Controller): The LLM (Claude/Gemini) acts as the architect. Instead of writing code weights, the agent uses the Hypothesis Canvas (Idea
Map) to structure experiments. It configures the state space (choosing which custom features to feed the network), sets up the reward functions, triggers the training
loops, and sweeps boundaries. It then evaluates walk-forward efficiency (WFE) and Monte Carlo risk outputs to decide on strategy mutation.
### 2. Engine Latency & Live Iteration
Since the core backtesting engine and state compiler are written in optimized Rust:
β’ Single Backtest: Running a strategy over 10,000 bars (hourly data, ~1.5 years of BTCUSDT) takes about 70 to 110 milliseconds.
β’ Exit Optimizer (Sweep): Running a parameter sweep (e.g., testing 288 different combinations of TP/SL ratios) takes around 300 to 400 milliseconds.
β’ Live Iteration: Because the Rust engine handles calculations in milliseconds, the latency of our iterations with Claude is almost entirely dominated by the LLM's API
response time. There is no blocking compute lag, which allows the AI agent to run backtests, optimize exits, and cross-validate walk-forward results in real-time during
How does the RLX engine handle walk-forward validation versus simple in-sample fitting, especially when the reinforcement learning loop starts overfitting to historical regimes?
@gkegjn9Β
"Great question. The RLX engine handles this through a combination of strict walk-forward cross-validation (WFCV) and deterministic policy freezing:
### 1. Walk-Forward Validation vs. In-Sample Fitting
β’ Sliding/Anchored Windows: Instead of a single train/test split, the engine runs walk-forward analysis ( walk_forward tool) across multiple rolling windows. The model
(whether rules-based or a neural policy) is optimized/trained strictly on an In-Sample (IS) window and then executed on an adjacent, completely unseen Out-of-Sample
(OOS) window.
β’ Walk-Forward Efficiency (WFE): We evaluate robustness using the WFE metric:
Average OOS Return
WFE = ββββββββββββββββββ
Average IS Return
If WFE is close to or above 1.0, the edge is robust. If it decays significantly (e.g., below 0.5), the system flags the configuration as overfitted to local
volatility/trend regimes.
### 2. Preventing Reinforcement Learning Regime Overfitting
When using the RL engine (e.g., DQN or Actor-Critic):
β’ Deterministic Policy Evaluation: During training, the RL agent uses stochastic actions (via Ξ΅-greedy or entropy-regularized policy distributions) to explore. However,
during validation and walk-forward OOS testing, the policy is frozen and evaluated deterministically using the argmax of policy logits. All exploration noise is
disabled.
β’ Non-Stationary State Space Normalization: To prevent the neural network from memorizing nominal price levels (which leads to regime overfitting), the RLX engine
processes inputs through statistical normalization. Features are converted into stationarity-adjusted metrics such as return z-scores ( ret_z_24 ), drift scores, and
Shannon price entropy. This forces the model to generalize patterns of market structure rather than specific historical price zones.
β’ Benchmark Comparison: The engine benchmarks OOS performance directly against passive Buy & Hold and randomized baseline agents to ensure that the RL model is capturing
actual alpha rather than riding beta or overfitting to a specific market direction."
Curious how the RL loop actually works in practice here, like is the agent running full training cycles on past data or more of a prompt-driven parameter sweep? Also wondering what kind of latency you are seeing from the Rust engine when iterating with Claude live.
@savas_teki53713Β
"Great questions! Here is how the system is architected under the hood:
### 1. How the RL Loop Works
It is a hybrid, two-level system:
β’ Under the Hood (Deep RL): Yes, we run full training cycles on historical data. When we trigger training, the engine spins up PyTorch/LibTorch pipelines (running models
like Actor-Critic A2C or DQN) directly on chronological feature datasets. The neural network trains over multiple episodes (e.g., 10β30 episodes) to learn optimal action
policies (Buy/Sell/Flat) based on normalized feature inputs (like return z-scores, fractal efficiency, and Shannon entropy).
β’ At the Agent Level (Strategic Controller): The LLM (Claude/Gemini) acts as the architect. Instead of writing code weights, the agent uses the Hypothesis Canvas (Idea
Map) to structure experiments. It configures the state space (choosing which custom features to feed the network), sets up the reward functions, triggers the training
loops, and sweeps boundaries. It then evaluates walk-forward efficiency (WFE) and Monte Carlo risk outputs to decide on strategy mutation.
### 2. Engine Latency & Live Iteration
Since the core backtesting engine and state compiler are written in optimized Rust:
β’ Single Backtest: Running a strategy over 10,000 bars (hourly data, ~1.5 years of BTCUSDT) takes about 70 to 110 milliseconds.
β’ Exit Optimizer (Sweep): Running a parameter sweep (e.g., testing 288 different combinations of TP/SL ratios) takes around 300 to 400 milliseconds.
β’ Live Iteration: Because the Rust engine handles calculations in milliseconds, the latency of our iterations with Claude is almost entirely dominated by the LLM's API
response time. There is no blocking compute lag, which allows the AI agent to run backtests, optimize exits, and cross-validate walk-forward results in real-time during
a single chat turn."
https://rlxbt.com/articles/autopilot-strategy-creation-evolution-with-ai-agents-and-deep-rl-1