Keryx 0.16.1 tells the pool when its GPUs are busy
Source report: 2026-11-07 · Editorial analysis published: 2026-11-08
The pool can reassign an AI request instead of waiting for silence. The mining kernels remain unchanged.
A busy card can now answer the pool
Keryx Miner Supr 0.16.1, released on November 7, gives a mining pool a clearer answer when a rig cannot take another AI task. If every suitable GPU is already serving inference, the miner can report error 46, meaning busy, instead of leaving the request unanswered. The pool can then send that task to another rig sooner.
Inference means running an AI model to produce an answer. In Keryx, a rig can have responsibilities for these requests as well as mining. A pool waiting for silence to become a timeout has less information than a pool told that the suitable cards are occupied. The update targets that communication gap.
The developer recommends the update for rigs that serve inference and explicitly says the mining calculation is unchanged from 0.16.0. This is a small pool-connection update, not a new promise of more hashrate or lower electricity consumption. Its usefulness depends on whether the operator serves those requests through a compatible pool.
What triggers the busy response
The new response concerns a pool inference request when all cards able to serve the requested model are running another inference. The miner first waits briefly for a suitable card to become free. The default wait is 5,000 milliseconds, or five seconds.
The setting permits a wait from 1 to 30,000 milliseconds. That is a local waiting interval before the busy reply. It is not a promise that the task will finish in that time or that another rig will accept it. The pool still controls what happens after it receives the response.
Other situations in which a rig does not answer retain their previous silent behavior. The change therefore has a specific trigger. A missing answer elsewhere in the log should not automatically be interpreted as the same busy-card case, and changing this interval does not add memory or computing capacity to the hardware.
Keep task responses separate from mining shares
The release also describes what happens when the pool returns error 46 in response to a mining share: the miner logs it and keeps the connection open. A share is a submitted piece of mining work. This handling prevents that particular response from closing the session.
Keeping a session open and having a share accepted are different outcomes. The log records the response; it does not turn a rejected or deferred item into accepted work. Operators can distinguish connection continuity from the pool’s actual accounting of submitted shares when reading the results.
The developer says the GPU mining kernels, embedded CUDA and OpenCL code, and inference engines are byte-identical to 0.16.0. Only the pool connection code changed. CUDA and OpenCL are ways the program runs work on GPUs. The useful comparison for this update is how requests and connection responses are handled, not an assumed speed increase.
H16 compatibility remains part of the package
Version 0.16.1 retains the preceding release’s H16 handling for Keryx node 1.6.7. The documented mainnet activation threshold is DAA score 147,000,000, with 180,000 used for testnet. DAA is the network’s progress score; it is not a Bitcoin block height.
The preceding release switches rules at that threshold and frees 200 MiB of context-pad GPU memory per tier. A MiB is a memory unit. This is inherited compatibility behavior, not memory newly saved by the busy-response patch. The release documentation’s expected calendar activation time is also separate from directly observing a live node’s current score.
A miner, node and pool bridge need compatible handling of the service messages. The official node release describes traced inference and audit messages for pools. Having an archive for a particular operating system does not by itself establish that a chosen pool implements the required protocol. The pool’s supported connection and the program version belong in the same operating record.
What the published tests establish
The developer reports startup checks on Ubuntu 20.04, 22.04 and 24.04 for the Linux archives. A packaged miner on an RTX 5070 Ti ran against the updated mainnet pool for 70 minutes, with 268 accepted and zero rejected shares and no reconnection. These are the publisher’s test conditions and results.
That live run did not receive a pool request that required the new busy reply. The busy format was covered by miner and pool unit tests. Keeping those two results together explains the evidence: the release has a reported live mining run, while the new response path was tested separately. ASIC.tools did not install or run the package.
Packages cover Linux, several mining operating systems, Windows, macOS arm64 and Docker. The executable and its bundled libraries should stay together. The release retains limitations: Metal H15/H16 is unsupported and Windows GPU hardware was not tested for this release. A package listing is not an equivalent hardware test on every platform.
For a rig owner, the practical checkpoint is whether the machine serves AI requests, which model its cards can handle, and how the pool records busy responses and accepted shares. Those observations address the change introduced here. The release improves a defined hand-off between occupied GPUs and the pool, with its test scope and inherited H16 behavior stated alongside it.
Source: Keryx Miner Supr release notes ↗ · Previous release and H16 scope ↗ · Official node H16 release ↗
Mining calculator ↗
