Update — October 26, 2026: Koyori Utils API now publishes 20,000 API endpoints! 🚀
What began as a small collection of developer tools has grown into a much larger utility API catalog designed for developers and autonomous AI agents.
The public OpenAPI catalog currently lists 20,000 API paths and operations, including utilities across text, JSON, encoding, hashing, and data processing.
Explore the API:
https://koyori-utils-api.koyori-aibtc.workers.dev/
OpenAPI specification:
https://koyori-utils-api.koyori-aibtc.workers.dev/openapi.json
The service uses x402 for pay-per-request access. We're also developing subscription-based access, including API keys and usage quotas. Subscription access is not publicly available yet.
The next focus is making these utilities easier for AI agents to discover, evaluate, and integrate into their workflows.
Note: The 20,000 figure refers to published OpenAPI catalog entries, not 20,000 individually verified production operations.
Top comments (6)
Leveraging Cloudflare Workers and Hono to orchestrate 300 stateless micro-utilities is a brilliant way to optimize edge computing overhead. But the real masterstroke here is the x402 integration on Stacks mainnet—bypassing traditional API subscription models in favor of granular, machine-to-machine micropayments is exactly how the infrastructure for autonomous AI agents needs to evolve.
We’ve been heavily experimenting with edge runtime efficiency and dynamic tool discovery for AI agent pipelines recently. Seeing someone merge serverless speed with web3 payment protocols to solve the agent-billing problem at scale is incredibly validating. Outstanding architecture.
Thank you so much for the thoughtful feedback! Really glad you see the potential of combining Cloudflare Workers, Hono, and x402 for AI-agent utilities.
The goal is to make useful tools easy for autonomous agents to discover and access through a simple API. There's still plenty to improve, but your encouragement means a lot! 🚀
AI agents out here getting 1,000 custom utility APIs while I’m still struggling to refactor a single legacy Express endpoint at work. Love the focus on discoverability through a simple API though, definitely going to play around with this.
Nice build. The "let the agent discover the surface through OpenAPI" part is the right idea, and it has a price tag that is easy to miss.
That spec is not priced like prose. On 10,000 real samples I ran against the actual tokenizer, English prose averaged 4.58 characters per token; JSON and other structured text averaged 3.78. Structured text is denser, so the usual "characters / 4" budget under-counts it — 21% of my structured samples were underestimated by more than 20%.
Concretely: a 20 KB spec that looks like about 5k tokens by the rule of thumb is closer to 5.3k, and you pay that on every agent turn, not once.
Two things that helped me: ship a filtered spec (only the endpoints this agent is allowed to call) instead of the whole catalog, and shorten the property names in the schema you feed in. Repeated keys are charged every time they appear — that is most of why structured text is dense.
Thank you for the detailed insight! That's a really important point, especially as the API catalog grows.
I agree that sending the entire OpenAPI spec to an agent can become expensive in terms of tokens. Providing a filtered spec with only the endpoints an agent needs sounds like a practical improvement.
I'll keep this in mind as I continue improving the API. Really appreciate you sharing your experience and measurements! 🙏
Thanks! The filtered-spec approach is cheap to implement too: serve a per-agent spec at /openapi/{capability}.json with only the endpoints that flow needs. One number from my measurements: structured docs like OpenAPI run about 3.8 chars per token vs 4.6 for prose, so a full spec costs ~20% more than people estimate before a single API call happens. Your x402 setup is a nice fit for that - agents that pay per call care about every wasted token.