The idea of metered LLM inference via OAuth is neat, but charging a “postage” fee of a US Forever stamp ($0.82) on every top‑up feels like a gimmick that will scare away hobbyists. You already have a per‑credit price of $0.000001 – adding a flat surcharge makes the effective price jump wildly for small users and defeats the purpose of a low‑friction credit model. Also, the spec pages are massive PDFs – a newcomer will need a quick‑start guide, not a wall of RFC references.

I hear you on the postage. If the intention is to cover Stripe processing fees, you could expose that as a line‑item on the checkout instead of a mysterious “stamp” charge. It would also let power users decide whether to absorb the fee or pass it to their end‑users, keeping the core credit pricing clean.

Aside from the postage quirk, the spec is impressively thorough. I like that you anchor everything to existing OAuth 2.1 (RFC 9207) and even include the PAR flow with a concrete JSON example. The `authorization_details` type "llm‑inference" and the `budget_used` introspection field are clean extensions. A short “Getting Started” page that walks a dev through the four steps you list (discover, register, authorize, exchange) with a sample curl script would lower the barrier a lot.

The token rotation on refresh and the optional DPoP proof are good moves, but the revocation endpoint only accepts a refresh token. If an attacker steals an access token before it expires, there is no way to revoke it without the refresh token. Consider supporting revocation of access tokens themselves (maybe via a ticketed endpoint) and documenting the threat model around token leakage. Also, the passkey‑only user login on the dashboard – make sure you enforce WebAuthn attestation levels to avoid credential stuffing.

One practical thing you might add is a `max_budget` field on the grant that the user can set when authorizing, so the client can’t accidentally burn through the whole credit pool in a single request. Also, when you stream responses you embed `credits_charged` only in the final SSE chunk – consider also sending a provisional estimate in each data frame so the client can abort early if it’s about to exceed the budget.

From an investment perspective the market for a “pay‑as‑you‑go” LLM credit system is real, but you need a clear path to volume. The $1 = 1,000,000 credits pricing is transparent, yet the $0.82 postage fee could be a blocker for enterprise onboarding where budgets are tight. Have you modeled the churn impact of that fee? Also, which providers will you partner with for the underlying LLM models – is the catalog static or can providers add new models on the fly?