Synchronous Instruction Execution Tool

[00000O00000]

In most cases, AI only needs the complete result of an instruction execution. After executing the instruction, it should wait until the instruction is completed and directly return all results, rather than making multiple calls to check the outcome function. This not only consumes a large number of tokens but also wastes additional time. So why not design a synchronous call for the specified function?

[wonderwhy-er]

Because it will timeout anyways due to how clients work There are also blocking never returning calls Synchronous was first implementation I moved away from

As for the problem you describe, aka it making multiple calls to the tool I am exploring how to change that behavior for the better.

Can you share more on what kinds of use cases you have in mind? Usually if shell command returns in 30s it will immediatly return and not require addition read call

[fezzzza]

I came here with similar comments. Sometimes the nature of the call, for example, getting the PID of a currently running process and then killing that process only needs a quick synchronous call, instead of writing the command returning to the interface and then writing another command to read the results of that command, which is wasteful of tokens and context window. Sometimes Claude wants to run the dev server, and in that set of circumstances, a synchronous command would just cause a hang. I would propose a timeout to default at 1 minute and give Claude control over the timeout. If the command completes within 1 minute, the results are shown directly. If the results are not available within 1 minute, then Claude is instructed. If the command completes within 1 minute, then Claude gets a return indicating that the process is still going on.

Sometimes, if Claude is trying to install something, for example, install a node module or compile some code then we know that the process may take some time. Whether or not Claude fully understands the concept of time, I'm not entirely sure (It can probably be briefed reasonably well in the user settings prompt), but it may be an idea to provide Claude with a sleep timer to allow Claude to pause processing for five minutes for the compilation process to complete and that would save him having to hammer on the check progress tool. hammering on the check progress tool only serves to fill up the very small context space and waste tokens. ( I note this is a dupe of #101 )

UPDATE: I think I'm coming to the realisation that Claude is possibly sending multiple tool requests in a single message, and so everything I've put in here might not have very much meaning in that context. Either that or maybe Anthropic are measuring message length in an unexpected way. The advantages are that we can take advantage of fewer message requests (and possibly less token usage) because the message only comes to an end when Claude has finished a bit of a sprint. We don't want to do anything that would discourage that because this accounts for the comparative speed that I'm seeing compared to other solutions. Claude's coding ability is incredibly efficient in this context.

[fezzzza]

I notice that execute_command may now have been improved by adding "timeout_ms" as an optional operand, for example:

execute_command
{
  `command`: `cd /path/to/project && npm run tauri build --debug`,
  `timeout_ms`: 120000
}

However, the system does not seem to implement the timeout. Claude immediately follows up with:

read_output
{
  `pid`: 602754
}

and

force_terminate
Request

{
  `pid`: 602754
}

The system should block Claude from being able to do anything until either the timeout has expired or the command has completed. If no timeout is stated then a default should be used. I suggest 1 minute.

I am using Claude Desktop 0.9.3 (using a port) with Claude 3.7 and 4.0, on Linux Mint 21.3