The big win is multi-file refactors where the model needs to hold the full dependency graph in context simultaneously. With 200k, compaction kicks in mid-task and the model loses track of which files it already changed, leading to inconsistencies or repeated work. With 1M you can load an entire module (tests, types, implementation) and get a coherent refactor in one pass.

Also useful for long debugging sessions where the conversation history itself is the context. Compaction preserves a summary, but summaries lose the exact error messages, stack traces, and failed approaches that help the model avoid going in circles.

The real loss here isn't Google Fiber itself, it's the competitive pressure it created. Every city where Google Fiber launched or even announced plans saw incumbent ISPs suddenly "discover" they could offer faster speeds at lower prices. That threat alone was worth more to consumers than the actual service.

PE firms optimize for cash extraction, not market disruption. Expect the new entity to quietly stop expanding, raise prices to match competitors, and eventually become indistinguishable from the cable company it merged with.

The same pattern is playing out in API payments right now. Traditional API billing (Stripe subscriptions, API keys, monthly invoices) is the "bank branch" model: it works, but it requires human setup, identity verification, and ongoing account management for every provider.

HTTP 402 "Payment Required" has been a reserved status code since 1997, unused for nearly 30 years. Now protocols like x402 and L402 are finally implementing it: a server returns a 402 with a payment instruction, the client pays (stablecoins or Lightning), and gets access. No signup, no API key, no billing relationship.

This isn't replacing Stripe any more than ATMs replaced tellers. Most API providers will keep using traditional billing. But there's a new category of consumer that can't use the old model at all: autonomous software agents. An AI agent can't fill out a signup form, pass KYC, or manage a credit card. Per-request micropayments over 402 let agents acquire API access without any human in the loop.

The parallel to the article is exact. ATMs automated a task within the existing branch paradigm. Mobile banking eliminated the need for the branch. Similarly, better developer portals automated API key management within the existing billing paradigm. Machine-to-machine micropayments eliminate the need for the billing account entirely.

This fills a real gap. Right now x402 and L402 are both fire-and-forget: the client pays, the server delivers (or doesn't), and there's no recourse if the response is garbage or never arrives. For small amounts that's tolerable, but as agents start chaining multiple paid API calls in a single workflow, the failure modes compound fast.

A few questions: How does the arbitration layer handle the case where "delivery" is subjective? For a data API, you can verify the response isn't empty, but validating that the data is correct or fresh is harder. Does x402r define what constitutes a valid delivery, or is that left to per-service SLAs?

Also curious whether this works across payment protocols. L402 (Lightning macaroons) has a different settlement model than x402 (USDC on Base), so the refund mechanics would differ. Does x402r handle both, or is it x402-specific?

Interesting approach. The "universal balance across providers" model solves the onboarding friction well, but I'm curious about the discovery side. How does the 280 API catalog get maintained? Is it a curated list, or do providers self-register?

The x402 ecosystem is growing fast on the stablecoin side, but there's a parallel L402 ecosystem on Lightning that's also non-trivial in size. Do you plan to index both, or stay x402-only?

One tension I've noticed in this space: projects that act as both the payment intermediary and the discovery layer tend to lock agents into their ecosystem. The "open ecosystem" framing suggests providers just need x402 support, but the agent still needs to know about AgentCash to find them. A truly open approach might separate the directory from the payment rail, so any client can discover endpoints regardless of which payment SDK it uses.