Treat Client Abort and Model Cancellation as Different Events

Summary: A cancelled browser request does not prove that remote model execution stopped. Track cancellation intent and endpoint state separately.
AbortController can stop a browser request or application fetch. It cannot, by itself, establish what happened after the remote endpoint accepted the work.
This distinction matters for long-running text, image, and video operations. The user may leave while the remote job continues.
Create a server-side request ID and persist cancellation intent. A useful state model can distinguish running, cancel_requested, cancel_acknowledged, detached, and completed_late.
The flow is: receive cancellation -> persist intent -> check verified endpoint capability -> send cancellation or detach -> apply the late-result policy.
VectorNode is our product. Its public API is described as providing one API key for GPT, Claude, Gemini, DeepSeek, Qwen, Midjourney, Kling, and other models, with unified credits, transparent pricing, and usage logs. It can be placed behind an application-owned cancellation lifecycle: https://www.vectronode.com
Disclosure: VectorNode is our product, and this link is included for readers who want to explore it.
Do not mark remote execution as stopped unless the endpoint provides a relevant, verified acknowledgement. When cancellation is unavailable or unclear, stop local polling and decide whether late output should be discarded, retained, or reviewed.
Usage logs may help correlate calls after the event. They should not be treated as cancellation acknowledgements.
A clear unknown state is more accurate than a confident but unsupported “cancelled” label.