I would like to suggest a guardrail for ChatGPT Work: large binary data and oversized tool output should not be allowed to consume the active conversation context when a file-native transport or artifact reference would be more appropriate.
What happened
During a recent technical Work session, ChatGPT needed to move a large executable artifact between environments.
Instead of using a file-native transfer mechanism, the Work agent attempted to transport the binary by compressing it and representing it as a very large base64 text payload.
The transfer failed and left an incomplete .b64 artifact of approximately 29 MB.
Shortly afterward, a relatively fresh Work conversation became effectively unusable because it reached its conversation limit.
I cannot prove that the base64 transfer was the sole cause of the conversation reaching its limit. However, the timing strongly suggests that very large tool/text payloads can consume a substantial amount of a Work conversation’s practical capacity.
Why this matters more in Work
In a normal chat, losing conversation capacity is inconvenient.
In Work, the conversation may already contain:
-
long-running execution state
-
tool results
-
files and artifacts
-
completed implementation steps
-
debugging history
-
environment state
-
expensive Work usage
A single inappropriate transport decision by the agent should not be able to consume a large fraction of the remaining conversation capacity.
The user may not even see the full payload that is being moved through the tool layer, so there is very little opportunity to stop it before the damage is done.
Suggested protections
1. Detect binary-through-text transport
If Work is about to send a very large:
-
base64 payload
-
hex dump
-
compressed binary represented as text
-
multi-megabyte tool argument or response
the system should recognize that this is probably not an appropriate use of the conversational/tool context.
It could instead recommend or automatically use:
-
direct file transfer
-
artifact/file storage
-
signed temporary download/upload
-
local filesystem transfer
-
another file-native mechanism
depending on the available tools.
2. Keep large tool results out of active context
Large tool outputs should ideally be stored externally and represented inside the conversation by something like:
-
artifact ID
-
file reference
-
size
-
checksum
-
short summary
rather than inserting the full payload into the active model context.
The model could retrieve a relevant range later if it actually needs it.
3. Preflight warning
If an operation is expected to consume an unusually large amount of conversation capacity, Work could warn before executing it:
This operation will produce or transfer a very large amount of data and may significantly reduce the remaining conversation capacity. Use file transfer instead?
For autonomous Work execution, a reasonable safe threshold could simply switch to the file-native path automatically.
4. Tool-output contribution to the capacity indicator
If ChatGPT eventually exposes a conversation-capacity indicator, it would be useful if tool I/O were included.
A conversation with 20 visible messages may be much heavier than a conversation with 200 messages if those 20 turns moved very large tool payloads.
Important distinction
I am not asking for arbitrary restrictions on large files.
Large files are normal in engineering and research workflows.
The issue is specifically transporting the contents of those files through the conversational/tool text channel when the system already has, or could provide, a more appropriate file transport mechanism.
A useful rule could be:
Large artifact → store/transfer the artifact, keep only its reference and necessary metadata in conversation context.
This would make long-running Work sessions considerably more robust and would reduce the risk of an agent accidentally exhausting the conversation that is coordinating its own work.