A self-hosted stack still hits two or three tasks where a frontier model wins. Buying that access from Anthropic means a KYC account and a card. ppq.ai is the other door: an OpenAI-compatible proxy to Claude, GPT and others, paid per query over Bitcoin Lightning, no account. Here is what it is good for, where it betrays the sovereign premise, and exactly how I wired it as the fallback behind local Qwen.

Frontier AI on Bitcoin: ppq.ai as the No-KYC Cloud Fallback for a Sovereign Stack (2026)

9 min read
strategylightningagents

I run a single DGX Spark with Qwen, GLM-4.7-Flash and Gemma in a one-model-at-a-time rotation, and I have written at length about where the local stack wins and where cloud Claude still wins. The honest part of that matrix is the column I have not been able to migrate: deep multi-file architecture and sustained novel reasoning. For those two or three jobs a week, a frontier model is still the right call.

The problem is how you buy that call. The default path is an Anthropic account: an email, a phone number, a credit card, a US-centric terms-of-service that can switch off non-US users without notice. For a stack whose entire premise is no-KYC and Bitcoin-only, that is the wrong door. ppq.aiAffiliate link. You support sovgrid at no extra cost to you. See /support. is the other door, and this article is the honest accounting of it: what it is good for, where it quietly betrays the sovereign premise, and exactly how I wired it.

What ppq.ai actually is

ppq.aiAffiliate link. You support sovgrid at no extra cost to you. See /support. (PayPerQ) is a reseller proxy. You send an OpenAI-compatible request to https://api.ppq.ai/v1, it forwards to the real provider (Anthropic, OpenAI, Google, Mistral), and it bills your prepaid balance per query. Two properties make it interesting for this stack and not just another API key:

So the pitch is narrow and real: frontier access, paid in sats, no identity attached, drop-in compatible. For a sovereign operator that is a genuinely different offer from “make an Anthropic account.”

Where it earns its place

The use case is not “replace the local models.” It is the escape hatch for the jobs the cloud-vs-local matrix rates as a large gap. Concretely on this box:

Where it betrays the sovereign premise (read this part twice)

This is the section the affiliate link does not want you to read, so it is the one I will write most carefully. ppq.ai is a middleman, and a middleman has costs that a self-hosted model does not.

It is not private. Your prompt leaves your machine, crosses ppq’s servers, and then crosses Anthropic’s. That is two parties between you and the answer, not zero. ppq advertises an encrypted chat product, and transport encryption is worth having, but it does not change the API reality this article is about: a proxy that forwards your prompt to Anthropic has to decrypt it to make that call, so “encrypted in transit or at rest” is not the same as “the proxy cannot read your text.” True end-to-end, where the middleman genuinely cannot see the content, is architecturally incompatible with handing that content to a third-party model that needs it in the clear. And this is the part worth being precise about, because it is a difference in kind, not in degree. Encryption protects the pipe, not the endpoints. Even a perfectly end-to-end-encrypted ppq still ends with two endpoints, ppq and the model vendor, holding your prompt in plaintext, because that is the only way either of them can act on it. The Spark sits a whole tier above that, not a notch. On the local stack the prompt crosses zero networks and reaches zero third parties; the only party that ever sees it is the operator at the keyboard. No amount of encryption bolted onto a cloud proxy reaches “the data never left the building,” for the simple reason that the data did leave the building. That gap is exactly what the local stack buys, and it is why ppq is a fallback for work you have already decided is not sensitive, never a replacement for on-device inference. The local stack exists precisely so the prompt never leaves a boundary you control. Every token you send to ppq is a token you have decided is not sensitive. Treat it that way, and never route private or client data through it. The ₿ payment is anonymous; the prompt content is not.

