feat(cli): make the 250ms top-level tool-call queue delay configurable (HAPPY_TOOL_CALL_DELAY_MS) - #1753
Open
taiyiops wants to merge 1 commit into
Open
feat(cli): make the 250ms top-level tool-call queue delay configurable (HAPPY_TOOL_CALL_DELAY_MS)#1753taiyiops wants to merge 1 commit into
taiyiops wants to merge 1 commit into
Conversation
Top-level tool_use messages are held for 250ms so a fast tool result can be released together with them. On slow relays (self-hosted server + phone) that fixed delay is pure latency on every tool call. This reads HAPPY_TOOL_CALL_DELAY_MS (default 250, unchanged behavior; 0 = send immediately; invalid values fall back to 250). No change for users who don't set it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01QBfUsLSj8DBVvVmHSqCDqZ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
In
claudeRemoteLauncher.tsevery top-leveltool_usemessage is enqueued with a fixeddelay: 250so that a fast tool result can be released together with it (nice UX for sub-250ms tools). On slower setups (self-hosted server behind a jumpbox + phone client) that quarter second is added to every single tool call and is a noticeable part of the "why is it slow" feeling. This PR makes the delay configurable viaHAPPY_TOOL_CALL_DELAY_MS:250(exactly today's behavior)0→ tool_use is sent immediately (skips the delayed enqueue path entirely)250Nothing changes for anyone who doesn't set the variable.
Proof
Before: with the stock CLI,
tool_usemessages for top-level tools are always held up to 250ms (see the existingmessageQueue.enqueue(logMessage, { delay: 250, toolCallIds })branch).After, on my machine (
HAPPY_TOOL_CALL_DELAY_MS=0exported beforehappy daemon start, happy-cli built from this branch, self-hosted server):Sessions spawned from the phone app run normally; tool calls show up in the app without the 250ms hold, and with the variable unset the queue behaves exactly as before (the
delay: 250path is taken).tsc --noEmitclean; existing unit tests pass (acpAgentConfigsuite 8/8 as a smoke check of the package).I'm happy to add a debug log line on the enqueue path if you'd like a more explicit trace in the PR.
🤖 Generated with Claude Code
https://claude.ai/code/session_01QBfUsLSj8DBVvVmHSqCDqZ