What Exactly Is a Claude Code "Account"?

Before we start

Over the past two years, "I want to use Claude Code / Codex" has gone from install a package, paste a key to something that genuinely requires a technical decision.

The same handful of questions keeps coming up in the community, and the people asking are rarely beginners:

• "I bought API credit. Why does the web app still ask me to log in?"
• "Same account. It ran fine yesterday, today it just spins. What changed?"
• "Why do relay providers make such a fuss about IPs? Can't I just plug in a more expensive proxy myself?"
• "Hosting providers say 'once assigned, the environment does not change.' Isn't that awfully conservative? Wouldn't swapping to a better one be faster?"
• "A long task ran for two minutes and died halfway. Why is retrying it actually worse?"

These look unrelated. They all point at the same thing: most people treat "account" as an indivisible atom, when it is really three kinds of credential + two levels of quota window + a set of identity-consistency constraints stacked on top of each other. Until you separate those layers, none of the questions above has an answer.

This article does not teach you how to game anything, and it contains no adversarial recipes. It does exactly one thing: make the engineering constraints explicit — why things are the way they are, and where each approach hits its ceiling under those constraints.

Roughly 10,000 words, with five explanatory diagrams. By the end you should be able to answer all five questions yourself, and know which path is yours.

Contents

• Chapter 1 Credentials: three different things hang off one account
  • 1.1 The conclusion first
  • 1.2 Two paths, forked at the billing system
  • 1.3 API keys: stateless metering
  • 1.4 OAuth tokens: an identity carrying subscription quota
  • 1.5 Session credentials: the web layer
  • 1.6 The derivation chain: what can produce what
• Chapter 2 Quota: how rolling windows shape what you feel
  • 2.1 Two levels of window
  • 2.2 Windows are counted per account
  • 2.3 The queueing effect when an account is shared
  • 2.4 Reading a 429: not every "rate limit" means the same thing
  • 2.5 Why "just split it evenly" does not work under a window model
• Chapter 3 Identity consistency: the risk is not being used, it is looking like someone else
  • 3.1 What the server can observe
  • 3.2 Consistency beats "better"
  • 3.3 Why a fixed environment is a constraint, not laziness
  • 3.4 A boundary that has to be stated
• Chapter 4 Multi-tenant isolation: where sharing hits its ceiling
  • 4.1 Session isolation
  • 4.2 Quota isolation
  • 4.3 Fault isolation
  • 4.4 Can you have all three
• Chapter 5 Streaming: the hardest part of any relay layer
  • 5.1 Why you cannot "buffer then forward"
  • 5.2 Four ways to break, all identical from outside
  • 5.3 Retries are not idempotent
  • 5.4 The timeout dilemma
  • 5.5 Backpressure, the part everyone forgets
• Chapter 6 Takeover and restore: what a hosting client does on your machine
  • 6.1 The problem
  • 6.2 Back up, overwrite, restore
  • 6.3 Merge, do not replace
  • 6.4 Idempotency and "first backup wins"
  • 6.5 Crash safety: what happens if the power cuts mid-way
  • 6.6 Symmetry on the way out
• Chapter 7 Observability: what you should insist on seeing
  • 7.1 A blunt criterion
  • 7.2 What specifically should be visible
  • 7.3 One anti-pattern
• Chapter 8 Device binding: why credentials are issued to "this machine"
  • 8.1 One login, several machines
  • 8.2 Why revocation has to be a first-class citizen
• Chapter 9 Choosing: one decision table
  • 9.1 Do not only count the cost of getting in
  • 9.2 These two are not mutually exclusive
• Chapter 10 Nine misconceptions, in one table
• Closing

Chapter 1 Credentials: three different things hang off one account

1.1 The conclusion first

A Claude or ChatGPT account is not, technically, "one thing". It derives at least three kinds of credential, and they are not equivalent:

The counter-intuitive column — and the one people trip over — is the last one: the three credentials open different doors, and they cannot substitute for one another.

1.2 Two paths, forked at the billing system

