Hummingbot vs Freqtrade: only one backtests the job it is built for

One framework quotes both sides of a book, the other runs a signal strategy. Only Freqtrade can backtest its own job; Hummingbot reaches more venues.

Two frameworks, two jobs

These two get typed together because both are free, both are Python, both run on your own machine, and both trade crypto against an exchange with your key. They are not built for the same job, and almost every difference below follows from that.

Hummingbot is a market-making framework. The homepage sells "the open source framework for crypto market makers", and the strategies it is known for — Pure Market Making, Avellaneda, Cross-Exchange Market Making — keep resting quotes on both sides of a book; the spread is what they are trying to capture. Its catalogue job is market_making.

Freqtrade is a signal framework. You write a strategy that decides when to enter and exit, backtest it on downloaded candles, optimise it with Optuna, dry-run it, and then run the same class live. Its job is automation, and it is also listed on the backtesting shelf, which Hummingbot is not.

So the first question is not which is better. It is whether your strategy rests quotes or takes positions on a signal. If it rests quotes, Freqtrade has no strategy for you; if it takes positions, Hummingbot's best machinery is pointed somewhere else.

What you write, and in what

Both are Python, and in both the strategy is code you own.

In Freqtrade the strategy is one class operating on a pandas dataframe, and that class is what the backtester runs, what dry-run runs and what trades live. There is no second implementation, which is the reason to pick it.

Hummingbot carries two generations at once. The V1 quoting strategies ship in the repository. V2 splits a strategy into a controller that decides and executors that manage the order lifecycle — position, DCA, grid, order, TWAP, XEMM, arbitrage and LP — and V2 is where new work lands. Writing a Hummingbot strategy today means writing a controller that emits executor configs, and choosing between V1 and V2 is also choosing whether the backtester can see your strategy at all (below).

Venues, and who keeps a connector working

Hummingbot connects to more. The repository holds 26 spot connectors and 20 perpetual ones, plus a paper-trade connector, and DEX access through Gateway — a separate TypeScript service covering an Ethereum family (mainnet, Arbitrum, Base, BNB Chain, Polygon and others) and Solana, with connectors for Uniswap, Jupiter, PancakeSwap, Raydium and more. Every exchange on Freqtrade's spot list appears on Hummingbot's except the regional variants Bybit EU, Gate EU and MyOKX. The vendor publishes three connector counts — 318, 50+ and 140+ — that count different things; the repository count is the one to use.

Freqtrade reaches venues through ccxt and names the ones it supports: twelve spot entries and seven for futures (Binance, Bitget, Bybit, Gate, Hyperliquid, Kraken, OKX), with Bitvavo and KuCoin community-tested and everything else ccxt reaches marked "we cannot guarantee they will work". Its DEX reach is Hyperliquid, which it can trade live but cannot backtest, because the venue returns no history.

How a connector stays alive differs more than the counts do. In Hummingbot, which connectors exist is a governance question: HBOT holders vote to add and remove them, and maintenance is paid by bounties that exchanges fund. If your venue's connector stops being maintained, a vote decides whether it comes back. In Freqtrade the connector is ccxt plus the project's own support list, and nothing on the card ties a venue's place on that list to a payment.

The backtest: one runs the strategy, the other runs something else

This is the finding neither card states on its own. Freqtrade's backtester runs the strategy Freqtrade is built to run. Hummingbot's backtester does not run the strategies Hummingbot is built to run.

Freqtrade downloads candles once and stores them locally. It reads the venue's fee from market info, though it charges the higher of maker and taker on every fill. In futures mode it pulls mark and funding-rate candles, settles funding during the run and exits at the liquidation price, where the venue serves that history; where it does not, the fallback is a constant the docs recommend setting to zero. Its fills are optimistic and the docs say so: no slippage, and intra-candle movement is a guess unless you pass a faster timeframe with --timeframe-detail. The automatic pairlists do not run in a backtest.

Hummingbot has a backtester only in the V2 engine, and only for four of its eight executors — position, DCA, grid and order. A passive quote is filled, in full, the moment a one-minute candle closes through its price, and priced at that close rather than at the quote, so the spread you meant to earn is not what the result is computed from. Costs are a flat 0.0002 a side, the same for maker and taker, with no rebate. There is no funding, liquidation or slippage anywhere in the package. XEMM, arbitrage, TWAP and LP cannot be simulated, the V1 strategies cannot be run at any setting, and the hbot CLI cannot reach the backtester; you go through Python or Dashboard, a separate repository last pushed on 27 October 2025.

Neither models a market maker's real question — whether a resting order would have been filled. Freqtrade does not try, because it has no quoting strategy. Hummingbot is built for exactly that question and assumes the answer. The backtest guide covers the assumptions in general; on this pair, the backtester is the reason a directional strategy belongs on Freqtrade even where Hummingbot has the connector.

Where the key lives, and what you run

