[sdk] tag API requests with the detected AI agent - #320
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
alexfarnhambrown
left a comment
alexfarnhambrown
left a comment
There was a problem hiding this comment.
Checked where this header could land: no sandbox table in PRODUCT has a user_agent column — not the usage facts, not any sandbox event-streaming topic. So both this and #319 depend on an ingestion change that doesn't have a ticket or owner yet. If the landing place is the sandbox usage-fact pipeline, that's the same pipeline we need a failure status from, so it's probably one ask rather than two.
The upside is real though: the composed header separates CLI-driven from programmatic from agent-driven with no join required, which is a split we can't currently make.
|
|
||
| // Attribute traffic to the AI agent driving this process, if any, so the | ||
| // server side can record it once ingestion support lands. | ||
| const aiAgent = await detectAgentName(); |
There was a problem hiding this comment.
The SDK has no telemetry setting, so once the server side records this header there's no way to opt out of agent attribution, and the CLI's VERCEL_TELEMETRY_DISABLED won't cover SDK traffic. That's request metadata now but collected data the moment ingestion lands, and cheaper to settle before a public SDK ships it. Recommend either honouring VERCEL_TELEMETRY_DISABLED here or documenting that this stamp isn't covered by it.
There was a problem hiding this comment.
Half of this is closed — detectAgentName() now returns undefined when VERCEL_TELEMETRY_DISABLED or VERCEL_SANDBOX_TELEMETRY_DISABLED is set.
What's left is the config-file case: someone who ran vercel telemetry disable has enabled: false in config.json and no env var set, and the SDK can't see that, so they'd still get agent/<name> on the user-agent. The CLI path in #319 handles it through telemetry.enabled; the SDK has no equivalent. Looks like the automated review landed on the same point today.
Not urgent from our side — no sandbox table in PRODUCT has a user_agent column, so nothing reads this header yet. Leaving open in case you want to close the config-file case before something does.
|
You must have Developer access to commit code to Vercel Labs on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes. Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles |
![vercel[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
3 participants
Stacked on #319, which added the
agent/<name>user-agent phrase to the CLI. This extends the same stamp to the SDK, so programmatic callers get attributed too once the server side records the header (same ingestion ask, no new dependency on it).This:
agent/<name>to the SDK's existing user-agent whendetect-agentidentifies an AI agent driving the process; no agent means the header is byte-identical to todaydetect-agent@1.2.0as an SDK runtime dependency (zero transitive dependencies, node >=20 which the SDK already requires)Deliberately not added: telemetry events. The SDK ships in customer production code; this is request metadata only, nothing is collected or sent anywhere new.
Verified:
env -u CLAUDECODE -u CLAUDE_CODE -u AI_AGENT(a deployed server's environment):vercel/sandbox/3.2.0 (Node.js/v26.7.0; darwin/arm64), unchangedagent/occurrence in the final headerpnpm turbo typecheck --filter=@vercel/sandbox --filter=sandbox --force: 4/4; CLI suite 101 passed; SDK suite 291 passed, 80 skipped (pre-existing live-credential skips)Detection only labels the process driving the SDK, so servers creating sandboxes to run agents inside them correctly carry no label; that population is the planned self-declared tag, not this PR.