Payment is authorization

I can't tell you how many times I've needed to do something simple like remove the background from an image or convert a file from one type to another but wasn't able to do it. While these feel like simple, common things your OS should just handle, they require a service to do them. Luckily, I'm usually able to Google the problem, find a website dedicated to solving that one problem and do it. It's super nice because I land on a website like remove.bg , drag my image onto the page, and the background is removed. I don't have to log in, it's not tracking me (that I'm aware of), and it just works. The API version of this is something I'd call a utility API . It simply does a thing and gives you a result. Compare a utility API with what we're growing more and more accustomed to. I click on a marketing site, sign up, pick a plan, confirm my email address, then start making requests. You know what I call that? Friction . And in a world where AI agents are becoming increasingly important consumers of APIs, friction is holding us back. There's a lot of attention right now on agent identity , and for good reason. Agents that read private data, modify infrastructure, operate business systems, or act on behalf of people absolutely need durable identity, delegated authority, auditability, and policy. But I think we're going a little too far with it. For a lot of utility APIs, identity doesn't need to be part of the authorization decision. Instead, it just becomes who we charge . Let's dig into that a little bit. Bring your own access To perform a basic utility, it's likely that an agent will discover your API at runtime, perform a single operation, and never call it again. So requiring it to create an account and establish a permanent relationship with your service before doing 2 cents of work feels wrong. What if instead, your API provided a pay-as-you-go on-demand model (something my readers should be familiar with). x402 is an open protocol for payments over HTTP, led by th