Request flow: User, Relay, Worker and Partner

Four components

Component	Responsibility
User Client	Local API/keys, caller recognition, remote verification and encrypted sessions
Relay	Permissions, routing, lifecycle, accounting/records, published configuration and ciphertext forwarding
Attested Worker	Protected request processing, conversion, upstream calls and execution/usage evidence
Partner Client	Supplier account connection/maintenance, local login synchronization and egress

Users and suppliers can operate on different devices. Worker is not your local coding Agent.

One request

Tool / HTTP caller
  → local endpoint and key
User Client
  → routing preparation, verification and encryption
Relay
  → ciphertext
Verified Worker
  → selected account and egress
Model provider
  → response back through the chain
Local Agent executes its own tools

The Worker calling a model does not execute coding commands in your real project.

Partner and records

Hosted and local accounts differ in renewal/egress; see Hosted accounts and Local synchronization. Client/proxy exits must remain online. Local synchronized supply does not silently become cloud Worker egress.

Local diagnostics cover early processing, platform usage covers request/business states, Worker evidence covers execution, and wallets/earnings reflect settlement. A local failure without a platform record or a returned response awaiting settlement can represent different stages. Correlate request IDs.

Visibility

Relay needs business metadata such as account, routing, price and state. Bodies use Client–Worker encrypted sessions; Worker and the final provider process inference input. Real information written into prompts is not automatically anonymized by directory mapping.

The tool's other telemetry, browser traffic and external logins are not necessarily this same chain. See TEE trust.