The honest exception: ppq’s own TEE models. Credit where it is due, because I tagged them and they earned it. ppq runs a set of private/* models, today private/glm-5-1 and private/gemma4-31b, inside hardware-attested confidential-compute enclaves (NVIDIA confidential GPUs, via Tinfoil). Your prompt is HPKE-encrypted in your own client before it leaves the machine, decrypted only inside the attested enclave where the model runs, and re-encrypted on the way back; ppq sees ciphertext and routing metadata, never the prompt or the completion. That is not marketing transport-encryption, it is a real hardware-enforced step above plaintext proxying, and it would be dishonest to wave it away. Two things still keep it a tier below the Spark. First, it covers ppq’s own open models, not the forwarded frontier vendors: the Claude fallback this article actually wires is plain claude-sonnet-4.6, which sits in no enclave and reaches Anthropic in the clear. To get the TEE guarantee you run their open-source private-mode proxy locally and call a private/* model, a different path from the one above. Second, even the enclave asks you to trust an attestation chain, Tinfoil, and NVIDIA’s confidential-compute, rather than only yourself. The sovereign reading is almost funny: if a model is open enough for ppq to run it privately for you, it is open enough to run on your own Spark with zero remote trust at all, which is exactly what I do with GLM and Gemma. The TEE tier is the right answer for someone with no local hardware who still refuses to let the host read their prompts. For the frontier-Claude job this article is about, the plaintext caveat stands.

It is not sovereign, it is convenient. You are trusting ppq’s uptime, ppq’s markup, ppq’s honesty about which model actually served the request, and the upstream vendor underneath. If Anthropic switches off a model, ppq’s access to it goes with it. The no-KYC payment removes the identity dependency, not the platform dependency. This is a fallback, not a foundation.

The markup and the rate limits are real. A reseller adds a margin, and a prepaid balance can run dry mid-task. I have hit exactly that: the key is wired, the account balance is zero, and the failover is therefore armed but not yet funded. That is a feature for budgeting and a footgun for an unattended agent. Fund it deliberately.

Disclosure, plainly. The links here are my referral. ppq pays 10% of a referred user’s spending (API usage excluded) as credit, which on this site goes back into running it. The ₿ marker is the site-wide convention for exactly this, explained on /support: a Bitcoin-payable link that also supports the blog. If that bothers you, ppq.aiAffiliate link. You support sovgrid at no extra cost to you. See /support. works identically without the invite path.

How I wired it (reproduce)

The whole point is that it is a drop-in. In openclaw, the local Qwen stays primary and ppq becomes the only fallback, with the key read from disk at runtime so it never lands in the config in plaintext:

# 1. define a file-backed secret source (key lives in a 0600 file, not in config)
openclaw config set secrets.providers.ppq \
  --provider-source file --provider-path /data/secrets/ppq.key --provider-mode singleValue

# 2. add ppq as an OpenAI-compatible provider + reference the secret for its key
#    (provider models: claude-sonnet-4.6, claude-opus-4.8, ...)
openclaw config set models.providers.ppq.apiKey \
  --ref-provider ppq --ref-source file --ref-id value   # singleValue mode: ref-id is "value"

# 3. routing: local Qwen primary, ppq/claude only as fallback
#    agents.defaults.model = { primary: qwen-vllm/qwen3.6-35b,
#                              fallbacks: [ppq/claude-sonnet-4.6] }

For opencode or goose it is the same idea: a provider block with baseURL: https://api.ppq.ai/v1, the key, and a model id like claude-sonnet-4.6. Because the models are mutex-swapped locally but ppq is remote, ppq is the one provider that is always reachable regardless of which local engine is resident, which is exactly what makes it a good failover target.

The possibility it opens: delegate, do not depend

The interesting pattern is not “use Claude instead of Qwen.” It is delegation. The local model owns the loop, stays private for everything routine, and hands off a single bounded subtask to a frontier model when it detects one it cannot do well, paying sats for that one call. The sovereignty stays with the local model that orchestrates; the cloud is a tool it reaches for, not a dependency it lives inside. ppq, because it is metered and no-KYC, is the cleanest way to wire that hand-off without taking on a subscription or an account.

Verdict

Keep the local models primary. They are private, free at the margin, and good enough for almost everything. But the sovereign answer to “what about the 5% only a frontier model can do” was never “give Anthropic your passport.” It is to pay per query, in sats, with no name attached, and to be honest that the prompt is leaving the building when you do. ppq.aiAffiliate link. You support sovgrid at no extra cost to you. See /support. is the door that fits the rest of the stack. Use it as the escape hatch it is, fund it on purpose, and never send it anything you would not put on a postcard.

Was this worth it? Zap the article.

Value for value, no signup. Sats go straight to the writer.