Restored Access Is Not the Same as Usage Attribution

An account-security review can be necessary — and still leave the operational question unanswered

When a provider sees unusual-looking activity, it should protect the account and investigate. That is a sensible security response.

But an account-security review and a usage audit are not the same thing.

Earlier this summer, I documented unexpected movement in the usage dashboard on my Claude Max 20x account and asked for an itemised explanation of the activity counted against the allowance. Later, the account was disabled and the Max 20x subscription was cancelled. After I supplied information requested by Anthropic’s safeguards process, account access was reinstated. The subscription did not automatically resume.

That restoration of access was welcome. It did not answer the question that began the case: what precise activity had been counted against the usage allowance during the periods I had documented?

I was not provided with an itemised record for those periods showing timestamps, product surface, model or service class, session or device attribution, and usage attributed to each event.

What restoration does — and does not — establish

It is important to be exact here.

An account being restored does not prove the original usage reading was wrong. Equally, a temporary restriction does not prove that a customer, their device or a specific third-party tool was responsible for disputed activity.

It means the provider has taken steps within its own security and review process. Restoring account access is also not the same as restoring a paid plan, and it is not the same as providing an itemised usage record.

That distinction matters because security language can quickly outrun the available evidence. I reviewed my own setup, including local tools and account connections, and supplied the requested information. I have no basis to say that a particular application, device, person or service caused the usage I queried — and I will not make that claim.

What remains reasonable is a request for attribution. When a paid service restricts an account or materially affects a customer’s ability to work, the customer needs enough information to understand what happened.

Two separate tracks: security and evidence

If your AI account appears to behave unexpectedly, separate your response into two tracks.

1. Secure the account

• Change your password if there is any concern about access.
• Review active devices and sessions.
• Revoke access you do not recognise.
• Review connected apps, extensions, integrations and automated workflows.
• Pause or disable scheduled work while you investigate.

Anthropic’s current help guidance explains how users can review active sessions and log out across sessions. These are sensible first actions, regardless of the eventual cause.

2. Preserve the evidence

• Take dated screenshots before and after relevant periods.
• Record reset times and usage percentages shown in the product.
• Keep a concise activity log: what you did, what you did not do, and which tools were left connected.
• Save support correspondence privately.
• Ask support for a bounded, itemised record rather than a broad explanation.

The aim is not to win an argument on social media. It is to create a factual timeline that can be checked.

Why an itemised audit matters

A percentage bar is useful for a quick status check. It is not enough for a business that needs to reconcile its operational use with a paid allowance.

For a material usage event, a customer should be able to see at least:

• timestamp and relevant usage window;
• product surface, such as web, desktop, code, integration or scheduled task;
• model or service class;
• session, device or authorised integration identifier;
• whether work was directly initiated, scheduled or automated; and
• a plain-language explanation of how that event affected the limit.

That record can protect privacy. It does not need to disclose prompts, proprietary system behaviour or confidential data. It simply needs to let a customer distinguish normal activity, automated activity, connected activity and possible account-security concerns.

The operational lesson

AI is becoming a core working layer for marketing, research, coding, customer service and internal operations. As that happens, reliability cannot stop at the model response.

Businesses also need visibility over permissions, integrations, sessions, automation and usage. Providers need tools that help customers investigate anomalies fairly. And customers need to resist filling gaps in the evidence with confident speculation.

Restored access was an important step in my case. The unanswered usage-attribution question is why I believe itemised, privacy-preserving AI usage records should become a normal operational control.

Related reading

• Claude Max Usage Increasing While Idle? What to Check

Official resources

• Anthropic: Manage usage credits for paid Claude plans
• Anthropic: Managing your active sessions
• Anthropic: How to log out of all active sessions

This is a first-person account of Grant De Swardt’s experience. It does not state or imply that Anthropic confirmed a product defect, account compromise, malware incident, or a cause connected to a particular application.