The Claude Agent SDK is Claude Code packaged as a library: you call it with a prompt and options, and it gives you the full agent loop and built-in tools for reading and writing files, running bash, searching and fetching the web, plus MCP servers and subagents, running on your own infrastructure. People use it to build agents that do real work against the open web: research agents, monitoring agents, data-collection agents, agents that log into a service and pull a report. Those agents need proxies, and this guide is about where the proxy goes, because the answer is specific and easy to get wrong.
The two-part rule from our AI coding tools explainer holds here: the SDK's own model calls do not want a proxy, and the web the agent reaches does. The SDK just makes the second part bigger, because an agent fetches far more of the web than a chat session does.
The built-in web tools run through Anthropic
Start with what a proxy does not touch. The SDK's built-in WebFetch and WebSearch tools, like Claude Code's, run their fetching and searching through Anthropic's infrastructure rather than your local HTTP client. Setting HTTPS_PROXY does not route them, and it is not supposed to: those tools are for the agent's own light lookups, and Anthropic handles their egress. So the built-in tools are the wrong hook for "fetch these thousand pages from a residential IP in Germany." For that you use your own tools, where you control the client.
Where the proxy actually goes
Two places, both under your control.
Custom tools that fetch. When you give your agent a custom tool that requests a URL, that tool runs your code with your HTTP client, and the proxy goes there, exactly as in a standalone scraper. In Python that is a proxy on requests, httpx or aiohttp; in Node it is an agent on fetch or axios. The library guides have the exact lines: Python requests, httpx, aiohttp, Node.js and axios. Putting the proxy in the tool, rather than process-wide, lets you rotate per request or hold one sticky exit per task, which is what a stateful agent needs.
Scraper code the agent runs in bash. If your agent writes and runs a scraper through the bash tool, that scraper is ordinary code and the proxy goes in it, with the type matched to the target: a rotating residential exit for defended sites and a sticky ISP one for logged-in steps, as in proxies for browser-use and proxies for web scraping.
Process-level HTTP_PROXY / HTTPS_PROXY still has a role: it covers reachability, letting the SDK's own model connection reach Anthropic from a network or country that blocks it, the same narrow case as Claude Code. But for the agent's website traffic, per-tool proxies beat one process-wide setting, because different tasks want different exits.
Your proxy, your control
Custom tools that fetch URLs
proxy in the tool's HTTP client
Scraper code run via bash
proxy in that code
Per-task sticky exits
one identity per multi-step task
Not your proxy
Built-in WebFetch / WebSearch
run through Anthropic, not your client
The model calls
your account; quota follows the key
Reachability only for HTTPS_PROXY
unblock the Anthropic connection, nothing more
Sizing for an agent, not a script
An agent differs from a plain scraper in one way that matters for proxies: it holds identity across steps. When your agent logs in, navigates and acts as one coherent visitor, that whole task wants one sticky exit, then the next task takes a fresh one, so the two never collide on a single IP. Size a pool by how many tasks run at once rather than by request rate, and give any long, logged-in task its own ISP address. For stateless fan-out, where the agent fires many independent lookups, rotating residential per request is right. This is the same pattern as any browser agent, and proxies for AI agents covers it in full.
Where HProxy fits
For the custom tools and scraper code your Agent SDK agents run, give the fetching tools a residential exit from $0.44/GB on defended sites and an ISP address at $2.70/IP a month for a task that stays logged in, priced on use with no KYC and sized to the tasks you run at once. Put the proxy in each tool's HTTP client, leave the built-in web tools and the model calls alone, and confirm any exit with the proxy checker. The tool-level view of the same picture is in proxies for Claude Code, and the whole cluster in proxies and AI coding tools.
Sources
- Anthropic, Claude Agent SDK documentation (
code.claude.com/docs/en/agent-sdk): the SDK as Claude Code's agent loop offered as a library, with built-in file, bash, web and MCP tools and subagents. - Claude Code, Enterprise network configuration: the
HTTP(S)_PROXYvariables shared by the SDK's runtime for process-level traffic. - HProxy, proxies for AI agents, proxies for web scraping and the library guides linked above.