The cost gap between local and full regeneration should be visible to the user

What it is

“Rewrite this sentence” and “rewrite the whole piece” differ in time, billing, and blast radius on the model side: local is usually shorter, cheaper, smaller. If both acts share one Regenerate button, people cannot choose on cost. They pick whichever feels safer — often the full rewrite, because local looks like a gamble. The cost gap has to be visible. Otherwise a local entry, even if it exists, is not treated as a real second grade of operation.

What should be visible is the difference a decision can use: how long to wait, which region will move, what quota this run will burn. Not a GPU utilisation overlay.

Why it happens

Choice needs comparable attributes. When two regenerations share icon, copy, and waiting animation, the attributes are flattened and the decision falls back to habit. Habit favours the whole, because its mental model is simple (“draw another sample”) while local still requires naming a span. When local is in fact cheaper and full is in fact dearer, an invisible price gap drives all traffic to the dear side. Local then looks unused in the data and gets removed — a false demand signal made by the interface.

Wait time is itself a cost. If local still runs full inference and only pastes one sentence back, experienced latency matches the whole, and people conclude “so-called local is not local.” Visibility includes honest latency. It does not include painting the same wait as a different animation.

Studying it

Offer both entries on the same task and manipulate cost information: none / estimated duration / region that will move / quota gap. Dependent variables: take-up of the local entry, time to finish, count of unnecessary full rewrites. Then measure the damage of “fake local” (backend still infers the whole): if latency matches full, take-up should fall back near zero.

Do not stop at “do you think local is cheaper.” Willingness to pay and actual clicks often split; the primary endpoint is choice under real latency and real span.

Where it stops holding

When the two acts are close in backend cost (short text, full context must be recomputed anyway), stressing a price gap fabricates a contrast. Merge them and say so. On unlimited monthly plans, money drops out of the decision; span and latency remain. In accessible use the gap must be spoken as text, not only as a progress-bar colour. On offline or on-device models where the latency gap is tiny, visibility should shift to “which sentences will change,” not seconds.

Applying it

• Make local and full two distinguishable acts, and write beside each the wait magnitude and the coverage (“about two sentences · a few seconds” versus “full rewrite · longer”).
• Highlight the span before send. If the backend cannot actually do local inference, do not use the local name; say “rewrite the whole and try to touch only this,” so the price gap is not a fake.
• When quota exists, mark both acts in the same unit so they can be compared, rather than popping a message only when the quota is gone.
• Check: on a task that can truly infer locally, hide cost copy for a week, then show it for a week, and compare the local entry’s share. If share does not rise, check whether latency actually differs — print measured duration next to the button; if the gap is below a just-noticeable wait, stop advertising “faster.”

Related

• Same group: L2.12.1 A local edit has to locate the part the user meant; failed reference is the main break · L2.12.2 Changes in parts that were not mentioned destroy trust in the edit function · L2.12.3 Successive edits accumulate drift until the result no longer matches the original goal · L2.12.4 Any historical version must be restorable; undo-last-step cannot carry iteration
• Nearby: L2.05 Iterative Revision · L1.12 Latency and Streaming Experience · L2.04 Complementarity of Parameter Controls and Natural Language
• Search terms: visible cost of local vs full regen · interaction cost · regen cost transparency