Backtesting

Backtesting simulates a controller config against historical candles. Use it to understand parameter sensitivity and to check that your strategy behaves as expected, not to predict exact live results.

Philosophy

Backtesting market making strategies can’t perfectly simulate reality:

Queue position: order books are first in, first out, and exchanges don’t tell you where your order sits in the queue.
Path dependency: if one fill differs between backtest and live, everything after it diverges.
Order book depth: on a thick book your order may never fill, even when the price touches your level.

Don’t trust absolute PnL numbers from backtests. Use backtesting as a parameter research tool, not a prediction engine.

What backtesting is good for

Use case	Example
Parameter sensitivity	”What happens if I change portfolio allocation from 2% to 10%?”
Behavior validation	”Does my strategy only sell after inventory reaches 30%?”
Relative comparison	”Does configuration A generate more volume than B?”
Strategy debugging	”Why did the bot stop trading in this scenario?”

Supported executors

The Hummingbot backtesting engine simulates the executors a controller creates. It has simulators for these executor types:

Executor	Supported
Position Executor	Yes, including position hold
DCA Executor	Yes
Grid Executor	Yes
Order Executor	Yes
Arbitrage, XEMM, TWAP, LP executors	No

A controller that creates unsupported executors produces no trades for them in a backtest.

Running a backtest in Condor

Condor runs backtests with the backtest_chart routine. It sends a saved controller config to the Hummingbot API’s backtesting engine, waits for the result, and draws an interactive chart. The routine is part of Condor’s shared routine library, so you can run it from the Workspace, from Telegram, or through an agent.

Workspace
Telegram
Agent

Open the Routines page and select backtest_chart.
Pick a config in config_name and fill in the other fields (see the table below).
Run it. The summary and metrics appear in the run’s result, and the interactive chart is saved as a report.

Send /routines, choose backtest_chart, set the fields and run it. The chart is sent to the chat as an image.

Ask an agent, for example: “Backtest pmm_mister__balanced on 5m candles for the last 30 days.” (pmm_mister__balanced is the name an agent gives the balanced sample config when it uploads it.) Agents call the routine through manage_routines:

# Condor MCP tool call made by the agent
manage_routines(
    action="run_async",
    name="backtest_chart",
    config={
        "config_name": "pmm_mister__balanced",
        "start_date": "2026-09-15",
        "end_date": "2026-10-15",
        "resolution": "5m",
    },
)

run_async returns straight away and hands the result back to the agent when the backtest finishes.

Fields

Field	Default	Meaning
`config_name`	(empty)	Saved controller config to backtest. In the Workspace it’s a dropdown of the server’s configs.
`start_date`	`2025-04-22`	First day, `YYYY-MM-DD` (UTC).
`end_date`	`2025-04-23`	Last day, `YYYY-MM-DD` (UTC).
`resolution`	`1m`	Candle resolution for the simulation: `1m`, `5m`, `15m` or `1h`.
`trade_cost`	`0.0002`	Fee per trade as a decimal (`0.0002` = 0.02%).
`chart`	`true`	Send the chart image to the chat. Turn it off for parameter sweeps; the chart is still saved in the web report.
`task_id`	(empty)	Re-draw a saved backtest by its task ID instead of running a new one.

Each run gets a Task ID, shown in the summary. Results are stored in Condor for 30 days by default (CONDOR_BACKTEST_RETENTION_DAYS). If a run has fewer than 20 executors, the summary warns that the metrics are noise. Widen the date range or loosen the config and run it again.

Candle resolution and look-ahead

For controllers that trade on indicator signals, use a resolution no finer than the controller’s own candle interval.

The engine joins each controller’s indicator candles to the simulation candles by the candle’s open time. When the simulation resolution is finer than the controller’s interval (for example, a 15m bollinger_v1 run at 1m), each 1m row inside a 15m candle already sees that 15m candle’s final close and signal. The backtest trades on information it wouldn’t have had live, so PnL and Sharpe come out better than they should. Backtest such controllers at their own interval (here, 15m).

supertrend_v1 can’t be backtested at the moment: the engine drops every row of its indicator data, and the run fails.

Hummingbot’s standalone script scripts/backtest_pmm_mister.py (run from a Hummingbot source checkout) defaults to --resolution 1s for market making. Condor’s routine lists only 1m, 5m, 15m and 1h.

Comparing backtests

The backtest_compare routine overlays the PnL curves of saved backtests and ranks them in a metrics table.

Field	Default	Meaning
`task_ids`	(empty)	Comma-separated task IDs. Leave it blank to use the latest runs.
`latest_n`	`3`	How many recent backtests to compare when `task_ids` is blank (2–6).
`normalize_time`	`false`	Align every curve at t=0 so runs over different dates overlay.

