After Cancel, the old answer can still arrive.

The successful version of an AI writing assistant is easy to picture: enter a sentence, wait, accept a better sentence. The less tidy version starts when someone cancels, edits the input and tries again.

If the first answer arrives last and replaces the second one, the Cancel button was a visual promise the application did not keep. I would treat permission to update the screen as a separate piece of state.

Stopping work and discarding an answer are different

The browser's AbortController API can signal cancellation to supported asynchronous operations, including fetch. A model runtime or another operation must support the mechanism actually used. Passing an AbortSignal somewhere does not establish that every downstream computation stopped.

The interface still needs a rule for late results. Assign a version to each request. When input changes, a new request begins, or the user cancels, invalidate the old version. Only a result belonging to the current version may be applied.

let version = 0;

async function suggest(input) {
  const requestVersion = ++version;
  const result = await generateSuggestion(input);
  if (requestVersion !== version) return;
  showSuggestion(result);
}

function cancelSuggestion() {
  version += 1;
}

This is a minimal illustration of stale-result rejection. It omits transport cancellation, error handling, component teardown and the application's input-change wiring. A local check reversed two fake completions and confirmed that an invalidated answer was ignored. It does not test a real model, network cancellation or browser memory use.

The original text should remain available, too. Generating a proposal, accepting it and transmitting a message are three events. Completing the first one should not silently perform the other two.

The original task should still have an exit

A contact form is for sending a message. If an optional local model needs a download, someone who does not want the assistance should still be able to type and submit normally. Loading the model should not become a new requirement for the old task.

I would test the awkward orderings deliberately: cancel just before completion, change the input while work is running, start a second request and finish the first one last. Fake responses make those sequences repeatable. Real runtime compatibility remains another check.

The useful boundary is simple: a completed computation is not automatically an instruction to change the screen. The interface decides whether that answer still belongs there.

한국어 글: 브라우저 AI에도 취소한 뒤의 시간이 있다