Most people assume these are just "different entrances to the same model". Technically they do reach the same weights, but they are two completely separate systems along three axes: billing, authentication and rate limiting:

The split is deliberate, because the two audiences want incompatible things: programmatic callers want a predictable unit price, horizontally scalable concurrency, and no dependency on "someone being online" — a stateless key implements that best. Individual subscribers want "one price, use it freely", and to avoid being sunk by a handful of heavy users the vendor must introduce quota; for quota to work, consumption has to be attributable to a specific person — which requires an identity, which requires a login.

Once you see that, a whole family of "why can't I just…" questions dissolves. It is not that vendors refuse to bridge the two. It is that bridging them leaves the two billing models unable to reconcile.

1.3 API keys: stateless metering

The defining property of an API key is stateless metering — it is bound to no login session, it does not care which machine or client you use, and the server accepts it on sight; billing is settled per token.

Because it is stateless, it is ideal for programmatic use (CI, backend services, batch jobs) with nobody sitting there logging in.

And because it is stateless, it cannot open any human-facing surface. The web app and the desktop client do not want "something billable", they want "somebody logged in" — and on the server those are two entirely different authentication paths.

That is the complete answer to "I bought API credit, why does the web app still want a login?". The product is not being awkward; the thing in your hand was never meant to open a browser session.

1.4 OAuth tokens: an identity carrying subscription quota

The second credential type is an OAuth token, usually a pair: a short-lived access token and a refresh token that keeps it alive.

The fundamental difference from an API key is provenance:

• An API key is created by clicking a button in a console. It comes from nowhere.
• An OAuth token is exchanged out of an already logged-in session — somebody must actually have logged in before a token can be issued at all.

Two consequences:

It draws on subscription quota, not metered credit. When you run tasks through the official CLI or an editor extension, you consume the allowance inside your subscription plan — which is why, with the same vendor, "subscription" and "API" are two separate ledgers.

It has a prerequisite. Whether a token can be issued depends on the tier of the account behind the source session. A free-tier session usually cannot produce a token usable by the CLI or editor extensions — that is not some middleman withholding it, it is the authorisation scope being fixed at issue time.

The practical implication is blunt: if you intend to use the CLI or an editor extension, "I have an account" must be completed to "I have a paid-tier account". Confirm that before you buy, not halfway through setup.

1.5 Session credentials: the web layer

The third type is a web session credential — the cookie in your browser.

Its defining property is that it is strongly tied to the environment it was issued in. A session is minted during one specific login, and the server does observe what kind of environment that session subsequently shows up in. A sharp change in environment triggering re-verification is entirely normal server behaviour.

Chapter 3 expands on this, because it carries the heaviest engineering implications in the whole article.

1.6 The derivation chain: what can produce what

Drawn as a chain:

Email login  ──►  Session credential  ──►  (if tier allows) OAuth token
                        │
                        └──►  Web chat interface

API key  ──►  Metered API     (entirely parallel; the two never meet)

Properties worth committing to memory:

1. The arrows are one-way. A session may produce an OAuth token; the reverse is not possible.
2. The API-key line is isolated. It takes no part in the chain above and cannot be produced from it.
3. "Setup complete" comes in levels. Getting a session means the web app works; getting an OAuth token on top means the CLI and editor work. The first is mandatory, the second is an optional follow-up.

This chain explains a common confusion: why hosted setups often light up the web app first and the CLI later. Because that genuinely is two steps, not one. Any service describing them as "set it up and everything works" has either hidden the second step or not considered the case where the account tier is too low.

Chapter 2 Quota: how rolling windows shape what you feel

2.1 Two levels of window

Subscription quota is not metered the way most people assume. It is not a monthly pool — not "N calls this month, then you are done". The mainstream implementation is a rolling window, usually at two levels:

• The short window, on the order of hours. It decides whether you can keep working right now. It is small, so hitting it is a frequent event — especially during large refactors or long agent runs.
• The long window, on the order of days. It decides your budget this week. You hit it rarely, but recovery takes correspondingly longer.

