Drop-in proxy¶
The proxy records each AI call and forwards it to the real provider, so you get
request-level attribution without touching application logic. You change one
thing: the provider SDK’s base URL. The <your-venturi-instance> placeholder
below is your data-plane host in either deployment mode (see
Deployment modes); your onboarding contact
provides it.
Fail-open guarantee
The proxy runs on a hard latency budget. If Venturi is slow or unreachable, the request is forwarded to the provider anyway. The proxy can never block or fail your production traffic.
How it works¶
The proxy passes your request through unchanged (including your provider API key,
which Venturi does not store), captures metadata (model, tokens, latency, cost)
and emits an InvocationEvent. Request and response content exists only in
memory while being forwarded and is never written to access logs, error logs,
traces, queues, or exception payloads.
Endpoints¶
Relative to your Venturi instance host (provided during onboarding):
| Provider | Proxy base path |
|---|---|
| OpenAI | /api/v1/proxy/openai/v1 |
| Anthropic | /api/v1/proxy/anthropic/v1 |
| Amazon Bedrock | /api/v1/proxy/bedrock |
OpenAI example¶
Anthropic example¶
Attributing the call¶
To attribute beyond “this API key”, forward identity/service hints as headers your platform team configures (e.g. an identity header or your existing trace headers). Ask your onboarding contact for the header convention enabled on your instance.
Streaming¶
OpenAI and Anthropic Server-Sent Events are forwarded incrementally and token counts are derived from the stream. Bedrock non-streaming requests use the route above. Bedrock binary event streams are forwarded but are not parsed for token usage; those rows are labeled estimated rather than presented as complete request-level metering.
The decision-time interceptor that supplies routing guidance has a 50 ms P99 end-to-end budget; proxy forwarding remains fail-open if that budget is exhausted.