On the architecture question: today it's pass-through per request, but not "per key" the way you mean. Your nullsink token authenticates against a local balance ledger and is never forwarded — every request goes upstream under a single shared account key, so the provider sees all users commingled under one identity, with no per-user key to cluster on. Client/SDK fingerprints (user-agent, x-stainless-*, org, referer) get stripped or normalized too.
On the architecture question: today it's pass-through per request, but not "per key" the way you mean. Your nullsink token authenticates against a local balance ledger and is never forwarded — every request goes upstream under a single shared account key, so the provider sees all users commingled under one identity, with no per-user key to cluster on. Client/SDK fingerprints (user-agent, x-stainless-*, org, referer) get stripped or normalized too.
Architecture discussion lives here if you want to dig in: https://github.com/nullsink/nullsink/issues/58
That's the shipped state. It's still early — on the roadmap the metering proxy moves into a sealed enclave, and, related to your interleaving instinct, traffic mixing is a planned capability: https://openanonymity.ai/blog/unlinkable-inference/#22-traffic-mixing