"Rolling" means the window boundary is measured backwards from this instant, not pinned to a clock hour. So there is no "wait until midnight and it resets" — only "the earliest consumption slides out of the window, and capacity trickles back".

2.2 Windows are counted per account

This is the load-bearing sentence of the chapter:

Both windows are counted per account — not per person, not per device, not per IP.

From the server's point of view an account is one quota subject. Whether there is one human behind it or ten is neither known nor relevant.

2.3 The queueing effect when an account is shared

Suppose an account carries five users, each with modest daily usage. On paper it copes easily. But a rolling window is acutely sensitive to instantaneous concurrency: one of them kicks off a large refactor, the short window goes to 90% within twenty minutes, and the other four start hitting the wall with no warning whatsoever — unable to see who did it, how much is left, or when it recovers, because recovery depends on when the earliest consumption slides out, and that consumption was not theirs.

This is not something better scheduling fixes. It is determined by the granularity of the quota subject. As long as quota is counted per account and the account is shared, the coupling exists.

2.4 Reading a 429: not every "rate limit" means the same thing

What you get when you hit the wall is usually an HTTP 429. But 429 means different things at different layers, and confusing them leads to the wrong response:

The second is the one people misread. Many clients default to "back off and retry", but under window quota retrying is not only useless, it pushes recovery further out — because each failed request may still count.

The test is simple: does the response carry an explicit reset time? If it does, it is quota — wait it out. If it does not and the interval is short, it is a rate limit and backoff is appropriate.

This is also why "seeing remaining quota and a reset countdown" is not a decorative feature but necessary diagnostic information. Without it, all you can do when you hit the wall is guess.

2.5 Why "just split it evenly" does not work under a window model

The obvious idea: put quota allocation in the middle layer, cap each user at one-fifth.

Two problems make that unworkable.

You cannot measure accurately. The middle layer can count the requests it forwards, but the server's window accounting — how it weights, how it converts, how the boundary slides — is its own implementation detail and is not contractual. Your curve and its curve will diverge, and the gap between them is exactly "I still have plenty left, and the far end is already returning 429".

Even if you could, it is a bad deal. Split five ways precisely, and each person gets one-fifth of an account's quota. What the user has actually bought is not "a subscription" but "one fifth of a subscription" — at which point you may as well say so.

So the honest positioning for a shared plan is: modest usage, tolerant of occasional queueing, optimising for a low barrier and low starting cost. That is a perfectly legitimate position. It is simply not the same thing as "stable and predictable".

Chapter 3 Identity consistency: the risk is not being used, it is looking like someone else

3.1 What the server can observe

To be clear up front: this section discusses no countermeasures. It states one neutral fact — the signals a server can observe during authentication go well beyond "did you present a credential".

Any mature online service consults a set of contextual signals during session renewal, sensitive operations and anomaly detection. Roughly three layers:

How the server weights these, and where the thresholds sit, is published by nobody and should not be claimed by anybody. Anyone waving a "rule table" that guarantees safety if you follow it can be treated as unreliable on that basis alone.

3.2 Consistency beats "better"

There is one empirical regularity that follows from system-design principles and holds up well:

To an anomaly detector, a sudden change is more interesting than any particular value.

Anomaly detection models "what normal looks like" and then finds deviations. If an account operates in a stable context over a long period, that context becomes its baseline; the steadier the baseline, the cheaper it is to explain each subsequent access. Conversely, an account that is here today and there tomorrow presents a change that itself requires explanation, even if each individual "there" looks fine in isolation.

Which produces the most counter-intuitive — and most important — engineering conclusion in this article:

Stability is worth more than "better".

The instinct is "I will switch to a faster, cleaner network egress, so the account should be safer". From the detector's point of view, what you did was manufacture a discontinuity. The cost of that discontinuity may well exceed the quality you gained.

3.3 Why a fixed environment is a constraint, not laziness

This is what explains that conservative-sounding rule in hosted offerings: once assigned, the runtime environment does not change.

