When asking Codex App Server for turns, it embeds full generated images data with each turn for the current page. For a thread that contains just 1 turn with 7 generated images, that's a 27 megabyte websocket frame. If you have more images per turn, more turns with generated images, higher res images etc, this hits user RAM hard.
For locally running CAS, generated image bytes aren't needed at all - the CAS client already has access to the filesystem and can read savedPath directly. For remote clients, generated image bytes would be better off loaded separately from general turn data, or least there should be an option to do that.
As a workaround, I'm doing manual streaming and parsing of CAS's websocket/json data to drop the image bytes field on the fly and avoid hitting user's RAM, if anyone else is looking for a solution. This still wastes tens or hundreds megabytes of i/o traffic between your CAS client and CAS because you have to physically consume that websocket frame, but at least RAM gets saved.
When asking Codex App Server for turns, it embeds full generated images data with each turn for the current page. For a thread that contains just 1 turn with 7 generated images, that's a 27 megabyte websocket frame. If you have more images per turn, more turns with generated images, higher res images etc, this hits user RAM hard.
For locally running CAS, generated image bytes aren't needed at all - the CAS client already has access to the filesystem and can read
savedPathdirectly. For remote clients, generated image bytes would be better off loaded separately from general turn data, or least there should be an option to do that.As a workaround, I'm doing manual streaming and parsing of CAS's websocket/json data to drop the image bytes field on the fly and avoid hitting user's RAM, if anyone else is looking for a solution. This still wastes tens or hundreds megabytes of i/o traffic between your CAS client and CAS because you have to physically consume that websocket frame, but at least RAM gets saved.