Schrijver: Lars Krombeen, Software Engineer
AI coding agents are most useful when they can work where developers work: inside the repository, with access to project structure, related files, and enough context to suggest meaningful changes. For many companies, using a public SaaS coding agent or an unapproved extension is not an option. This limits developers to a browser-based chat workflow. You can ask questions, paste snippets, and get useful help. But it is still a manual workflow:
The main limitation is context. The model only sees what you remembered to paste. It cannot inspect related files, follow references through the project or help make a consistent change across multiple parts of the codebase.
In a specific client case, we already had Azure AI Foundry available through an approved Azure environment, with centrally managed model deployments. Rather than looking for another external coding agent, we looked at whether we could connect an agent to the model infrastructure we already had.
Azure Foundry and Pi combined with a small local proxy was what we ended up building. The proxy translates the API calls made by Pi into the format supported by our Azure deployment. This gave us a repository-aware coding workflow while keeping model access and data processing within the company’s approved environment.
The Azure part
Our Azure AI Foundry resource was deployed in West Europe. This matters because models and API capabilities are not always available in every Azure region at the same time. A resource may be located in West Europe while capacity for a newer model is available in another European region, such as Sweden Central.
For our setup, Data Zone Standard made it possible to use models that were not directly available in West Europe while keeping processing within Microsoft’s European data zone. That met our requirements, but this is something every company needs to assess for itself. The second issue was API support. In our West Europe setup, the Responses API was not available for the deployment we wanted to use, so we had to access the model through the older Chat Completions API.
Pi, like several other modern coding-agent harnesses, uses the Responses API. It therefore could not communicate directly with our Azure deployment. We needed something in between that could accept the request Pi produces, convert it to a Chat Completions request and translate the result back into the format Pi expects. That became the job of the local proxy.
What we built
Our final setup looked like this:
Pi coding agent
-> local Responses API endpoint
-> local Node.js proxy
-> Azure OpenAI Chat Completions API
-> GPT model deployed in Azure AI Foundry
Pi sends its Responses API calls to the proxy running locally. The proxy converts those calls into the Chat Completions format supported by our Azure deployment and forwards them to Azure using an endpoint like this:
https://YOUR_RESOURCE.cognitiveservices.azure.com/openai/deployments/YOUR_DEPLOYMENT/chat/completions?api-version=2024-12-01-preview
When Azure returns a response, the proxy translates it back into the format Pi expects. The proxy is only a compatibility layer. It does not host a model or route the request through another external provider. The actual model request still goes to the Azure deployment that is part of our approved environment. This approach is not necessarily limited to Pi. It may also work for other coding-agent harnesses that use the Responses API but need to connect to an environment where only Chat Completions is available.
Create the Azure deployment
You need an Azure AI Foundry resource and a model deployment. In our case the setup looked like this:
Resource region: West Europe
Deployment type: Data Zone Standard
Deployment name: gpt-coding-eu
Model: a GPT model available for your subscription
Get the following values from Azure AI Foundry:
AZURE_OPENAI_BASE_URL=https://YOUR_RESOURCE.cognitiveservices.azure.com
AZURE_OPENAI_API_KEY=YOUR_AZURE_OPENAI_KEY
AZURE_OPENAI_DEPLOYMENT=gpt-coding-eu
AZURE_OPENAI_API_VERSION=2024-12-01-preview
Keep the base URL clean. Do not include /openai/deployments/… in it. The proxy adds that part.
Install Pi
Install Pi through npm:
npm install -g –ignore-scripts @earendil-works/pi-coding-agent
Check if it works:
pi –version
At this point Pi is installed, but it does not know anything about Azure yet. For that we need the local proxy and a Pi model configuration.
Create the local proxy
Clone the proxy repository:
https://github.com/lkrombeen/pi-azfoundry-proxy
The README.md explains how to configure the environment variables, connect the Azure deployment and start the proxy.
Once it is running, start with a small prompt to check the connection:
Summarize this repository and tell me how to run the tests.
You can also ask it about a specific file:
@README.md explain how this project is structured
If the configuration is correct, Pi will now use the model deployed in Azure AI Foundry through the local proxy.
Watch out for rate limits and cost
Coding agents send more context than you might expect. They inspect files, include conversation history and may request fairly large responses. Token usage and rate limits therefore become much more noticeable than they are in a normal browser chat. We hit 429 Too Many Requests several times while testing the setup. One setting worth checking is maxTokens.
Ours was configured as follows:
“maxTokens”: 128000
You can lower this value in models.json if your tasks do not require such large responses. You can also increase the tokens-per-minute quota for the deployment in Foundry when quota is available. For one developer experimenting with the setup, adjusting the token settings and quota was enough. If multiple developers start using the same deployment, it is worth looking at a more managed setup or provisioned throughput.
Cost also needs attention. With a suitable model for the work, our normal development usage was roughly between 10 and 20 euros per developer per day. That is not a fixed price, though. It depends heavily on the selected model, the amount of context and the types of tasks you give the agent. Using the wrong model can make a big difference. In our tests, choosing an unnecessarily expensive model could push usage towards 100 euros per developer per day. That is high enough that model selection should be a conscious choice rather than simply defaulting to the most capable model available. For routine repository exploration, straightforward code changes and smaller questions, a cheaper model may be more than sufficient. More capable models are better reserved for tasks where their additional reasoning actually makes a difference.
What this enables
The useful part of this setup is not really the proxy itself. It is the fact that we can now use a coding agent with repository context without sending source code to an unapproved provider or repeatedly copying anonymized snippets into a browser.
We reused an Azure AI Foundry environment that was already available within the company and added a relatively small compatibility layer. That let us, in this client case, try a better development workflow without first having to introduce a complete company-wide coding-agent platform. This is probably not the final architecture you would use for a large internal rollout. A broader setup would need proper authentication, monitoring, quota management, cost controls and support. For experimenting with the workflow and proving that it is useful, however, the local proxy has been enough.
The main takeaway for us is that company security requirements and repository-aware AI tooling do not have to conflict. When approved model infrastructure is already in place, the missing part may simply be a way to connect the development tool to it.
Deel dit artikel
BannerText_Seraphinite Accelerator