CraysRoutstr
Routstr brings Nostr into the AI market: providers announce themselves, clients discover routes, Cashu pays for usage, and familiar OpenAI-compatible APIs become a permissionless pay-per-request surface.
The AI router that uses Nostr as market infrastructure
Routstr belongs in the Apps shelf because it is one of the clearest examples of Nostr moving beyond social feeds. It asks a hard question: if AI inference is increasingly controlled by a small set of accounts, billing systems, regional rules and API gatekeepers, can a Nostr-and-Bitcoin stack make access feel more like an open market?
The official site describes Routstr as pay-per-request AI APIs with Bitcoin micropayments, OpenAI-compatible, privacy-preserving and accountless. The footer is even shorter: an open source protocol for decentralized AI inference routing. The docs explain the moving pieces: Nostr handles discovery and communication, Cashu handles private instant Bitcoin ecash payments, and providers serve model requests through a proxy or their own hardware.
That puts Routstr in a different category from a normal chat product. It is not just a front end for one model. It is a market layer. A user or developer wants access to inference. A provider wants to sell tokens or capacity. The network needs a way to announce providers, compare price and latency, pay per request, avoid mandatory accounts and route around failure. Routstr uses Nostr events and relays for the discovery side, then Cashu tokens for payment.
For Nostr readers, this is important because it shows a protocol pattern that can matter far outside posting. Nostr is useful whenever independent actors need to announce signed state to a network: relays, app handlers, wallet services, data vending machines, calendars, markets and now AI nodes. Routstr makes that pattern visible in a category where censorship resistance, payment privacy and accountless access are not abstract values. They are daily developer friction.
What Routstr actually is
Routstr has several surfaces. The public website is the front door. The docs explain the protocol and guides. The chat app gives non-developers a way to try model access. The Core repository contains the provider-side proxy. The protocol repository contains Routstr Improvement Protocols, or RIPs. The roadmap shows how discovery, node listings, evaluations and smart clients are meant to evolve.
The clearest mental model is this: Routstr is trying to make AI inference purchasable with small private Bitcoin payments while letting clients discover providers through Nostr. A developer can point an OpenAI-compatible SDK at a Routstr endpoint and use a Cashu token as payment. A provider can run Routstr Core as a reverse proxy in front of OpenAI-compatible APIs, connect upstream models or hardware, set prices and receive Lightning value through ecash flows.
The docs divide readers into client builders and node runners. Client builders want AI models without accounts, subscriptions or KYC. Node runners want to sell capacity or proxy access, set pricing and receive payment. That split is healthy because it keeps the marketplace honest. A product like Routstr only works if both sides are legible. Buyers need predictable access, prices and refunds. Sellers need a deployable proxy, useful admin tools and payment settlement.
The hosted site and chat app are convenient, but they are not the whole claim. The stronger claim is protocol-shaped: a network where many clients and providers can coordinate without one AI account platform becoming the owner of every request. That distinction matters. If a user only touches api.routstr.com, they are using a hosted route. If builders run nodes, clients and discovery flows independently, Routstr becomes closer to the decentralized market it describes.
Why Nostr belongs in the route
Routstr uses Nostr for discovery because AI providers need a public way to announce themselves. The roadmap names a Nostr event spec for inference node announcements, including kind 40500 events, node capabilities, supported models, pricing, region, operator pubkeys, endpoint URLs and latency metrics. Another roadmap item covers frontend discovery: list active nodes from Nostr, filter by model, region, price and social proximity, show node cards and update in real time as new node events arrive.
That is a natural Nostr job. A provider announcement is signed. It can be published to relays. Clients can subscribe, filter and compare. No central directory has to own the only list. The network can gossip about providers, and different frontends can build different ranking systems. In a normal platform market, the app store or API broker decides visibility. In a Nostr market, visibility can be contested by clients, relays, social trust and user-side filters.
The Citadel Dispatch episode listing captures the broader discussion topics around Routstr: provider proxies, proprietary models, pricing dynamics, discovery, reviews, quality signaling on Nostr, open source funding, one-click stacks, agents and routing around outages. That set of topics shows why Nostr is not a gimmick here. Discovery and reputation are the hard part of a permissionless provider market. Payment only solves one half of the transaction.
Nostr also gives Routstr a path toward accountability without requiring identity paperwork. A provider can bind itself to a pubkey. Clients can observe reliability, relay presence, pricing changes and evaluation events. That does not make every provider trustworthy. It makes the trust surface inspectable. In a market for AI output, that is valuable because failure can mean bad answers, hidden upstreams, missing tool support, high latency, surprise costs or censorship.
Cashu is the permission layer
Routstr's payment idea is blunt: instead of a user account, credit card, subscription and stored billing profile, a request can carry or reference Cashu ecash. The Core README says Routstr combines Nostr for discovery and Cashu for private Bitcoin micropayments. Its basic usage examples show an OpenAI client pointed at https://api.routstr.com/v1 with a Cashu token used like an API key, and a cURL example using an x-cashu header.
That is powerful because AI requests are a perfect micropayment use case. A single prompt may cost less than a cent. A long coding session may cost more. A developer may want to try a model once without opening an account or loading a monthly plan. Cashu lets the payment be granular and bearer-like. The user can top up, spend and move without teaching every provider who they are.
But Cashu does not remove every trust question. A Cashu token depends on the mint that issued it. A Routstr node depends on the provider that accepts it. A hosted chat app can still have its own privacy posture. The privacy gain is not "nobody can know anything." The gain is that the billing rail can avoid normal account identity, card identity and KYC, while clients can route through providers rather than sending every request to one default platform account.
This is also why the user experience matters. If Cashu feels like pasting a strange token into a box, most people leave. Routstr's public chat and API key flows try to make the payment model familiar: top up, get access, point a standard client at the endpoint. The strange part stays under the hood. That is exactly what a Nostr-and-Bitcoin app often has to do. Keep the protocol honest, but make the first successful action boring.
Routstr Core is the provider piece
The most important repository is Routstr/routstr-core. Its README calls it Routstr Payment Proxy: a FastAPI-based reverse proxy that sits in front of OpenAI-compatible APIs and handles pay-per-request billing. On June 18, 2026, GitHub's API showed the repo created on April 8, 2025, updated on June 17, 2026, written mostly in Python with TypeScript also present, GPL-3.0 licensed, with 60 stars, 13 forks and 61 open issues. The latest release shown by GitHub was Routstr Core v0.4.3 from May 6, 2026.
The README's basic user path is intentionally familiar. Use the OpenAI SDK, set the base URL to the Routstr API, provide a Cashu token in the key position or x-cashu header, and request a model. The provider path is similarly direct: run Docker Compose, configure an admin password, node name, description, Nostr secret key and Lightning receiving address, then open the admin panel to connect upstream providers and set pricing.
That reverse-proxy model matters because it lets Routstr sit between many existing AI APIs and buyers who do not want a normal account relationship with each upstream. A provider can expose access to OpenAI-compatible models, local models or other upstreams, price requests and receive payment. A client can use existing SDK patterns instead of learning a completely new AI API.
The tradeoff is that the proxy becomes the trust surface. A provider can see the request unless the model path has additional privacy techniques. A provider can misprice, fail, censor, log or route to unknown upstreams. Routstr's roadmap around evaluations and quality is therefore not optional polish. It is part of the market design. If anyone can sell access, clients need ways to judge who is worth paying.
Chat, API keys and developer entry points
Routstr does not ask every user to begin with Docker. The public site sends people to chat.routstr.com and to an API key tab. The site copy says the API is OpenAI-compatible and works with OpenAI SDKs, LangChain or desktop applications. That matters because developer adoption often begins with the smallest possible migration: keep the client code, change the base URL and payment credential.
The Routstr Chat repository shows the consumer-facing side. It is a Next.js frontend with conversation history, model selection, Cashu Lightning wallet integration for deposit, balance and invoice history, Nostr support, relay connectivity, configurable models and providers, and local persistence through localStorage and Zustand. Its tech stack includes Next.js 15, React 19, TypeScript 5, Tailwind CSS 4, TanStack Query, Cashu TS and nostr-tools.
That frontend is important because most people understand AI access through chat first. A protocol can be brilliant and still fail if the first user touch is only a terminal command. Routstr Chat gives the market a visible face: choose a model, fund the session, ask a question, see cost. The same accountless payment idea then extends to code, agents and scripts.
OpenClaw is another useful signal. Routstr's OpenClaw page advertises self-hosted AI agent setup with a single Lightning payment to deploy a VPS with Routstr balance. Whether or not a reader uses that exact flow, it shows the intended direction: AI agents, hosting, payments and Nostr-discovered service routes can become composable. That is where Routstr starts to touch the wider Nostr agent economy rather than only chat completions.
Roadmap, quality and young network risk
The roadmap is unusually helpful because it names what still has to become real network behavior. RIP-1 covers an OpenAI-compatible API proxy with Cashu payments, per-request micropayments, token-based pricing and cost reporting. RIP-2 covers Nostr node listing events. RIP-3 covers frontend discovery. RIP-4 covers anonymous quality control and provider ratings using standardized events. RIP-5 covers smart clients with local Cashu wallet management, auto-redemption, token splitting, Tor or proxy routing, provider optimization and dynamic scoring.
That roadmap gives the reader the maturity frame. Routstr already has live public surfaces, docs, a core proxy and repositories. But a decentralized AI marketplace is not finished just because one gateway works. The harder product is a network where clients can discover many providers, compare them, evaluate them, route around failures, manage private payments and protect users from bad or misleading nodes.
The open issues on the Core repository also show normal young-project friction: provider routing errors, config ownership, cost details, streaming parser concerns, unsupported mints, upstream model support and testing with testnet mints. Those issues are not a reason to dismiss the project. They are a reminder that a reader needs to separate the idea from operational reliability. AI infrastructure with payments attached needs boring edges before it can carry important work.
The central criticism is simple: Routstr can reduce dependence on account platforms, but every request still lands somewhere. A provider can log content. An upstream model provider can apply its own policy. A public gateway can become a convenience choke point if users never move beyond it. The promise becomes stronger when more independent nodes, clients, wallets and evaluation tools exist. Until then, Routstr is best read as a serious early market, not a solved replacement for every AI provider account.
How to test Routstr like a real product
Start as a user, not a believer. Put in a tiny amount, use the chat app and run one harmless prompt against a cheap model. Watch the cost, speed and output. Then use an OpenAI-compatible client with the Routstr base URL and a small Cashu token. If that first loop works, you have tested the product's most important promise: AI access without a normal account and credit-card path.
Then test the payment edges. What happens when the token runs out? How clear is the cost reporting? Does streaming behave? Can you refund or recover unused balance in the flow you used? Cashu is powerful, but a good product must make token state understandable to a normal user. Losing a few sats during a test is education. Losing track of payment state during real work is not.
Next, test provider diversity. Try more than one model and, if the interface exposes providers, compare latency and reliability. If a model claims tool support, test tool calls. If a provider advertises a low price, check whether output quality and availability match. Routstr's market promise depends on clients being able to make these comparisons instead of trusting one default route.
If you are technical, run a node. Deploy Routstr Core with Docker, connect an upstream provider, set conservative pricing and try to buy from your own node with a separate client. That one exercise reveals the true product shape: admin setup, upstream credentials, Nostr identity, pricing, Cashu redemption, cost accounting and client behavior. After that, the public site will make much more sense.
Routstr sources worth opening
Open the main site and docs first, then read Core, Chat, the protocol repo, roadmap and the Citadel Dispatch episode notes for the public explanation of the team, market and reliability questions.
- Routstr official site
- Routstr documentation home
- Routstr overview documentation
- Routstr roadmap
- Routstr blog
- Routstr 0.1.0 announcement
- Introducing Routstrd
- OpenClaw setup page
- Routstr chat app
- Routstr GitHub organization
- Routstr Core repository
- Routstr Chat repository
- Routstr protocol repository
- Citadel Dispatch episode 192
