How to work with a model and not lose access: rules, not rumours

Short version: accounts are closed over how you got access and what you do with your key, not over what you ask the model. The three usual causes are a shared account, automation dressed up as a human, and a key that leaked

Below: what the terms actually say, what happens on screen when something goes wrong, and how to arrange your work so that losing access costs you an evening rather than a project

Why this is worth reading at all

Search results on this topic come in two kinds. Adverts, where risk is never mentioned, and rumours from chats, where risk is inflated into "they ban you for any word"

Both are equally useless, because neither contains the one thing that matters: what the terms say. They are published, they are dull, and almost nobody reads them. What follows is a summary with links to the source so you can check it yourself

Source: Anthropic, Consumer Terms of Service

The three rules people break most

One: an account is for one person

A personal account is personal. One person, one login. Splitting a subscription three ways to save money is against the terms, and it is visible from the outside: requests arrive from different places at the same time

Team plans exist for teams, and they cost less than losing access in the middle of a delivery

Two: do not automate what is priced for a human

A subscription assumes a person at the keyboard. A script firing thousands of requests in the background is a different product: API access billed by volume

This is not greed. A subscription costs a fixed amount because a human physically cannot make more than a certain number of requests. A script can

Three: usage policy still applies

There is an acceptable use policy, and it covers what you build rather than what you ask. Building something to deceive people, to harass them or to break into systems is outside it. Asking the model about security, law, medicine or money is not

Source: Anthropic, Usage Policy

What the rules do not say, despite the rumours

You are not banned for topics. The model may decline a specific request. A refusal is an answer, not a mark on your record

You are not banned for writing code for a competitor. Your code stays yours, and the terms say so plainly

You are not banned for asking a lot. There are limits, and when you hit one you are asked to wait. That is a limit, not a punishment

One refusal is not a warning. It does not accumulate into anything

This list matters as much as the first one: fear of imagined rules is what drives people into arrangements where the risk is real

What it looks like on screen

Worth knowing in advance so you do not mistake a limit for a ban

A limit. A message saying you have reached the cap and when it resets. The account is fine and work continues in a few hours. This is by far the most common thing, and it is not a ban

A refusal. The model declines a specific request. The next question works normally

A sign-in failure. Login does not go through. Usually an expired session or the wrong email rather than a ban. Check password recovery: if the email arrives, the account is alive

A closed account. You can sign in, paid features are gone, and there is a notice in your account settings. That is a ban

Work through it in that order. People declare themselves banned after hitting an ordinary limit surprisingly often

Is your project ready to lose access

Seven checks. Every "no" is something that will hurt

• The project runs with one command, without the agent
• All the code is in a repository, not only on this laptop
• There is a project config file describing how it works
• Keys live in environment variables, not in code
• Your prompts are saved as a file, not only in chat history
• There is a command that checks the project and answers yes or no
• You know how production is deployed and how to roll it back

Seven yeses mean losing access is a change of tool and an evening of work. Three yeses mean you lose the project along with the access, and you will rebuild it from memory

What to do if access is already gone

First, do not panic about the code. Your code is on your disk and in your repository. The model never held it; the agent worked on your local files

Second, check the project runs without the agent. Start it by hand. If it starts, you lost a tool, not the work

Third, check where your keys are. If a model key was written into code and that code is in a public repository, revoke the key now, regardless of what happened to the account

Fourth, open your project config file. If you kept a CLAUDE.md, it describes how the project is built and run. With it, moving to a different agent takes an evening. Without it, a week

Fifth, change the tool, not the approach. Agents are built alike. Prompts carry over almost unchanged, as long as they do not name specific models

Key hygiene: where people actually get burned

You can lose access without any moderation involved. A leaked key is switched off faster than any ban, and it happens like this

The key goes into the repository: pasted in for a quick test and forgotten. The repository is made public. Automated scanners find it within minutes, because they look for exactly this. Someone else's requests run on your key, the bill climbs, the provider shuts it off

What to do about it

Keys only in environment variables. The file holding them never enters the repository: its name goes into the ignore list on day one

Scan before you make a repository public. Tools exist that search code and history for keys, including ones deleted from the current version. One run takes a minute

A separate key per project. Then a leak takes out one project rather than all of them

History counts. Removing a key from a file and committing is not enough: it is still in the history and it will be found. A key that has been in a public repository gets revoked, not hidden

Screenshots. A key visible in a screenshot posted while asking for help is a leaked key