It is easy to read as the provider taking the easy way out. It is actually a constraint bought with real cost — giving up "dynamically schedule to whichever path is currently best", which sounds far more sophisticated, in exchange for every account's baseline staying put.

The justification is §3.2: account availability is far more sensitive to contextual stability than to contextual quality. Trading a little headroom for a baseline that does not jitter is a good deal.

The same logic explains a second design choice: changing accounts does not change the environment. Account and environment are two layers; when an account has to be replaced, only that layer moves. If both moved together you would be dropping a new account straight into a new context — two variables at once, the worst possible combination.

3.4 A boundary that has to be stated

This needs saying plainly, because it is the most common piece of misdirection in this space:

No third party can guarantee that an account stays usable.

Availability is ultimately adjudicated by the official vendor, not by any intermediary. What any provider — including a hosting provider — can actually do is two things:

1. Not add unnecessary risk: no gratuitous discontinuities, no obviously anomalous operating patterns.
2. Report status honestly: when something breaks, flag it and notify you immediately rather than leaving you staring at an error page guessing whether the problem is yours.

As for "we keep your account alive", "guaranteed no bans", "we compensate if banned" — such promises are either unconsidered or knowingly unmeetable. Whether a provider is willing to put this boundary in writing tells you more than how attractive its promises sound.

Chapter 4 Multi-tenant isolation: where sharing hits its ceiling

Chapter 2 covered quota coupling, but that is only one of three isolation problems. Sharing a single account means solving all three at once:

4.1 Session isolation

The problem: conversations under one account naturally pile up together; A opening the list should not see B's sessions. The usual fix: the middle layer maintains a "conversation ownership" table and filters the list per user.

The ceiling: the filtering is at the presentation layer, not the storage layer. The conversations still live under one account, and any account-level action (suspension, official cleanup) hits everyone equally.

The engineering requirements on that ownership table are also far steeper than they look, and they are the best illustration of where the complexity in a shared design actually hides.

One — it is a read on the critical path. Every list load queries it, so latency is felt directly. The natural move is an in-memory cache as the fast path.

Two — it absolutely must not be lost. Which fights the first point: caches are volatile. If the cache is the only copy, then a process restart, a cache eviction or an instance migration will wipe every user's conversation list simultaneously. And the failure is nasty in a specific way: it does not look like a failure. The user sees an empty list and concludes "my data is gone", not "the service is broken".

Three — it has to be rebuildable. Those two together leave exactly one solution: dual write plus cold-start rehydration — durable storage as the source of truth, cache as the fast path, and on cold start the cache is refilled from truth.

Which is worth stating directly: a shared plan looks cheaper because the cost moved from subscription fees to engineering complexity. That cost does not disappear; it is merely paid somewhere else — and if any part of it is under-built, the user pays it.

Four — the sort key trap. A very specific detail that is easy to get wrong. A table like this needs sorting by "last active", and the moment a time field crosses a timezone interpretation you have a problem: if the writer and the reader disagree about timezone, the same instant converts to different values and the ordering falls apart.

The safe approach is to store the sort key as a raw integer timestamp, not a timezone-bearing datetime, and keep a separate human-readable column. Integers take part in no timezone conversion and are immune by construction.

4.2 Quota isolation

Chapter 2 settled this: it cannot be done. The quota subject is the account; that is the granularity. All a middle layer can do is throttle on its own side, and that curve does not line up with the server's real window.

4.3 Fault isolation

The problem: when the account breaks, the blast radius is everyone attached to it.

The ceiling: that is what the word shared means. No technique routes around it. One account in trouble is a group of people in trouble.

4.4 Can you have all three

No, and the reason is clean:

Session isolation can be faked by a middle layer. Quota and fault isolation require splitting the quota subject to be solved at all.

And "splitting the quota subject" translates into plain language as: one account, one person.

That is the entire reason account hosting exists as a category. It is not more sophisticated than sharing; it just moves the problem to the only layer where it can actually be solved — at the cost of everyone needing their own subscription, which is a completely different cost structure.