Both run on hardware you control, and in both the exchange key stays with you: Freqtrade holds your API keys and calls the exchange directly, and Hummingbot runs locally, where its quickstart needs no key at all for a paper-trading bot. Neither sells a hosted tier.

The burden after that is not the same. Freqtrade is one program: Docker, which the project recommends, or Python 3.11+ with TA-Lib, on a documented floor of 2 GB RAM, 1 GB disk and 2 vCPU. The REST API, the FreqUI web interface, the Telegram bot and webhooks are all inside it.

Hummingbot is one program for one bot on one centralised venue, and a set of services after that. Docker runs the classic interactive client by default; a source install wants Anaconda or Miniconda. DEX trading adds Gateway. Running several bots, agent control or the first-party MCP server adds the Hummingbot API server, and the MCP server is a further install on top of it. Alerts are not in the client at all — the notifier has no implementations and there is no Telegram — so being told the bot stopped means Condor or something you build. And by default each instance reports aggregated volume, the connector, the version, system specs and a random ID every 15 minutes, off with one setting. The Freqtrade card records no such feed.

Who pays for each

Both are free to you and sell you nothing. The difference is what the card can say about the other side.

Hummingbot's foundation publishes its rate card: a maintained connector from 10,000 dollars a year through bounty management, a sponsorship from 50,000, and a README sponsor table where Binance carries a 10% fee-discount referral link and Gate.io, KuCoin and OKX 20% ones — which is why Binance is the quickstart exchange. The default-on volume reporting is what the foundation's public volume dashboard is built from.

The Freqtrade card records no hosted tier, no signal subscription, no commercial licence and no token, no commission on orders and no routing through anything of its own. It does not record what funds the project. The guide to who pays for free bots explains why the question is worth asking before the feature list.

The licences differ in a way that matters only if you distribute a modified bot: Apache 2.0 is permissive, GPL-3.0 is copyleft for what you distribute. Running a private strategy on your own server obliges you to publish nothing under either.

Dates under this page

Both cards' pricing, capability and coverage blocks were verified on 19 September 2026, and both were last updated on 3 October. Freqtrade's fee rule and its funding fallback were re-checked on 3 October; Hummingbot's backtester findings, release dates and connector lists date from 19 September. Release cadence as of that date: Hummingbot one every five to eight weeks (v2.16.0 on 29 July), Freqtrade monthly (2026.8 on 31 August).

Which one, and when

Take Hummingbot if the strategy quotes both sides — a spread, an Avellaneda model, a cross-exchange hedge — or if the venue you need is a DEX pool or an exchange on its list and not Freqtrade's. Accept, before you start, that you will be judging the quotes live or on paper, because its backtester cannot tell you whether they would have filled, and budget for Gateway, the API server and your own alerting as the setup grows.

Take Freqtrade the moment the strategy is a signal — enter on a condition, exit on another — on a venue from its support list. It is the one whose backtest runs the class it will trade live, charges a real venue fee, settles funding on perpetuals where the venue serves the history, and reports through Telegram and webhooks out of one process. Check first that your venue serves funding history, and pass your own fee if you rest limit orders.

Do not run a directional strategy on Hummingbot because the connector is there. The backtest you would read is the weaker one by the card's own account. And if the simulator matters more than either connector list, NautilusTrader is the engine built around an order-book fill model; for signal frameworks alone, Freqtrade vs Jesse is the closer page.

FAQ

Which one should I use for market making?

Hummingbot. Freqtrade ships no market-making strategy and has no DEX middleware; its strategy is a class that reads a dataframe and emits entries and exits. Hummingbot is built around quoting both sides, with Pure Market Making, Avellaneda and Cross-Exchange Market Making in the repository. Just do not expect its backtester to tell you whether the quotes would have filled, because it has no market-making fill model.

Which one has the better backtester?

Freqtrade, for the strategies each is built to run. Freqtrade stores candles locally, reads the venue's own fee, and in futures mode settles funding and stops at the liquidation price where the venue serves the history. Hummingbot's V2 engine fills a passive quote whenever a one-minute candle closes through its price, charges one flat cost for maker and taker, models no funding or liquidation, and cannot run the V1 strategies the project is named for at all.

Do I need to know Python for either?

For Freqtrade, yes; the strategy is a Python class and there is no configure-instead path. For Hummingbot, new strategy work is a V2 controller in Python, and the classic quoting strategies ship with the client. Freqtrade's web interface and Telegram bot watch a running bot; neither is where the strategy is written.

Is either one free, and who pays for it?

Both are free, with nothing to buy from either. Hummingbot's foundation publishes where its money comes from — exchanges pay from 10,000 dollars for a maintained connector and from 50,000 for a sponsorship, and the README carries fee-discount referral links. The Freqtrade card records nothing for sale at all, not even a hosted tier, and states that it adds no commission and routes orders through nothing of its own.

Report an error on this page

Quote the line and say what it should be.

The vendor’s page, filing or documentation that says otherwise.

Only if you want to hear back. Never published.

Read by a person. It fixes a fact and moves nothing else.