[FEATURE] let the harness surface Claude's just-authored text for approval without a second model pass, especially on remote/mobile(token cost)
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
In workflows where Claude authors text and then shows it to the user for approval, Claude has to regenerate that text token-by-token to display it in the chat — even when it produced the same content moments earlier and often already wrote it to a file via a Write/Edit tool call. The content is generated twice: once to write it, once to show it. For approval-heavy workflows this roughly doubles output-token cost for zero new information.
I understand that any text the model emits is generated, and that this is inherent to how LLMs work. This is a request for a harness affordance, not a model change: a way to surface already-produced text — e.g. the content of a Write/Edit tool call, or a named file's contents.
Proposed Solution
Surface already-produced text — e.g. the content of a Write/Edit tool call, or a named file's contents — to the user as an approval-facing message, verbatim, without a second pass through the model. The model produces the text once; the harness would re-display that same content instead of the model re-emitting it.
Alternative Solutions
On desktop there's a workaround: don't render the text in chat at all — have the user read it in their open editor, since the file was just written. But that workaround collapses on remote control / mobile. Opening an edited file from a phone means navigating cloud storage and re-downloading it every time, which is impractical mid-conversation. So on mobile you genuinely need the text inline in the chat — which makes the regeneration cost unavoidable exactly where token budgets and convenience matter most. "View it in the editor" is a desktop-only answer; remote workflows need inline text, and inline text currently costs a full regeneration of content the model already wrote.
Priority
Medium - Would be very helpful
Feature Category
File operations
Use Case Example
A plugin/workflow (like my Sovereign Implementer plugin) that logs work sessions and drafts content (log entries, captured notes, task descriptions) for the user to approve. Each draft is written to a file once, then reproduced verbatim into the chat for approval — doubling the tokens for that content. On mobile, inline review is the only viable way to approve, so the cost can't be sidestepped.
Additional Context
Possible directions
- A primitive that renders a tool call's input/output (or a named file's contents) as a user-facing, approval-oriented message that the model does not regenerate.
- A "display verbatim" affordance the model can invoke to surface existing text as a message counted as shown-to-user.
Related but distinct
#39944 requests on-demand display of an existing file's contents (closed as duplicate). This request is different: it targets avoiding regeneration of text Claude just authored itself, specifically in a show-for-approval loop, plus the remote/mobile dimension that makes inline display unavoidable.
<img width="1200" height="611" alt="Image" src="https://github.com/user-attachments/assets/e86dd7b3-b763-4dbb-97b0-97aefa43e8d1" />
3 Comments
This is real for approval-heavy workflows. Write content once, then regenerate to display it = 2x tokens for the same text.
Until there's a harness fix, one workaround: instead of displaying full content in chat, output just a summary + file path. User can review in their editor.
For mobile where that doesn't work: at minimum, make sure the content you're writing is already compressed/concise before the first write. If your draft is 50 lines instead of 500, the 2x cost is more tolerable.
Would love a
show_fileprimitive that surfaces existing content without regeneration.Follow-up: the mirror direction (author-in-chat → write-to-file)
Worth recording a second direction the original request doesn't spell out, since both share the same root cost.
The request above is framed as write-to-file first, then re-display for approval (call it Direction A). But many approval-heavy workflows run the reverse: the model authors the text in chat first (that draft is the approval step), the user approves, and only then is it written to a file — because writing before approval would persist not-yet-approved content. In that ordering the doubling isn't the re-display; it's the Write/Edit call re-emitting the same text the model just showed in chat (a tool call's input is model-generated output too).
So the underlying waste — the same text produced twice, once for chat and once for the file — appears whichever end you start from:
Direction A: write → re-emit to show (what this issue asks to fix)
Direction B: show → re-emit to write (the approval-first flow)
I don't think B needs a separate primitive. If the Direction-A affordance exists — surface a Write/Edit's content, verbatim, as an approval-facing message with no second model pass — then an approval-first workflow can adopt write-first ordering and get the same saving, provided rejecting an approval can revert the just-written file. So it's really one primitive with a note: the biggest win is when the harness both (a) displays a Write's content without regeneration and (b) treats that displayed content as the approval surface — so "write once, show that exact thing, approve or revert" becomes the whole loop.
Flagging it so the fuller workflow context is on record; the core ask is unchanged.
+1 to the "write once, show that exact thing" primitive.
One extra motivation for building it generically (a
show_file(path, range?)that renders inline, rather than something coupled to Write/Edit approval): the same surface would let Claude present sections of _pre-existing files_ — docs, notes, configs — in chat without ingesting and re-emitting them, and would give subagent output a way into the transcript without the parent re-emitting it. Could even be an adaptation toSendUserFileto show the file inline.Same mechanism, three cost sinks closed.