The cover does not pad the request.
@VitalikButerin posted at 10:48 UTC on October 16. https://x.com/VitalikButerin/status/2111046730959433793. When I read it, that post had 750 likes, 84 reposts, 263 replies, and 109,053 impressions. The short text says he wrapped zkAPI, Tor, extra cover traffic, and a local prompt rewrite into an OpenAI-compatible daemon, and a “paranoid mode” wrapper for his agent harness, pi. The long text says each conversation gets its own Tor circuit, the requests are masked with random cover traffic, zkAPI keeps the payment off your name, and every prompt is rewritten on a local model. He is using qwen3.8-flash-next. The link under that paragraph is a branch, not a release tag. https://github.com/vbuterin/zkapi/tree/feat/client-concession-local
I wrote on October 3 that the proof unlinks who paid. I wrote on October 4 that a local rewrite is not a deletion. This note is the cover sentence in today’s post. He says the requests are masked. The docs on the branch say the cover is other GETs.
What the branch calls cover
Cover is off unless you turn it on. The client README takes a list of URLs and a rate. The example is --cover-rate 5. The cover note says that number is mean attempted arrivals per second, about 300 a minute, not throughput you can count on. The allowed range is 0.01 to 5. In-flight requests default to 4, and stop at 8. You can name 1 to 16 HTTPS URLs, port 443 only. Each call is a GET. The body is thrown away. No prompt, no wallet credit, and no inference identity goes out on those calls. Use a small file you control, or one you have permission to poll. An older helper hammered third-party APIs by default. This one does not, unless you type those URLs in.
A response is cut at 64 KiB. The note says that if every response hits the cap, the response payload alone can exceed 1 GiB an hour, before TLS and Tor. The next sentence says more noise is not necessarily stronger anonymity. I am using both. I did not run the worker.
The arrivals do not follow the chat. They are random, and independent of prompts, completions, rewrites, and wallet activity. There is no burst when the daemon starts, and no catch-up if a worker is already busy. Each cover worker keeps one SOCKS identity for the life of the process. That identity is not taken from the conversation. The chat has its own.
Then the line the post does not paste. “This is background noise, not proven traffic-analysis protection.” A person on the machine can see extra traffic going into Tor. Someone at an exit may tell the cover hosts from the model host, and may tell a small GET from a streamed completion. The same paragraph says the worker does not pad the inference, does not hide the daemon starting or stopping, and does not make constant-rate encrypted traffic. It also does not touch the rewriter’s connection. Those calls go directly, outside Tor.
His next paragraph names a stronger adversary than a passive exit. Cover is okay against a passive observer. It is much weaker if the model provider is colluding with the guard and manipulating timing. He writes that this job needs a specialized mixnet, a higher bandwidth multiplier, and constant cover built in. The branch does not ship that. It ships the GETs, and his sentence that they are the weaker thing.
The task on the screen
The post says the images are a simple research task. I looked at them. The header reads pi v0.0.73, model openrouter/anthropic/claude-opus-4.1, through zkapi-clientd-tor. The ask on the screen is vegan restaurants in Tallinn. The harness curls a page on visittallinn.ee, then a Google search URL, and the answer is a five-row table. Two curls on screen are marked 6.0s and 5.1s. I am not adding those to his latency line. He wrote that a new conversation still costs a lot of latency. He did not put a number on it.
He also writes that the harness sits in a bwrap sandbox, with torsocks around that, so what the harness does goes through Tor. He is trying a MicroVM too. I have not watched those packets. The post is about the harness. The cover note is about the daemon. A GET from a cover worker and a completion from Claude are different requests, on different SOCKS identities, if Tor mode is on and IsolateSOCKSAuth is actually set. The daemon cannot read that flag through SOCKS. I am not going to treat “wrapped again with torsocks” as a check that the inference was padded. Nothing in the images shows a padded body. They show a table.
A useful answer named the city. That is the October 4 point, and I am not redoing it. The model in the screenshot is not the local rewriter. The README’s rewriter example is localhost, qwen3.8-flash-next, the model he named. The paid model on screen is Claude, through the daemon. The circuit carries that request. The cover calls are other GETs. The table is the answer that came back.
Not the installer
The branch page says this is not a production release. Concession network manifests are undeployed, and production proving keys are missing. The client README says the published clientd-v0.1.6 packages do not contain this branch’s privacy features, and not to use that installer to get this build. The privacy note says release builds load only the keys from a multi-party setup that has not run, so the packaged profiles are placeholders and no note can be funded. Turning the cover worker on does not open a vault.
The default key reuse window is still 60 seconds. In Tor mode an unrelated history rotates the key. A continuation can keep it. The provider can link requests that share a key. The privacy note also says a conversation identity is not a promise of a different exit IP, and not a defense against timing. He says the job needs constant cover on the real traffic. The branch documents dummy GETs beside it.
He writes that cheaper deposit and withdraw gas is coming to mainnet soon. I do not have the new figure.
If someone says the cover masked the chat, ask whether it padded the inference or sent a different GET. The note answers that. The request still left, at its own size, on its own circuit.