Skip to main content

​
Symptoms

You generate images on your own computer with a script, or with a Skill inside an AI coding tool (Codex, Claude Code, etc.), and see the following:
  • 1K and 2K images mostly come back, but 4K images or requests with several reference images often never arrive
  • The program shows no error at all and keeps waiting until your own timeout (600 s, 900 s) fires with read timed out, or until you kill it
  • Nothing arrives while it waits, not a single byte, not even the response headers (no HTTP status code)
  • In the call log, the matching request ended 30-90 seconds after submission, marked as failed with error code write_response_body_failed, and was not billed
  • The program bypasses the proxy and connects directly: you set NO_PROXY or trust_env=False, or added a direct rule for apiyi.com in your proxy app

​
Short Answer

The image was already generated. It got lost on its way back to your computer.A 4K image response is tens of MB. On some home broadband and office networks, a direct connection to overseas nodes gets cut a few dozen KB into a response that large: the server side sees the disconnect, while your computer receives nothing, so your program just keeps waiting. Routing image requests through your proxy (VPN) usually fixes it. These failures are not billed.

​
Why This Happens

A non-streaming image request returns its result all at once at the end: In the cases we investigated, the server finished the image within 40-60 seconds and started sending it back. The response headers and the first 64-135 KB had already gone out, and about 1 second later the connection was cut. The customer’s program received 0 bytes and never got any “connection closed” signal, so it waited until its own timeout. During the same period:
  • Small 1K and 2K images from the same computer mostly arrived normally
  • Requests from the same account that went out through the proxy delivered nearly every 40-50 MB 4K image
So the problem is that the direct line between your computer and APIYI cannot carry large responses. The model did not fail, and the network is not fully down. A connectivity test with curl or a browser looks perfectly healthy on such a line (small requests return in well under a second), which makes this hard to spot on your own.
This is the exact opposite of Image Calls Drop After About 90 Seconds Behind a Proxy?. There, the proxy kills the connection while it sits idle waiting for the image, and the fix is to connect directly. Here, the direct line cannot carry the large response, and the fix is to use the proxy. Which route works for you is decided by the comparison test below.

​
How to Confirm

1

Check the call log

Find the matching time range in the call log. If your program is still waiting while the log already shows a failed write_response_body_failed record, the server finished the image and started sending it back. The connection broke on the way back.
2

See whether larger images fail more

With the same prompt and reference images, if 1K / 2K come back and 4K does not, this is almost certainly the cause.
3

Check whether your program actually uses the proxy

Many AI coding tools start Python / Node child processes that do not read the system proxy. Even with Clash in global mode, those processes may still connect directly. Run this in the same terminal or tool:
If it prints your local broadband IP, requests from that environment go out directly.
4

Alternate proxy and direct runs with a few 4K images

Run them in alternating order: proxy, direct, proxy, direct. Do not run 5 of one kind and then 5 of the other, or a temporary network fluctuation can mislead you. If the proxy runs succeed reliably and the direct runs often hang, that confirms it.

​
Solutions

Remove whatever setting makes the program bypass the proxy, so image requests go through it:
  • Remove apiyi.com from NO_PROXY
  • Python requests / httpx: remove trust_env=False
  • Python urllib: do not build the opener with ProxyHandler({})
  • Node.js: native fetch does not use a proxy by default; specify one explicitly with a library such as ProxyAgent
If the child process does not read the system proxy, set the proxy address in an environment variable before running it (replace the port with your proxy app’s HTTP port):
Both problems can happen at once. If, after switching to the proxy, requests start dropping in batches at 90-180 seconds, that is the proxy node’s idle timeout; see Image Calls Drop After About 90 Seconds Behind a Proxy?. In that case, switch to a proxy node with a longer idle timeout first, or run the image program on a server instead.

​
Set a sensible timeout too

In this situation your program never receives a disconnect signal, so its own timeout is the only way to notice the failure. With a 900-second timeout, you wait 15 minutes just to learn the request failed. A non-streaming image request carries no data while the image is being generated, so the read timeout cannot be shorter than the generation time. Set it to a bit longer than a normal generation: about 300 seconds for 4K, about 180 seconds for 1K/2K. After a timeout, check the call log first to see whether the request was billed, then decide whether to retry, so you do not generate the same image twice.

​
Will This Happen After Deploying to a Server?

Lines from cloud servers in mainland China or overseas to APIYI are usually far better than home broadband, so this mainly shows up in local development. If a server also sees “headers arrive, then the body breaks off halfway”, follow Troubleshooting Image API Connection Drops.

​
Common Questions

No. Requests recorded as write_response_body_failed in the call log are not billed. The charge shown on each log record is authoritative.
A connectivity test sends and receives only a few hundred bytes and finishes in well under a second. The problem only appears when a response of tens of MB is transferred, which a small request cannot reveal.
Once a request is submitted, the server generates the image as usual. So if you kill the program and retry immediately, two requests may be generating at the same time. In the situation described here, though, by the time you kill the program the server has usually long finished the image and failed to send it back, so nothing is billed.
The larger the response, the more likely it gets cut, but there is no hard size above which it always fails. A 2K response is still a few MB, so it can be hit on a bad line too, just much less often.

Image Calls Drop After About 90 Seconds Behind a Proxy?

The opposite problem: the proxy closes idle connections; fix it by connecting directly

Troubleshooting Image API Connection Drops

Full troubleshooting for write_response_body_failed, SSL EOF, and other disconnect errors

The log says the call finished and was billed, but my client never received a response — how do I troubleshoot?

Where the gap between logged duration and client wait time comes from

How to view my call records?

Check each request’s status and charge by time range