How to Pay for AI Without Being Known: Local, zkAPI, and Nothing Else That Counts

The prompt is the leak

Every question you type into an AI service is a document you handed to someone else. It leaves your machine, crosses someone's network, lands in a provider's logs, and (most of the time) trains on infrastructure you will never audit. If you accept that, "which model is smartest" is the wrong first question. The right one: who can see the prompt, and who knows it was me?

The news hook this week: on October 1 the Ethereum Foundation launched zkAPI, a mainnet system for paying for AI API calls without the payment being linked to you. Before scoring it, name what any "private AI" product is actually solving, because most answer one leak and stay silent about the other two.

The threat map: three leaks

Identity: can the provider link usage to you (an account, a bill, a payment trail)?
Content: can anyone (provider, relay, operator) read the prompt?
Network: can an observer see that traffic exists at all, and from where?

Fig. 1 - Stack from the bottom for full coverage: local first, zkAPI for frontier calls. Sources: EF blog Oct 1 2026, venice.ai, brave.com/blog/browser-ai-tee

The scorecard

Rating the field on our terms: threat coverage times trust assumed, with one honest question — can you verify it yourself, or is it somebody's word?

Fig. 2 - Five checks, five approaches: 5 = no trust needed / fully verifiable by you. Green clears our bar; amber conditional; red is a posture.

Two rungs survive that bar.

Rung 1: local, the only zero-trust tier

Ollama (OpenAI-compatible on localhost), LM Studio (MLX backend, fully offline), and llama.cpp underneath make serious open-weight models run on consumer and Apple Silicon hardware. Nothing leaves the machine, so identity, content and network all score 5 by construction: leaks of exactly zero kinds.

Limits are real and stated plainly: hardware ceiling, slower frontier-adjacent quality on hard tasks, zero specialization (your machine does the serving). For drafts, RAG, code assistance and anything sensitive, it wins outright. For frontier reasoning at scale, it does not — yet.

This is the only layer where nobody's word is involved. Including yours to us: run it airgapped, and the vendor's blog stops mattering.

Rung 2: zkAPI, the payment layer with no operator to trust

zkAPI ("private usage credits for any API") shipped October 1 by the EF's dAI team with the Open Anonymity Project, implementing a design Davide Crapis and Vitalik Buterin put on ethresear.ch. The mechanics, from the EF's own announcement:

You deposit ETH or USDC into a vault contract. The balance becomes a private note: committed, not exposed.
Spending is authorized by Groth16 ZK proofs (BN254 curve, Poseidon hashing, a 32-level Merkle tree); you prove you hold sufficient credits without revealing which credits or how many. Nullifiers prevent double-spend.
The developer experience is the clever bit: ephemeral, dollar-capped API keys minted on-device. The key binds to a spend ceiling and nothing else. The provider sees prompts; the payment layer sees spend; neither can link them.

Status, verifiable today: the vault is live on mainnet (ZkApiVault at 0x4386fdbda35d995beb3bf8625118ec5982ec81fe), the code is public (github.com/ethereum/zkapi), and OA Chat (chat.openanonymity.ai) runs it in the browser. This is not a promise of a product; it is a product.

Why it passes the bar: the trust assumption is the contract and the math, not an operator. The EF's own framing: the vault's exit path works even if every zkAPI server disappears. Censorship-resistance lives in the contract, not the frontend.

The honest limitations, straight from the same write-up. No network anonymity built in (their advice is Tor, fresh circuits per session). Prompt-content fingerprinting can re-link sessions: write distinctively and your sessions correlate again. Proxy mode, where offered, means a relay sees the traffic. And it does not seal content: zkAPI buys payment unlinkability, not prompt privacy. It is the top rung of a tower that still needs the bottom one.

What we're not buying

Policy-privacy chatbots: "no logs by default" is a posture, not an architecture. The claim is a server they own, a log they promise to skip, and an opt-out you will never find. One ToS rewrite and the posture is gone. If the privacy comes from a settings page, it isn't private; it's pending.
Gloss "anonymity": an anonymizing proxy tier covers the network hop while the account and the bill still name you. Selling that as "anonymous" is the kind of sentence this desk exists to call out.
Apple PCC / Google Confidential Inference, said fairly: best-in-class design — stateless, no retention, PCC even ships sepOS and iBoot in plaintext for researchers. But you extend deep trust to a vendor-graded hardware fleet you will never inspect, with closed weights, as a fully identified paying customer of the very company hosting it. Matthew Green's June 2026 read of the Apple-Google pairing is worth following for one reason: when both platform giants ship verifiable enclave serving, "we promise we don't look" dies industry-wide. That is progress. It is still not our recommendation; it is context for how high the bar is rising.
TEE-attested cloud, scoped honestly: Brave Leo's "Verifiably Private with NEAR AI TEE" (DeepSeek V3.1, NVIDIA-backed, attestation reports with model and code hashes) and Venice's Pro TEE/E2EE tier are good practice — the attestation report is a real artifact and you should read it. But it seals content only. The account, the bill and the operator's metadata log stay attached to you, plus three trust layers (hardware vendor, attestor, operator) that mostly go unexamined. For someone who must run a frontier model through a named account anyway, TEE is the right minimum: a content shield for a known identity. It is not one of the two rungs that clear the bar.

Fig. 3 - Where each option leaks, per its own docs. Amber = conditional pass, not one of the two rungs.

The takeaway

Sensitive thinking: local (Ollama / LM Studio), full stop.
Frontier quality, unlinkable payment: an open-weight model behind zkAPI-funded serving, over Tor.
Must run a named account on frontier models: TEE-attested serving, and read the attestation report yourself, not the vendor's blog.
Everything else in "private AI" is a subscription posture, and this desk rates postures accordingly.

Operational takeaway, same shape as the weights rule (from the delisting piece): vet your inference provider like you vet your weights. Read the attestation yourself. Check the vault contract on Etherscan, not in a tweet. A promise you did not check is a promise, not a property.

Sources

EF blog (Oct 1, 2026): "Introducing zkAPI: private usage credits for any API", Vittorio Rivabella, dAI Team; ZkApiVault 0x4386fdbda35d995beb3bf8625118ec5982ec81fe (Etherscan); github.com/ethereum/zkapi; OA Chat at chat.openanonymity.ai; ethresear.ch design by Davide Crapis and Vitalik Buterin
Venice.ai privacy documentation (venice.ai/privacy) and Venice blog (March 2026 Pro-tier TEE + E2EE announcements)
Brave blog: "Verifiably Private with NEAR AI TEE" (brave.com/blog/browser-ai-tee)
Apple, "Private Cloud Compute" security blog (security.apple.com/blog/private-cloud-compute); Matthew Green, blog.cryptographyengineering.com (June 9, 2026) on PCC + Google Confidential Inference
Ollama (GitHub); LM Studio (lmstudio.ai); llama.cpp (GitHub); Sitepoint guide to local inference
Edgeless Systems press on Privatemode AI (Mar 12, 2026); Azure Confidential AI documentation; NVIDIA Confidential Computing product line
Anuma, 2026 report grouping Brave Leo / Lumo / Venice as private-by-architecture
Delta V, "When a Model Gets Delisted" (Sept 30, 2026), for the weights-vetting continuity