How to work so that losing access decides nothing

This is the important part, and it is about how you work rather than about rules

Code and history in your repository, not in a chat. If the only place a solution lives is a conversation, you depend on that conversation. A commit after each working chunk fixes this entirely

A project config file in the repository. How it runs, what not to touch, how you want to work. Any agent reads it, and it moves between them

Keys in environment variables only. Not in code, not in chats, not in screenshots

Your prompts saved separately. Thirty prompts written for your own tasks are worth more than the subscription. Keep them as a file in the repository rather than in chat history

Checks that run without the agent. If quality depends on the agent having looked at it, you depend on the agent. A command that checks the project works always

Making limits last

A limit is not a ban, but hitting one mid-task is unpleasant. Three things that stretch the budget

Do not ask ten follow-ups instead of stating one task. Ten short exchanges cost more than one properly stated task, because the agent re-reads the context each time

Do not hand over the whole project when one file is needed. The more it reads, the more each step costs

Do not keep an endless session. A long conversation drags its whole history along. Finish a chunk, start a new conversation: the agent reads the config file and knows what it needs

Source: Claude Code documentation, Manage costs

Client data, separately

Building for a client adds an obligation that building for yourself does not have

Do not give the agent other people's personal data. Customer lists, phone numbers, identity documents and medical records do not belong in a conversation with a model. Made-up data is enough for debugging, and this is a legal requirement rather than caution

Ask the client whether their code may leave their systems. For some companies it is contractually forbidden. "We did not know" is not an answer

Keep production and practice databases apart. An agent with access to a production database will eventually do something you did not ask for

Team plans cost less than they look

If there are two or three of you, count the cost of downtime rather than the price per seat

One shared account across three people saves two subscriptions and creates a risk for all three at once: what gets closed is the account, not a share of it. A day of downtime in the middle of a delivery costs more than the month you saved

Team plans also separate data. Each person has their own history, and one client's code does not mix with another's. When a client asks who had access to their code, "the three of us worked from one account" is not an answer they will like

What moves between agents and what does not

Moves almost unchanged: prompts, as long as they name no models; the project config file; project structure; checks that run as a command; your own working rules

Moves with edits: keyboard shortcuts and commands, which differ everywhere; permission settings; connected MCP servers, which are wired up differently

Does not move: conversation history, accumulated session context, an agent's familiarity with your style

Hence a rule worth adopting on day one: anything you want to keep belongs in a file in the repository, not in an agent's head

In short

• Bans are about how you got access, not about what you ask
• A shared account is closed as a whole, not as a share
• A leaked key is switched off faster than any moderation, and history counts
• Losing access should not sink the project: code in the repository, keys in the environment, prompts in a file, checks as a command
• A project config file moves you to a different agent in an evening
• Other people's personal data never goes into a conversation with a model

Working through an intermediary, and why the shape matters

In some countries the service is not sold at all, and a market of intermediaries grows around that. The names change constantly; the shape does not, and the shape is what carries the risk

"We will pay for your subscription with our card." The account is formally yours, the payment is not. Medium risk: you hold the account, but the payment method can be flagged, and then it closes

"Here is access to our account." The account, the email and the password recovery are someone else's. You are renting, not buying, and you can be switched off at any moment with nobody to appeal to

"Our bot, same model, cheaper." This is a different product. You get a chat with a model through a middleman, not an agent working on your files. For anything involving a real project it does not fit at all: the agent has to see the folder

"A key on a monthly subscription." Worth asking whose key it is. If one key is handed to ten people, it gets switched off for all ten at once

The shared tell across all four: none of them says what happens if access disappears mid-month. That silence is the answer

Five questions to ask before paying

Whose email is the account registered to. If not yours, you are renting

How many people use it. "Only you" is worth testing: ask for the password to be changed and see whether anyone else keeps working

What happens on a ban. Is there a refund for the unused month, and in what form

Can the history be exported. If not, do not keep anything important in that conversation

Is there a contract. Not for court, but as a seriousness check: a service that has been running a year has one

What belongs in the config file so it actually saves you

Since it is what carries you between agents, it is worth knowing what goes in

Required: how the project runs, which command checks it, what must not be touched, and where the keys live (where, not the keys themselves)

Useful: decisions taken and why this option was chosen. A month later neither the agent nor you remember why the database is shaped that way, and you rebuild it back the other way

Harmful: long essays about code style that nobody reads. The file should fit on one screen