Daniel hit a moment of frustration using Claude Code's voice feature — the transcription was sloppy, the latency was bad — and he thought, what if I could just grab that API call mid-flight and route it somewhere faster? Turns out that question has an answer, and the answer is a lot more real than most people think.
It's not just real — it's a whole ecosystem now. routatic slash proxy, antigravity-claude-proxy, opencodex — these are all projects that have popped up on GitHub and they all do some version of exactly what Daniel's describing. Intercept the request, do something with it, send it back. The difference is what that "something" is.
And the difference between clever engineering and a Terms of Service violation. That's the line we're going to walk today. What these middleware proxy layers actually are, how they work under the hood, and whether building one is a dark art or just... reading the source code.
That frustration with voice latency is exactly where this starts. Because the question of whether you can intercept those requests — it's more answerable than you might think.
So let's define the thing. A middleware proxy for an AI tool sits between your client — Claude Code's CLI, in this case — and the backend API it's talking to. Every request, every response, flows through it. The proxy terminates the TLS connection locally, inspects the traffic in plaintext, and then forwards it wherever it wants.
And that "terminates TLS locally" part is the key. Your browser — or Claude Code — thinks it's talking directly to api dot anthropic dot com. It's not. It's talking to a proxy running on your own machine, on localhost, that's presenting a self-signed certificate you installed yourself. The proxy decrypts the traffic, reads it, optionally modifies it, re-encrypts it, and sends it on to the real destination. This is the exact same technique used by corporate firewalls and, well, malware.
So the architecture is fundamentally a man-in-the-middle attack that you're performing on yourself.
That's exactly what it is. And that framing matters because it clarifies what's happening technically and why it makes security people twitch. You're deliberately breaking the trust model of TLS. You're installing a certificate that says "I authorize this proxy to impersonate any website to me." If that certificate leaks, or if the proxy itself has a vulnerability, you've opened a hole.
But for the use case Daniel's describing, the proxy isn't attacking anything. It's just... rerouting. Walk me through the lifecycle of a single request.
Claude Code sends a POST to api dot anthropic dot com slash v one slash messages. The proxy captures it. The payload is JSON — it contains the model name, something like claude-sonnet-four hyphen twenty twenty-five zero five fourteen, the messages array with the conversation history, system prompts, tool definitions, and parameters like temperature and max tokens. The proxy can read all of that. It can log it, modify it, or completely rewrite it. Then it forwards the request — maybe to Anthropic's real API, maybe to a local Ollama instance running Llama three, maybe to OpenAI. The response comes back, the proxy captures that too, optionally transforms it, and returns it to Claude Code as if nothing happened.
And Claude Code doesn't notice?
Not if the proxy is doing its job right. The client sees a valid TLS connection to the domain it expects, receives responses in the format it expects, with the status codes it expects. But here's where it gets tricky — streaming responses.
Right, because Claude Code isn't waiting for the full response before displaying anything.
Server-Sent Events. The API streams tokens one at a time as they're generated. The proxy has to receive each chunk, potentially transform it — maybe remapping the format from OpenAI's streaming schema to Anthropic's — and forward it in real time. Every millisecond of processing the proxy does adds latency the user can feel. The antigravity-claude-proxy project benchmarks this at roughly two hundred to five hundred milliseconds of added latency per response.
So if the voice feature already feels slow, adding a proxy in the middle isn't going to help that particular problem.
Unless you're routing to a faster model. That's the tradeoff. You might add fifty milliseconds of proxy overhead but save three hundred milliseconds on inference if you're hitting a local GPU instead of a remote API.
Let's talk about why this is suddenly a thing. Claude Code being open-sourced — that's the catalyst, right?
Massive catalyst. When the source is on GitHub, you don't need to reverse-engineer anything. You can just read it. You can see exactly which endpoints are called — it's api dot anthropic dot com slash v one slash messages, by the way. You can see exactly which headers are sent — there's an anthropic-version header, there's x-api-key for authentication. You can see the exact request format, the error handling logic, the retry behavior. Building a proxy goes from "disassemble a binary and pray" to "read the source and write a handler."
So open-sourcing didn't just let people inspect the code — it gave them a blueprint for intercepting it.
And Anthropic had to know that. You don't open-source a client that talks to your paid API and think nobody's going to look at how it talks to your paid API. The question is what they expected people to do with that knowledge.
I want to get to the ethics and the ToS later. First, let me push on something. You said the proxy has to speak the exact same API schema as Anthropic. What happens when it doesn't?
It breaks. Sometimes subtly, sometimes catastrophically. If the proxy returns a four twenty nine rate limit response but formats the retry-after header differently than Anthropic does, Claude Code might not know how to back off — it might hammer the proxy with retries or crash entirely. If the proxy returns a streaming event with a different structure, the client's parser chokes. Protocol compatibility isn't optional — it's the whole game.
Give me a concrete example. Someone wants to route Claude Code to a local Llama three model through Ollama. What actually has to happen?
The proxy receives a request formatted for Anthropic's API. It strips the anthropic-version header because Ollama doesn't know what that is. It rewrites the model field from claude-sonnet-four hyphen whatever to llama three. It maps the messages format — Anthropic uses a content array with blocks, Ollama uses a simpler structure. The system prompt might need to be restructured. And then the response comes back from Ollama in its own streaming JSON format, and the proxy has to transform each chunk into Anthropic's SSE format, mapping fields like "done" to "stop_reason", converting token counts, handling tool calls if the local model even supports them.
Which most local models don't, at least not in Anthropic's format.
Tool use is one of the hardest parts. Claude Code sends tool definitions in Anthropic's schema — name, description, input_schema. If the local model doesn't support function calling in that format, the proxy has to either translate between schemas or strip the tools entirely and hope the model can fake it. Neither approach works perfectly.
So the proxy isn't just a dumb pipe. It's a translator between two languages that are similar but not the same, and the translation has to be perfect or the whole thing falls over.
And it has to happen in real time, chunk by chunk, without the client noticing. It's genuinely impressive engineering.
Alright. We understand the mechanism. Now let's look at who's actually building these things and why — because the ecosystem is more diverse than just "people trying to avoid paying for API calls."
I'd map it into three categories by intent. Privacy proxies, cost-saving proxies, and extensibility proxies. They all use the same technical foundation but solve fundamentally different problems.
Start with privacy.
routatic slash proxy is the cleanest example. It's a transparent logging proxy — it captures all traffic between Claude Code and Anthropic's API without modifying anything. Every request, every response, every header, every system prompt — it all gets logged locally. The proxy doesn't change the data, doesn't reroute it, doesn't transform it. It just records it.
So it's a debugging tool and a privacy audit mechanism rolled into one.
You run it for a day and you can see exactly what data your prompts are sending. What's in the system prompts Claude Code injects automatically? What tool definitions are being sent? What's in the conversation history that you might have forgotten about? It's visibility into a black box.
Because Claude Code is sending more than just your prompt. It's sending context, tool definitions, conversation history — things you might not realize are leaving your machine.
And routatic lets you see all of it before it goes anywhere. You can't modify it, you can't block it — it's purely observational. But that observation is powerful. It answers the question "what does this tool actually know about me and what is it sharing?"
That's the privacy proxy. What about cost-saving?
antigravity-claude-proxy is the poster child here. Its whole purpose is routing Claude Code requests to local models to avoid API costs. You run a model locally — Llama, Mistral, whatever — and the proxy translates Claude Code's API calls into requests your local model can handle. You get the Claude Code interface and workflow, but the inference happens on your own hardware.
Which means you're not burning through your Anthropic subscription.
Right. And the economics are interesting. If you're doing heavy development work, API costs add up fast. A local model on a GPU you already own has zero marginal cost per request. The tradeoff is quality — a local Llama three isn't Claude Sonnet four — but for many tasks, it's good enough.
And then there's the third category — extensibility.
opencodex. This one is more ambitious. It adds a plugin system to Claude Code through the proxy layer. You can write plugins that pre-process prompts before they're sent — adding context, reformatting, injecting instructions. And plugins that post-process responses — modifying output, extracting structured data, triggering actions based on what the model said.
So it's not just routing traffic, it's transforming the AI's behavior.
It blurs the line between proxy and framework. At some point you're not just intercepting API calls — you're building a new application layer on top of Claude Code. The proxy becomes the platform.
Compare those two philosophies — antigravity's model mapping versus opencodex's plugin architecture. They're both proxies, but they're doing completely different things.
antigravity is about substitution. Replace one model with another while keeping the interface identical. The proxy is a translator — its job is to be invisible. opencodex is about augmentation. Add capabilities that Claude Code doesn't natively have. The proxy is a platform — its job is to be extensible. One philosophy says "the proxy should disappear," the other says "the proxy should be where the interesting work happens."
And routatic is a third philosophy entirely — "the proxy should be a mirror."
Show you what's already happening without changing anything. Three projects, same technical foundation, three completely different visions of what a proxy is for.
Let's wade into the ethical and legal questions. All three of these projects have some version of "for educational and research use only" in their READMEs. What are they worried about?
Anthropic's Terms of Service. The ToS prohibit reverse-engineering and unauthorized access to their API. If you're using a proxy to avoid API calls entirely by routing to a local model, are you violating the ToS of a service you're not even hitting?
The second one seems harder to pin down. If I'm not touching Anthropic's servers, what exactly am I violating?
You're still using Claude Code, which is Anthropic's software. The open-source license — it's MIT, by the way — governs the code. You can modify it, redistribute it, do pretty much whatever you want with the code itself. But the Terms of Service govern the service. And the ToS say you can't reverse-engineer the service or access it through unauthorized means.
But building a proxy that routes to a local model isn't accessing the service at all.
Right, and that's where it gets legally murky. You're using Anthropic's client software to talk to a non-Anthropic backend. The client code is open source and MIT-licensed — you have permission to modify it. But you're also circumventing the intended use of the software, which was designed to connect to Anthropic's paid API. Is that a ToS violation? Probably not, if you never hit Anthropic's servers. Is it something Anthropic's legal team would be unhappy about? Almost certainly.
And if you are hitting Anthropic's servers through a proxy — like routatic does — you're accessing the API, just through an intermediary. The ToS say no unauthorized access. Is a self-signed certificate and a local proxy "unauthorized"?
The honest answer is that nobody's tested this in court. The practical answer is that Anthropic can revoke your API key at any time for any reason. If they detect proxy usage — and there are ways to detect it — they can just cut you off. No lawsuit needed.
What are the detection methods?
Certificate pinning is the nuclear option. The client would only accept a specific certificate from Anthropic's servers, not your self-signed one. That would break all proxies instantly. Request signing is more subtle — the client cryptographically signs each request with a key that the server can verify, and a proxy can't reproduce the signature. Behavioral fingerprinting is the most likely approach — Anthropic can look at request patterns, timing, header ordering, TLS handshake characteristics. A proxy inevitably leaves fingerprints.
But every countermeasure has a cost. Certificate pinning breaks enterprise audit logging tools that work the exact same way as routatic. Request signing breaks accessibility tools that need to inspect traffic. Behavioral fingerprinting generates false positives.
That's the arms race. Anthropic could lock things down, but every lock they add makes the tool less flexible for legitimate use cases. Enterprise customers want audit logging. Accessibility users want screen readers that can inspect what the AI is doing. Developers want debugging tools. All of those use cases look a lot like a proxy.
There's something else here that I think matters — the concept of implicit consent in open source. When Anthropic open-sourced Claude Code, they made a choice. They knew developers would study it, modify it, build things on top of it. That's the point of open source. Does that implicit consent extend to intercepting API traffic?
I'd say the community answer and the legal answer are different. The community answer is: you open-sourced the client, you knew people would figure out how it talks to your API, building a proxy is a natural extension of studying the source code. The legal answer is: the MIT license covers the code, not the service, and the ToS still apply to API usage. Those two answers don't have to be compatible.
They probably won't be resolved until someone with standing pushes the issue. Which nobody's going to do because nobody wants to get sued over a hobby proxy project.
The practical reality is that these projects exist in a gray zone and will continue to exist there. The API providers could crack down — and some have. In twenty twenty-five, several major AI providers updated their ToS to explicitly prohibit "intermediary services that modify API requests or responses." That language didn't exist before. It was added specifically in response to proxy projects like these.
The industry is aware and they're drawing lines. But enforcement is... selective.
It always is. Go after the commercial services that are reselling API access through proxies, ignore the individual developer running a logging proxy to debug their own prompts. That's the pattern.
Where does that leave us? Let me give you three things you can actually do with this knowledge.
First, if you're curious about building or using a proxy, start with routatic. Don't try to modify traffic — just observe it. Run it for a day and audit what data your prompts actually contain. You'll learn more about what Claude Code is doing — what headers it sends, what system prompts it injects, what data leaves your machine — than any documentation can teach you.
Second, understand the tradeoff you're making. Proxy projects give you control over latency, cost, and privacy, but they put you in a legal gray zone. Use them for local development and learning. Don't build a production workflow that depends on a proxy that could get your API key revoked tomorrow.
Third, and this is for the industry more than individual developers — the proxy ecosystem is a signal. Users want more control over their AI tooling. They want to choose their models, audit their data, extend their tools. The long-term solution isn't legal crackdowns. It's better API designs that natively support customization, plugin systems, and local model fallbacks. LiteLLM does this legitimately for multi-provider routing — there's a model for how to provide this kind of flexibility without violating anyone's ToS.
The proxy is a symptom. It exists because the official APIs don't give users enough control. Fix the APIs and the demand for proxies shrinks.
Not to zero — there will always be tinkerers — but the legitimate use cases get absorbed into the platform.
But the bigger question — the one I keep coming back to — is where this all goes as AI tools get more agentic. Claude Code already makes API calls, manages files, executes code. What happens when it's making calls to multiple services, chaining actions across different platforms, operating autonomously? Will proxy layers become a standard part of the stack, the way load balancers and API gateways are for web services?
I think they already are, just not in the way these GitHub projects implement them. Every enterprise deploying AI tools is going to want a layer between their users and the AI provider — for logging, for security, for cost management, for compliance. That's a proxy. It's just called an "API gateway" when a Fortune 500 company does it.
The difference is who controls it. The enterprise controls their gateway. The individual developer running antigravity controls their proxy. The user who doesn't know any of this exists controls nothing.
That's the tension that's not going away. The tools exist. The knowledge is public. The source code is open. The question isn't whether people will build proxies — it's whether the platforms will treat them as partners or adversaries.
Let me steelman the objection here. The strongest argument against all of this is straightforward: these proxies are circumventing a business model. Anthropic invests enormous resources in training models and building tools. They charge for API access to recoup that investment. Routing around their API — whether for cost savings or to use competing models — undermines the economic foundation that makes the tools possible in the first place. If everyone routed to local models, there'd be no Claude to build a proxy for.
That's fair. And I don't have a clean answer to it. The economics of open-source clients talking to paid APIs are unstable. But I think the counterargument is that the people running local model proxies were never going to be high-value API customers anyway — they're cost-sensitive developers who would churn the moment their free credits ran out. The proxy keeps them in the ecosystem, using the tool, building habits, contributing to the community. Some of them will convert to paid users when their needs outgrow what local models can do.
That's the optimistic read. The pessimistic read is that proxy projects normalize treating API access as optional, and the revenue erosion is real even if each individual user's contribution is small.
Both can be true. And I suspect both are true. The honest conclusion is that we don't know how this plays out — the proxy ecosystem is too new, the economics are too fluid, and the legal framework doesn't exist yet.
The proxy is a mirror. It shows us what we wish our tools could do — lower latency, lower cost, more privacy, more control. And it shows us what we're afraid they're already doing — sending data we didn't realize we were sharing, making decisions we can't audit, locking us into services we can't leave.
That's the image to sit with. Every proxy project is someone's answer to a question the official tools aren't answering. routatic answers "what is my AI actually sending?" antigravity answers "can I use this interface without paying per token?" opencodex answers "can I make this tool do things it wasn't designed to do?"
The fact that those questions need to be answered through a man-in-the-middle attack on your own traffic says something about the state of AI tooling.
It says the platforms haven't caught up to what users actually want. The proxy is a stopgap. The question is whether the platforms fill the gap before the stopgap becomes the standard.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. If you want to try this yourself, grab routatic slash proxy, run it for a day, and see what your AI tool is actually saying about you. It's the most educational thing you can do with a weekend and a self-signed certificate.
We'll be back soon.