Chapter 5 Streaming: the hardest part of any relay layer

Previous chapters treated the account as a static asset. This one looks at what a single request goes through on the wire. AI services have a property ordinary APIs do not: responses stream, and one interaction can last tens of seconds — which turns several non-problems into hard ones.

5.1 Why you cannot "buffer then forward"

The lazy implementation reads the upstream response fully into memory and sends it on in one go. Fine for ordinary APIs; a disaster for streaming: time-to-first-token goes from a few hundred milliseconds to the entire generation time — the user watches a motionless cursor for thirty seconds, which is experientially indistinguishable from a hang.

So the relay must forward as it receives, which means it holds two live connections for the whole generation. That is the root of everything below.

5.2 Four ways to break, all identical from outside

Every hop can break: the client's network wobbles, the relay instance restarts, the cross-network segment times out, the upstream errors. The trouble is that all four look exactly the same to the client — the stream stops, with no distinguishing information.

Which leaves you unable to decide from the symptom whether to retry. A workable mitigation is for the relay to emit a structured terminal event on disconnect carrying what it knows (which hop, whether upstream ended deliberately, any error code). It cannot be perfect — if the relay itself is what died, it cannot emit anything — but it covers most cases.

There is a practical quality test here: see whether it tells you anything when a stream dies. An implementation that ends silently is one that is not tracking this itself.

5.3 Retries are not idempotent

Ordinary API retries are usually safe: the failure cost nothing, resend it. But with streaming, at the moment of interruption the upstream may already have produced most of the content, and the quota is genuinely spent. So a retry carries real cost: double spend (one success from the user's point of view, two from the meter's), it will not stitch (generation is stochastic; the second attempt does not continue the first), and the ledger is opaque (a relay that retries silently leaves the user thinking their quota is draining for no reason).

First token is the watershed:

So a responsible implementation retries quietly before first token and reports the break honestly after it. Dressing a broken stream up as a success reduces complaints in the short run and spends the user's quota on your own appearances in the long run.

5.4 The timeout dilemma

Set it short and long-thinking tasks get cut off — which is precisely the main use case for agentic coding, where a large refactor running for minutes is normal. Set it long and a hung upstream holds resources until it expires.

Better than a total timeout is an idle timeout: ignore total duration, watch only how long since the last chunk. Still emitting tokens, still alive; nothing at all for longer than the threshold, declare it hung. The idea shares a root with rolling windows — both replace "absolute quantity" with "relative to the most recent activity", because the latter is what actually reflects health.

5.5 Backpressure, the part everyone forgets

The rate at which a relay reads from upstream and the rate at which it writes to the client are not necessarily equal. If the client consumes slowly (bad network, or simply a stuck terminal) while the relay keeps pulling at full speed, the buffer in the middle grows without bound — invisible on one connection, and memory exhaustion when hundreds do it at once.

The correct behaviour is for downstream consumption rate to exert backpressure on upstream read rate: if the client cannot keep up, stop reading from upstream. Most modern streaming frameworks build this in, but hand-rolled forwarding logic omits it constantly, and it only surfaces under real concurrency, which test environments rarely produce.

The chapter in one line: streaming turns forwarding from a stateless operation into a stateful one. Every extra hop adds another place to break, another buffer to manage, another retry decision to make. Which is why shorter paths tend to feel more stable — not because short is sophisticated, but because there is less that can go wrong.

Chapter 6 Takeover and restore: what a hosting client does on your machine

6.1 The problem

A hosted account has to run the official clients on your own machine, and those clients keep their identity in local config files. Which raises the obvious issue: you already have a login state of your own.

An implementation with no design behind it simply overwrites it — your own account is unusable while hosting is active, and when it ends you get to log in again and probably cannot remember what you had configured. In many offerings that cost is quietly transferred to the user.

6.2 Back up, overwrite, restore

A responsible implementation makes this a strictly symmetric three-part sequence:

Before takeover   store the current state verbatim
       ↓