Reading the chart

The backtest_chart figure stacks up to four panes that share the time axis. Panes only appear when the backtest has data for them.

Pane	Content
Price	Price line (white), with the controller’s Bollinger Bands when present, green or red background shading where the signal is long or short, and executor entry and exit markers. Grid executors also show their levels and fills.
MACD	MACD histogram and signal line, only when the controller computes MACD.
Cumulative PnL	PnL lines, active executor count and cumulative volume.
Position held	Long and short inventory, net position and its unrealized PnL. Shown for controllers that hold positions.

The chart title shows net PnL, Sharpe ratio, profit factor, executor count and volume.

PnL lines

Line	Colour	Meaning
Total PnL	Yellow, solid with a light fill	Everything combined
Executor Realized PnL	Green, dotted	PnL from executors that closed
Position Realized PnL	Blue, dotted	PnL realized from held positions
Position Unrealized PnL	Purple, dotted	Open PnL on held positions
Active Executors	Faint white area	Number of executors running at once (scaled to fit)
Cumulative Volume	Cyan, dash-dot, right axis	Traded volume so far

Executor markers

Each executor is drawn as an entry marker and an exit marker joined by a line. Markers are grouped by how the executor closed:

Legend entry	Colour and shape	Meaning
TP Buy / TP Sell	Green ▲ / red ▼	Closed at take profit
SL Buy / SL Sell	Orange ▲ / ▼	Closed at stop loss
Hold Buy / Hold Sell	Blue / purple ●, dotted line	Fill kept as inventory (position hold)
Early Stop Buy / Early Stop Sell	Grey-white ✕, dashed line	Stopped early, often an order refreshed before it filled
Other Buy / Other Sell	Grey ▲ / ▼	Any other close type, such as time limit

For TP, SL and Other markers the connecting line is green when the executor made money and red when it lost.

Example analysis: 2% vs 10% allocation

With pmm_mister, portfolio_allocation sets how much of the capital is quoted around the price. 2% allocation:

Inventory builds gradually
Trading continues through drawdowns
More consistent activity

10% allocation:

Inventory builds quickly
May reach max_base_pct during a drawdown
With position_profit_protection on, the controller won’t sell below its break-even price, and above max_base_pct it won’t buy either, so it stops trading until the position is profitable again

PMM Mister parameters

These pmm_mister fields have the most effect on backtest behaviour. Field names come from the controller’s config class.

Parameter	Description	Example
`portfolio_allocation`	Fraction of capital quoted around the price	`0.02` (2%)
`min_base_pct`	Below this inventory share, the controller stops placing orders that reduce the position	`0.3` (30%)
`max_base_pct`	Above this inventory share, the controller stops placing orders that add to the position	`0.7` (70%)
`max_active_executors_by_level`	Maximum active executors per price level	`20`
`buy_cooldown_time` / `sell_cooldown_time`	Seconds to wait before replacing a level on that side	`30`
`price_distance_tolerance`	Minimum distance from existing orders before a new one is placed at a level	`0.0002`
`buy_position_effectivization_time` / `sell_position_effectivization_time`	Seconds after a fill before it’s turned into held inventory	`1660`
`position_profit_protection`	Block the reducing side while the price is worse than break-even	`true`

Trading bots vs Condor agents

Aspect	Trading bots	Condor agents
Logic	Deterministic, coded	LLM-driven decisions
Tick speed	1 second by default	Minutes (each loop sets its own interval)
Backtesting	Supported for controllers	Not directly; agents backtest the controllers they deploy
Use case	Market making, executing a fixed strategy	Oversight, choosing and tuning strategies

Agents can backtest, deploy and retune controllers, but they act every few minutes, not every tick. The bot does the fast work; the agent supervises it.

Condor

Getting Started

Condor Agents

Running and Building Agents

Workspace Pages

Philosophy

What backtesting is good for

Supported executors

Running a backtest in Condor

Fields

Candle resolution and look-ahead

Comparing backtests

Reading the chart

PnL lines

Executor markers

Example analysis: 2% vs 10% allocation

PMM Mister parameters

Trading bots vs Condor agents

​Philosophy

​What backtesting is good for

​Supported executors

​Running a backtest in Condor

​Fields

​Candle resolution and look-ahead

​Comparing backtests

​Reading the chart

​PnL lines

​Executor markers

​Example analysis: 2% vs 10% allocation

​PMM Mister parameters

​Trading bots vs Condor agents

Philosophy

What backtesting is good for

Supported executors

Running a backtest in Condor

Fields

Candle resolution and look-ahead

Comparing backtests

Reading the chart

PnL lines

Executor markers

Example analysis: 2% vs 10% allocation

PMM Mister parameters

Trading bots vs Condor agents