![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Apr 9, 2026
\nAperture by Tailscaleis currently in alpha.
\nAperture routes all AI requests through a central proxy, giving organizations consistent visibility into AI usage. This page explains the four core mechanisms: identity and authentication, request routing by model, telemetry capture, and session tracking. Together, these enable auditing, cost awareness, and operational insight while letting teams safely adopt LLM clients.
\nTraditional API proxies require clients to authenticate with tokens or API keys. Aperture eliminates this step by using Tailscale's identity layer.
\nEvery connection to a tailnet carries cryptographic proof of identity. When a request arrives at Aperture, the proxy queries Tailscale with the remote IP address. Tailscale responds with the user's login name (for example, alice@example.com), a persistent device identifier, and any tags assigned to that device.
This identity is trustworthy because it comes from Tailscale's control plane, not from the client. A user cannot forge their identity without compromising Tailscale's key exchange.
\nThe identity flows through the entire system. Every metric record includes the login name and device ID. The dashboard filters by user. Access control uses roles derived from Tailscale tags.
\nClients connecting using ts-unplug also authenticate through Tailscale identity. Each ts-unplug instance joins the tailnet as its own device, so Aperture identifies requests by the ts-unplug device's login name. If each person runs their own ts-unplug instance, Aperture attributes activity to individual users. If multiple people share a single ts-unplug instance, all activity appears under the same identity.
\nWhen a tagged Tailscale device connects to Aperture, it does not have a user account associated with it. Instead, Aperture creates a synthetic identity from the device's tags.
\nAperture sorts the device's tags alphabetically and joins them with commas to create a stable login name. For example, a device with the tags tag:prod and tag:api appears as tag:api,tag:prod in dashboards, logs, and session tracking.
If a device has no user profile and no tags, identity resolution fails, and the device is denied access.
\nTo grant access to a tagged device, use this synthetic identity in the grant's src field (this applies to both grants and temp_grants — they use the same src JSON field with identical matching behavior):
tag:ci-runner:\"src\": [\"tag:ci-runner\"]\ntag:api and tag:prod:\"src\": [\"tag:api,tag:prod\"]\n\"src\": [\"*\"]\nFinding the correct tag string: To discover the exact tag string for a node, you can:
\nsrc: [\"*\"] to allow the node to connect, then observe the synthetic identity in Aperture's dashboards and tighten grants to the exact tag string.If all sessions from tagged nodes appear to come from the same user, refer to all sessions appear to come from the same user in the troubleshooting guide.
\nWhen a request arrives, Aperture extracts the model name from the request body (for example, claude-sonnet-4-20250514 or gpt-4o). The proxy looks up which provider serves that model and forwards the request to that provider's API endpoint, injecting the correct authentication headers.
From the client's perspective, the proxy appears as if it were the LLM provider itself. Clients connect to the proxy URL and send standard API requests. The proxy handles the routing transparently.
\nThe following table summarizes the supported API formats. For full provider details, including compatibility flags, see the provider compatibility reference.
\n| Format | Endpoint | Providers |\r\n| --- | --- | --- |\r\n| OpenAI Chat | POST /v1/chat/completions | OpenAI, OpenRouter, llama.cpp |\r\n| OpenAI Responses | POST /v1/responses | OpenAI |\r\n| Anthropic Messages | POST /v1/messages | Anthropic |\r\n| Gemini | POST /v1beta/models/{model}:generateContent | Google |\r\n| Amazon Bedrock | POST /bedrock/model/{model}/invoke | Amazon Bedrock |\r\n| Vertex AI | POST /v1/projects/{project}/locations/{region}/publishers/{publisher}/models/{model} | Google Vertex AI |
The capture system records everything needed to reconstruct and analyze each LLM interaction:
\nThe proxy processes telemetry asynchronously after the response completes, so clients receive responses without significant delay.
\nThe proxy handles two technical challenges transparently:
\ngzip, deflate, or Brotli) before storing them.A single coding task or conversation typically involves many LLM requests. A developer using Claude Code can generate 50 or more requests while debugging one issue. Without grouping, these appear as 50 unrelated events. With session tracking, they form a coherent unit you can analyze as a whole.
\nAperture groups related requests into sessions by detecting session identifiers from different client types. The following table describes how each client type identifies sessions:
\n| Client type | Identification method |\r\n| --- | --- |\r\n| Claude Code | Session ID included in each request body |\r\n| OpenAI Codex | Session ID sent as HTTP header |\r\n| OpenAI Chat | Fingerprint generated from conversation content |\r\n| Other clients | Random identifier assigned |
\nSessions enable conversation-level analysis. The Logs page of the Aperture dashboard groups requests by session, showing the full context of a coding session or chat conversation. You can review token costs per conversation rather than per request, trace how a coding assistant deconstructed a task, or identify which conversation consumed the most resources.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}