While running     hosted config is in effect; yours is untouched
       ↓
On teardown       put the stored copy back, remove all traces

Simple to state. Getting it right involves several non-trivial details.

6.3 Merge, do not replace

Writing config should merge, not replace wholesale. A config file holds more than identity — preferences, history, project-level settings. Replace it wholesale and all of that is gone.

The correct behaviour is to write only the handful of keys hosting genuinely needs and leave everything else byte-for-byte intact; on teardown, remove only those keys. A config file that never contained those keys should come out of a full takeover-and-restore cycle identical to how it went in.

This is also why, when describing such a system, "we do not touch your settings" is a lie, while "we write only the few keys we need and leave the rest as they were" is the truth. Users do not believe the first (they know something must change); the second is verifiable.

6.4 Idempotency and "first backup wins"

The most bug-prone part: backups must be idempotent, and the first one wins. Consider this sequence:

1. Takeover; your original config is backed up — backup = your original ✓
2. Hosting runs; config is now in hosted state
3. For some reason (reconnect, switch, client restart) takeover fires again
4. If this backup writes unconditionally — backup = the hosted config ✗
5. Teardown restores — you get the hosted state back, and your original is gone forever

So the rule must be: if a backup exists, never overwrite it. The first is the original; every one after it is dirt.

There is also an easily missed edge case: "there was no file here" is a state too, and it must be recorded. Otherwise restore cannot distinguish "put the bytes back" from "delete what we created" — and an implementation that does not distinguish them leaves the user with a file they never had.

6.5 Crash safety: what happens if the power cuts mid-way

Everything above assumes the sequence completes. In reality processes get killed, machines sleep, disks fill up. So: if it is interrupted at any step, what state is the system in?

① read the user's original config
② write the backup file          ← dies here: backup may be incomplete
③ write the hosted config        ← dies here: backup fine, config is half-written
④ ……running……
⑤ restore from backup            ← dies here: config may be half-written
⑥ delete the backup (if needed)  ← dies here: config restored, just a leftover file

The dangerous ones are ② ③ ⑤ — a half-written config file is, to the client, a corrupt one.

The standard remedy is write to a temp file, then rename atomically. The filesystem guarantees rename is atomic: you either see the old file or a complete new one, never a hybrid. This is near-universal for config writes, costs almost nothing, and skipping it corrupts user configs at low probability — a class of bug that is extremely expensive to reproduce and usually surfaces only in production.

A leftover from step ⑥ is by contrast harmless: an extra backup file breaks nothing, and the "never overwrite an existing backup" rule still protects it. In designs like this, prefer leftovers to losses — a good general principle.

6.6 Symmetry on the way out

Teardown must be as thorough as takeover. If takeover touched three places (CLI config, editor extension, desktop client pointer), teardown must undo all three. Missing one usually does not raise an error — it causes silent degradation: the editor config still points at an executable that has been deleted, the extension cannot find it and quietly falls back to its bundled copy, and the user cannot tell that hosting stopped working. They just feel that "something has been off lately".

Silent failure is ten times harder to diagnose than an error. This is the part of such client engineering most worth investing in.

Chapter 7 Observability: what you should insist on seeing

7.1 A blunt criterion

A hosting service is fundamentally holding an asset on your behalf and operating it for you, and information asymmetry is inherent to that. So the single most effective indicator of whether one deserves your trust is not its technical marketing but:

How much does it voluntarily show you that you could not otherwise see?

Publishing state has a cost — once it is in the open, you cannot be vague about it when things go wrong. Providers willing to pay that cost are usually the ones who can.

7.2 What specifically should be visible

In rough priority order:

Two bonus items that double as reverse indicators:

• Are results shown as measured? A panel that always reads "all normal" is probably not measuring anything. One that is willing to display "not yet checked" and "check failed" is more credible than one that is permanently green.
• Can you trigger a check yourself? Passively waiting for a push and actively verifying are different experiences, and only the second produces a sense of control.

7.3 One anti-pattern

