How network conditions factor in

Network conditions affect every remote call tCode makes the same way they would affect any other tool that talks to a server over the network: a slow or unstable connection adds latency to each individual round trip with the model.

This latency cost is independent of how complex the underlying task actually is; a simple one-step request and a complex multi-step one both pay the same per-round-trip network cost, just a different number of times.

In practice this shows up as the same exact turn taking noticeably longer on a poor connection than on a good one, with nothing about the request itself or the codebase having changed between the two runs.

A turn with many tool calls is more exposed to this effect than a single-step one, purely because it involves more round trips for the same connection quality to add latency to; the effect compounds with how many exchanges a turn genuinely needs.

There is no local caching mechanism that would let a poor connection's effect diminish over the course of a long session; each round trip pays the same latency cost independently, regardless of how many came before it.