SASVA High Token/API Usage Reported Without Matching Visible Chat Activity
Problem
An organization's SASVA usage/billing dashboard shows a spike in token consumption or API usage for a given day or user, but the visible chat history for that user does not show a corresponding volume of activity — the number of prompts/messages appears far too low to account for the reported usage.
Symptoms
- Usage dashboard reports a token/cost spike disproportionate to the number of visible chat turns.
- The affected user's local chat panel shows a normal or low number of messages for that period.
- The spike often coincides with a network interruption, extension crash, or forced VS Code reload during an active session.
Root Cause
When a chat request is interrupted client-side (network drop, VS Code crash/reload, or the extension being force-closed) after the request has already reached the SASVA backend, the backend may continue processing and generating the response even though the client is no longer listening. Depending on retry/reconnect behavior, the client can also resubmit a prompt that was already in flight, causing it to be processed twice server-side while only appearing once (or not at all) in the local chat history.
Because token/usage accounting happens server-side at the point of generation, these orphaned or duplicated generations are billed even though the user never saw the output — explaining the mismatch between visible chat activity and reported usage.
Resolution/Workaround
Immediate mitigation for end users
- Avoid force-closing VS Code or killing the process while a SASVA response is actively generating (streaming). Use "Stop" in the chat UI to cancel a request cleanly instead.
- After any network interruption during an active chat request, do not immediately resend the same prompt — reload the VS Code window first and check whether the response actually completed in the background/history before resubmitting.
For administrators investigating a usage spike
- Pull the usage/audit log for the affected user and time window from the SASVA admin dashboard, noting exact timestamps of the spike.
- Cross-reference with the user's reported activity: ask whether a network drop, laptop sleep, or forced VS Code restart occurred during that window.
- Escalate confirmed orphaned/duplicated generations to SASVA support for verification and potential usage credit, since this is a platform-side reconciliation issue rather than a user error.
Escalation
Report suspected orphaned-generation usage spikes to sasva_support_in@persistent.com with the organization name, affected user, and exact timestamp range from the usage dashboard. Include whether a network/crash event is known to have occurred at that time.
Comments