Anthropic's Claude billing model has been getting attention in the last few months, and for genuine reasons. The meter is visible in real time. Soft warnings fire as the cap approaches. Overflow is priced at standard API rates rather than a markup. When users hit the cap, the wall is clean. Three options surface in the moment. Wait for the reset, pay overflow at the published rate, or upgrade.
The design is better than the alternatives it replaces. A visible meter removes a confusion that has annoyed customers of usage-based services for years. Overflow at the published rate removes the suspicion that overage exists to extract from the unlucky. The wall, frustrating as it sounds, replaces a worse design where the model behind the API quietly becomes a cheaper one and the user discovers it on the next bad output. The trust cost of a hidden swap is higher than the friction cost of a clear wall.
Reading the praise the design has earned, one phrase appears repeatedly: transparency is the moat. That is the right word, doing the wrong work.
The objection here is not that the meter is wrong, or that it could be wrong without anyone catching it. The objection is that calling visibility a moat asks the word transparency to carry weight that visibility cannot bear.
The question the design doesn't answer
The meter is real-time. The meter is visible. The meter is, by every measure available to the customer, accurate.
Whose meter is it?
The vendor's. The platform produces the meter that shows how much of the vendor's product the customer has consumed of the vendor's allocation under the vendor's terms. The customer sees it. The customer does not produce it, cannot modify it, and reaches it only through the vendor's interface. Every number on the screen is the vendor's claim, presented with care.
This is fluid self-attestation with better presentation. The vendor records what happened, and continues to control the record after recording. If the methodology for counting reasoning tokens is revised next month, the customer learns about it from the changelog. If a count is restated in retrospect because of a billing correction, the customer learns about it in the support ticket. The record stays under the producer's continuing control. What has changed is how the producer communicates that control. Not whether the producer still has it.
If the answer to "is today's count what the system would have produced yesterday for the same activity" is "yes, because the vendor says so," that is not verification. That is the vendor reading the customer their own numbers in higher fidelity.
The design is not dishonest. It is at a layer below the one the praise has placed it at. It is a visible meter. It is not a verified meter.
What visible and verified actually require
The distinction is structural, not cosmetic.
A visible meter requires good interface design. The vendor builds a UI that surfaces consumption in real time. The customer reads it. The vendor confirms the read by displaying numbers that match what the customer's own clients report. Visibility is a property of the user experience.
A verified meter requires something else.
Verification requires evidence the verifier did not produce, cannot modify, and does not need permission to access.
The customer is the verifier. The vendor-displayed meter fails on all three of these conditions, even when the design is excellent. The customer did not produce the meter. The vendor can change it after the fact. The customer reaches it through the vendor's authentication. All three failures route back to the same party.
Visibility is not verification. Detail is not verification either.
The design is doing its job within the layer it occupies. Calling that layer a moat is overstating what visibility can secure. A visible meter is a feature one competitor can build to match another's in a quarter. The work is in the UI, the API surface, the warning thresholds, the overflow pricing. None of it is structural.
Two signings, only one notarized
The plainest way to see the difference is to picture two signings.
Person A signs a contract in front of Person B. Person B watches the pen move. Person B can describe the signing, attest to having seen it, and even take a photograph. Person B knows the signing happened.
Person A signs the same contract in front of Person B and a notary. The notary stamps the document. Both Person B and the notary saw the signing. Only one of those signings will hold up in a future dispute about whether it actually happened, in that form, at that moment.
The notary is not adversarial and does not judge the contract. The notary verifies that the signing happened. Notaries exist precisely because the signer cannot notarize their own signing. Verification works the same way.
A meter the vendor displays to the customer is visible. A meter the vendor publishes to a record neither party controls is notarized. The visibility is what the customer sees in the moment. The notarization is what makes the visibility durable past the moment of viewing.
The praise the new design is earning treats visibility as if it does the work of notarization. It does not.
What changes when the meter is notarized
Self-attestation does not go away when the meter is notarized. The vendor still produces the claim. The vendor is the only party that can credibly observe events happening inside their own infrastructure. What changes is whether the vendor controls the claim afterward.
In the fluid model, the vendor records, displays, can edit, and can selectively present. The act of attesting is continuing. The answer can move between askings. This is the model the praised design is in, no matter how visible the meter looks.
In the committed model, the act of recording publishes the claim to a destination the vendor no longer controls. The record becomes evidence the moment it is made. The vendor still claims. The vendor no longer revises. Both sides can check. Neither side can revise.
The categorical difference is not in how the meter looks. It is in what the meter becomes after the customer looks away.
This is the layer the new design does not include. Without it, the customer experience improves and the structural position does not. The vendor's invoice is still the vendor's claim. The customer's confidence is institutional rather than architectural. The customer who today accepts the visible meter will, in three or four years when contract sizes reach the volume where procurement teams formalize what counts as verification, run into the gap the visible meter does not close.
Procurement teams have asked this question before. SOC 2 was a procurement requirement before it was anything else. The same shape is forming around independent usage verification, and the question on the form will not be "is the meter visible." The question will be "can the meter be checked by parties other than the one whose product is being metered." That is a different question than the new design answers, and it is the one the next phase of usage-based pricing will be evaluated against.
The work the praise misses
Calling visibility a moat is the smaller mistake. The larger one is treating visibility as if it ends the work of transparency. It does not. Visibility is the part of transparency the vendor can ship on their own timeline. Verification is the part that requires somebody else.
The vendor is the only party that can produce the claim. The vendor cannot also be the only party that holds it. The signer signs. The notary stamps. The two functions are separate because the structural integrity of the second depends on the second not being the first.
The next phase of usage-based pricing isn't a better display. It's a notary.
Related reading: The Meter You Quietly Tune, on what happens to the meter's corrections after everyone looks away. And Edison Invented Self-Attestation. He Called It a Meter., on how the meter reached the customer's wall the first time, and where cloud billing put it.