A design worth being wary of: giving the conclusion without the basis.

A panel that says "line healthy" without telling you when that was determined or from what. The problem shows up when your experience contradicts the conclusion — you have no way to judge whether the problem is yours or its.

Better is to present conclusion, time and origin together: "this is the result of the check you ran ten minutes ago" is far more useful than a bare "healthy".

Chapter 8 Device binding: why credentials are issued to "this machine"

8.1 One login, several machines

A fair question: if the account is mine, surely using it on several machines is irrelevant?

Technically you could copy one credential everywhere. The more mature approach is per-device issuance: each machine authorises once and receives a credential of its own.

That extra step buys three things:

1. Visibility: you can see which devices are in use and when each was last active.
2. Revocability: retire one machine, or one you do not recognise, without affecting the others.
3. A smaller blast radius: a leaked credential compromises exactly one machine.

8.2 Why revocation has to be a first-class citizen

Point 2 deserves emphasis. In many designs revocation is bolted on late and done carelessly. But in security terms issuance and revocation must be a symmetric pair — a system that can only issue accumulates, over time, a pile of still-valid credentials nobody remembers.

For a user, "can I revoke a device myself" is a far better test of whether a design takes security seriously than counting the security words in its marketing.

Chapter 9 Choosing: one decision table

Compressing the first eight chapters into something actionable:

9.1 Do not only count the cost of getting in

A dimension almost nobody raises in selection discussions: what does it cost you to leave when it stops working out?

This is not a commercial question but a technical one — exit cost is determined almost entirely by the number and depth of coupling points.

Three points worth noting.

The low exit cost of API keys is badly underrated. Official API shapes have converged, and most clients let you change the base URL — moving from provider A to provider B costs approximately nothing. It barely locks you in at all.

Judging a hosting offering's exit cost comes down to the restore logic in Chapter 6. An implementation that restores cleanly needs one uninstall; a sloppy one leaves you hunting down every place it changed, without knowing what those places are. So all those fiddly details in Chapter 6 (first backup wins, merge not replace, symmetric teardown) do not determine "how pleasant it is to use" — they determine whether you are free to walk away.

Procured accounts couple most deeply. One question matters: if I stop renewing, is the account still mine? Answers vary a great deal between providers, and asking once there is a problem is too late. Conversely, bringing your own account is the shallowest form of hosting — the account stays yours throughout; only the environment running it is hosted.

9.2 These two are not mutually exclusive

Pay-as-you-go and subscription can coexist, and most mature teams do exactly that: interactive development on a subscription account (you want the UI and continuity), CI and batch jobs on an API key (you want statelessness and concurrency). The two are complementary; forcing a choice between them makes life harder than it needs to be.

Chapter 10 Nine misconceptions, in one table

Closing

Back to the five questions we opened with:

• Bought API credit, web app still wants a login — two parallel auth paths; a key cannot produce an identity.
• Fine yesterday, spinning today — most likely a rolling window, and if the account is shared, the person who consumed it is not necessarily you.
• Why everyone insists on fixed rather than "better" — anomaly detection models what normal looks like; the discontinuity itself is what needs explaining.
• Is "the environment never changes" too conservative — it is a cost paid deliberately, not laziness.
• Why retrying a broken long task is worse — after first token the quota is spent; a retry bills twice, and it will not stitch back together.

One level up, what this article is really arguing is something plain:

In this field, people who state their constraints clearly are more trustworthy than people who state their promises beautifully.

Constraints are verifiable — you can go and hit them and see whether things behave as described. Promises tend to live where you cannot verify them, and by the time you can, you have usually already paid.

If this gets you to ask two more questions during your next selection — "how exactly is the quota counted", "what does it do when a stream dies", "can my machine be cleanly restored when I leave" — it has done its job.

This article discusses only publicly observable mechanisms and general engineering trade-offs. It contains no server-side rule details and offers no adversarial techniques. The descriptions of quota windows and authentication paths are behavioural generalisations from a user's vantage point and do not represent any vendor's internal implementation.