Hummingbot Connector v6.2.3

Release Date: October 13, 2026 Tags: MARKET MAKING, STABILITY, MEMORY, RECORDER

Overview

A market-making instance that had been quoting for days could no longer be started. Hummingbot keeps a record of every order level its strategy has ever quoted, and loads all of those records into memory before it places its first order. A market maker adds tens of thousands a day and nothing deletes them, so the memory a start needs grew every day until it passed the instance's memory limit. The supervisor killed the instance seconds after the start. With Auto-restart on, it started the instance again after the back-off and killed it again. Raising the limit only moved the day, and each attempt kept a core and the disk busy for the better part of a minute, which slowed the site.

Before every start the panel now keeps the newest 10,000 records and removes the rest. Upgrade Notes says what that costs.

No new requirement: Core v6.7.8, as before.

Update Instructions

pnpm updator

No schema change. One optional .env key, HB_RECORDER_KEEP_EXECUTORS, works from its default; restart the backend after changing it. Instances that are running keep running. The new step runs at each instance's next start.

Upgrade Notes

The first start after the update may prune a large database

• Before a start, the panel looks at the instance's own database, data/instance-<id>.sqlite in the Hummingbot folder. No file yet, or a file under 4 MB, costs one file check. A larger file is opened by a short Python check with the instance's own interpreter that counts its records.
• More than 10,000 records: the oldest are deleted and the file is compacted. This takes seconds (a 409 MB database with 208,386 records took 4.1 seconds on a live server) and is allowed 60 seconds, while the instance's start claim is held. The supervisor looks at instances one at a time, so the memory checks of the others wait meanwhile. Later starts only count the records and find nothing to remove.
• If the file cannot be cut down (it is not a database, it is larger than 1 GiB, or the cut does not finish in 60 seconds) it is moved aside, with its journal files, to instance-<id>.sqlite.<date and time>.archived, and Hummingbot starts on a fresh one. An instance that ran long enough for its file to pass 1 GiB is moved aside, not cut down, at its next start.
• Moving the file aside takes more than the records: the database also holds the instance's orders, its fills and the in-flight state it restores at start. Your exchange's records are the truth, so check the account's open orders after an instance has been moved aside. An .archived file is an ordinary database. Keep it for the history or delete it; nothing deletes it for you.
• The instance log says which of these happened, before the Starting: line.
• What is given up: the controller's performance report (net profit, volume and fees per controller) is rebuilt from these records at every start, so after a prune it covers the newest 10,000 records, roughly four to seven hours depending on the preset, instead of everything since the instance was created. On one measured database, 208,386 records spanned 12 days and the newest 10,000 spanned 4.6 hours. Quoting does not read the records, unless a preset asks to buy the base asset at start (acquireBaseAtStart), which counts the positions the controller's records opened.
• To keep the old behaviour, set HB_RECORDER_KEEP_EXECUTORS="0".

Added

A ceiling on what a start has to load

• Added the HB_RECORDER_KEEP_EXECUTORS setting, default 10000. Digits only: any other value, including an empty one, is read as the default, and 0 turns the pruning off, the move-aside step included. It is listed in .env.example.
• Added a section to the Hummingbot troubleshooting guide, "The instance is killed at every start by its memory limit", with the two log lines that identify the problem and what to do on an install without this release: stop the instance and move that database file aside.

Fixed

Instances killed at every start by their memory limit

An instance that had been quoting for days died right after the line Markets recorder initialized, with Memory limit exceeded as the next thing in its log. Pure Market Making started by hand did not do it, because that strategy keeps no such records.

Hummingbot 2.16.0 builds the V2 strategy's executor orchestrator at start, and that reads every executor the instance has ever recorded. The integrated market maker records one per ladder level per refresh: 6 per refresh on the seeded 3 + 3 presets, which is about 65,000 a day at the default 8-second refresh and about 32,000 on the Balanced preset.

• Fixed the start. The records are pruned before Hummingbot reads them, so the memory a start needs no longer grows with the age of the instance.
• Fixed the slowdown that came with it. A start that is killed and repeated every few minutes kept a core and the disk busy each time, on the server that also serves the site.