Synchronous model call blocks the event loop in get_next_action

Description

get_next_action() is asynchronous, but its gpt-4 branch invokes the synchronous call_gpt_4o() function directly.

If the model request takes time to complete, the synchronous call occupies the event-loop thread for the duration of the request, preventing other scheduled asynchronous work from progressing.

I reproduced this behavior with a controlled local replacement for call_gpt_4o() that blocks for 0.25 seconds. No model API or network endpoint is contacted.

Observed behavior:

Selected model: gpt-4 Simulated synchronous model-call delay: 0.25 s get_next_action() elapsed time: approximately 0.252 s Event-loop timer delay: approximately 0.232 s External network contacted: No

This means latency in the synchronous model request can directly stall unrelated coroutines and timers running on the same event loop.

Affected Version

Confirmed on:

self-operating-computer==1.5.8 operate/models/apis.py:34-39 get_next_action()

PoC runtime:

Python 3.10.12

Other versions have not been tested.

Reproduction

The attached PoC loads the released get_next_action() implementation and executes its gpt-4 branch.

call_gpt_4o() is replaced with a local synchronous function that sleeps for 0.25 seconds before returning a fixed result. At the same time, an event-loop timer is scheduled to fire after 0.02 seconds.

Observed result:

blocking model-call delay: 0.25 s asynchronous function elapsed time: approximately 0.252 s event-loop timer delay: approximately 0.232 s synchronous model-call event-loop blocking reproduced: yes

No actual model request or external network request is made during reproduction.

Attachment

run.py