Introduction
AI-assisted coding has become part of the normal development workflow. Developers use AI to explain unfamiliar code, generate implementations, troubleshoot errors, refactor classes, and work through larger changes. But not every development team wants to use the same AI model.
A developer may prefer a particular model for coding, while an organization may already have an approved model deployment in its own environment. Some teams may also want to evaluate different models without changing their development environment.
This is where Bring Your Own Model (BYOM) in Visual Studio becomes useful.
Visual Studio now provides a BYOM experience that lets developers connect supported AI providers and use their own model deployments from the Visual Studio AI workflow. The current preview supports Microsoft Foundry, OpenAI, Anthropic, and Ollama, including custom endpoint support for OpenAI and Ollama. BYOM works with the newer Agent experience, giving developers a way to use a selected model while staying inside Visual Studio.
This article explains what Visual Studio BYOM is, how to configure it, how the workflow works, and what developers should consider before using it in a production environment.
What Is Visual Studio BYOM?
BYOM stands for Bring Your Own Model.
Instead of relying only on the AI models already available through the default Visual Studio experience, BYOM allows you to connect a supported external model or deployment.
The important distinction is that BYOM is about model choice. Your source code and development workflow can remain inside Visual Studio while the AI requests are handled through the provider or deployment you configure.
For example, a team might have:
Requirement | Possible approach |
|---|---|
General coding assistance | A supported cloud model |
Organization-approved AI | Microsoft Foundry deployment |
Model evaluation | Connect different providers |
Local experimentation | Ollama |
Custom endpoint | Supported OpenAI or Ollama endpoint |
Agent-based coding | Use the connected model in Agent mode |
Visual Studio's current BYOM preview supports Microsoft Foundry, OpenAI, Anthropic, and Ollama. Microsoft also notes that model capabilities can vary, so not every model supports every Agent capability.
Why Would Developers Use Their Own AI Model?
The main reason is control over model selection.
A development team does not necessarily want to choose an AI model only because it is the default option in an IDE. Different models can have different strengths, pricing models, context capabilities, latency characteristics, and organizational requirements.
BYOM can be useful when you need to:
Test a newer model.
Use an organization-approved deployment.
Work with a provider already used by your team.
Evaluate different models against the same coding tasks.
Use a local model for experimentation.
Keep the AI workflow inside Visual Studio instead of switching between tools.
For organizations, the deployment model can also matter. A team may already have governance or security controls around its AI infrastructure. Connecting Visual Studio to an approved deployment can fit that existing architecture more naturally than asking every developer to use an unrelated service.
How Visual Studio BYOM Works
The workflow is straightforward.
At a high level, the process looks like this:
Developer
|
v
Visual Studio
|
v
Chat / Agent
|
v
Selected Model Provider
|
v
AI Model
|
v
Response / Tool Actions
The developer selects a model provider from Visual Studio's model management experience. Visual Studio then uses that configuration when working with the model through the supported AI experience.
The exact capabilities available depend on the connected model.
For example, one model may work well for conversational coding assistance but not support a particular Agent capability. Visual Studio indicates unsupported capabilities rather than assuming that every connected model behaves identically.
This is important because connecting a model does not automatically make every AI feature available.
How to Add Your Own AI Model in Visual Studio
The current BYOM workflow is available through the newer Agent experience.
Step 1: Open Visual Studio Chat
Open the Chat experience inside Visual Studio.
The model picker is where you can manage the models available to the AI experience.
Step 2: Open the Model Picker
Open the model picker and select Add a model or Manage Models.
Microsoft's current setup flow uses this area to connect an external provider.
Step 3: Add a Model Provider
Select the option to add a model provider.
Depending on the provider, Visual Studio may require authentication information, an API key, deployment information, or an endpoint.
For example, a simplified configuration concept could look like this:
Provider: OpenAI
Endpoint: https://your-endpoint.example
Model: your-model
Authentication: API Key
The actual values depend on the provider and deployment you are using.
Do not hard-code API keys into source code or project files.
Step 4: Select the Model
After configuring the provider, select the model from the available model options.
You can then use that model from the supported Visual Studio AI experience.
Step 5: Start Agent Mode
The current BYOM implementation works with the newer Agent (Preview) experience.
This distinction matters because the older BYOM workflow is no longer the current path. Microsoft states that BYOM now works with the new Agent experience, while the earlier BYOM experience in the previous Ask and Agent modes is no longer supported.
A Practical Coding Workflow
Suppose you are working on an ASP.NET Core application and need to add validation to an existing API.
Instead of asking the model to generate an isolated code snippet, you can give it a development task that involves the existing project.
For example:
Review the CreateOrder endpoint.
1. Identify where request validation currently happens.
2. Add validation for missing CustomerId.
3. Check whether similar validation already exists elsewhere.
4. Keep the existing response format.
5. Update or add tests for the new validation.
6. Explain the files that need to change before making the changes.
This type of request is more useful for an agentic development workflow because the model can reason about the task in the context of the project rather than simply returning a standalone code sample.
The model still needs to be treated as an assistant. Developers should review generated changes, particularly when the agent can modify multiple files.
BYOM vs Built-In AI Models
BYOM does not necessarily replace the models already available in Visual Studio.
It gives developers another option.
Area | Built-in model | BYOM |
|---|---|---|
Model selection | Based on available Visual Studio/Copilot options | Developer chooses supported provider/model |
Provider control | Limited to available integrations | More provider flexibility |
Organization deployment | Depends on available configuration | Can connect to supported approved deployments |
Local experimentation | Depends on supported options | Ollama can be used |
Model evaluation | Possible within available models | Easier to evaluate external models |
Setup | Usually simpler | Requires provider configuration |
Capability consistency | More predictable | Depends on connected model |
The trade-off is straightforward: BYOM provides more choice, but more choice also means more configuration and compatibility considerations.
Using BYOM With Local Models
One interesting option is Ollama.
A developer can use a local model for experimentation where a suitable local model and machine configuration are available. The current Visual Studio BYOM preview supports Ollama and custom endpoint support for Ollama.
A simplified architecture looks like this:
Visual Studio
|
v
Agent
|
v
Ollama Endpoint
|
v
Local AI Model
This can be useful when experimenting with local AI infrastructure or evaluating models without making every development task depend on a cloud provider.
However, local execution does not automatically mean that a model will provide the same capabilities as a cloud model. Hardware resources, model size, context limits, response speed, and Agent capabilities all need to be considered.
Production Considerations
BYOM is particularly interesting for enterprise development teams, but it should not be treated as simply a model-picker feature.
Security
API keys and credentials should be handled securely.
Avoid configurations such as:
var apiKey = "my-secret-api-key";
Instead, use appropriate credential storage and environment-specific configuration.
For local development, environment variables or a secure developer secret mechanism may be appropriate. For organizational deployments, use the company's approved secret-management solution.
Data Governance
Before connecting a model provider, understand what information is sent to that provider.
Source code can contain:
Proprietary algorithms
Connection strings
Internal URLs
Credentials
Customer information
Business logic
Security-sensitive configuration
Developers should verify the organization's policies before connecting an external model.
Model Capability
Do not assume that every model supports every Agent capability.
Microsoft explicitly notes that model capabilities vary in the current preview.
Test the workflows your team actually uses rather than judging a model only by its text-generation quality.
Reliability
If AI assistance becomes part of a development workflow, consider what happens when the provider is unavailable.
Your build, test, deployment, and source-control processes should remain independent of the AI service.
AI should assist development, not become a required dependency for compiling or deploying the application.
Best Practices for Using BYOM
1. Use approved model providers
For enterprise projects, use providers and deployments approved by your organization's security and compliance teams.
2. Separate development and production credentials
Do not use production credentials for everyday development experimentation.
3. Test models against real development tasks
A model that performs well on simple code generation may behave differently when asked to modify a large repository.
Test tasks such as:
Debugging
Refactoring
Unit-test generation
API implementation
Documentation
Repository navigation
Multi-file changes
4. Review agent-generated changes
Never assume that generated code is correct simply because it compiles.
Review:
Business logic
Security
Exception handling
Performance
Dependency changes
Database operations
Tests
5. Keep AI configuration separate from application code
Provider credentials and model configuration should not become part of the application repository unless there is a specific, reviewed reason to store non-sensitive configuration there.
Common Mistakes
Assuming Every Model Supports Every Agent Feature
This is one of the easiest mistakes to make.
BYOM gives you model choice, but model capabilities differ. Check the capabilities required by your workflow before standardizing on a provider.
Putting API Keys in Source Control
Never commit API keys to Git.
Even a private repository is not a safe place for secrets by default.
Treating BYOM as a Replacement for Code Review
AI-generated code still needs human review.
The developer remains responsible for the final implementation.
Ignoring Provider Costs
Using your own provider means the provider's pricing and usage policies matter.
A model that looks inexpensive for occasional experimentation can behave differently when used repeatedly across a development team.
Assuming Local Models Are Automatically Better for Sensitive Code
Local execution can change where inference happens, but security depends on the complete environment, including the machine, model, endpoint, logging, credentials, network configuration, and surrounding infrastructure.
Advantages of Visual Studio BYOM
More freedom to choose AI models.
Access to supported external providers.
Ability to connect organizational model deployments.
Support for local-model experimentation through Ollama.
AI assistance remains within the Visual Studio workflow.
Useful for comparing different models against development tasks.
Can support teams with specific governance or infrastructure requirements.
Disadvantages and Limitations
The current experience is a preview.
Not every model supports every Agent capability.
Provider configuration requires additional setup.
Different providers can have different authentication and usage models.
Local models may require significant hardware resources.
Teams need to evaluate security and data-governance requirements.
Model behavior can change independently of the Visual Studio IDE.
Microsoft describes BYOM as an evolving preview and notes that additional provider support, model controls, centralized configuration, and governance capabilities are areas being developed.
Troubleshooting Common BYOM Problems
Model Does Not Appear
Check that the provider was added successfully and that the model is available through the configured provider.
Also verify that you are using the current Visual Studio experience that supports the current BYOM workflow.
Agent Feature Is Unavailable
The connected model may not support the capability required by that Agent feature.
Try another supported model and compare the available capabilities.
Authentication Fails
Check:
Provider credentials.
Endpoint configuration.
Model or deployment name.
Network connectivity.
Provider-side access permissions.
Avoid repeatedly changing application code when the problem is actually provider configuration.
Ollama Model Does Not Work as Expected
Confirm that the Ollama service is running, the endpoint is reachable, and the selected model is available.
Also remember that local models can have different capability and context limitations from cloud models.
When Should You Use BYOM?
BYOM makes the most sense when model choice is itself an important part of your development workflow.
It can be useful for:
Enterprise teams with approved AI deployments.
Developers evaluating multiple models.
Teams experimenting with local AI.
Organizations with specific infrastructure requirements.
Developers who want more control over their AI provider.
For a developer who simply wants the default AI experience and does not need additional provider control, the extra configuration may not provide much value.
Summary
Visual Studio BYOM gives developers another way to work with AI without being limited to a single model choice.
The current experience allows supported providers such as Microsoft Foundry, OpenAI, Anthropic, and Ollama to be connected to Visual Studio's AI workflow. It works with the newer Agent experience, although model capabilities vary and the feature remains a preview.
The biggest benefit is flexibility. Developers can select models based on their technical requirements, while organizations can explore approved deployments and different AI infrastructure options.
The important part is to treat BYOM as an engineering decision rather than simply an IDE setting. Model capability, security, data governance, credentials, cost, reliability, and developer workflow all matter.
For teams already using AI heavily inside Visual Studio, the ability to bring a preferred model into the development environment can make model selection a much more deliberate part of the engineering workflow.
Join the conversation! Your thoughts help the community grow.