Skip to content

Support Bring Your Own API Key (BYOK) and Local Models via OpenAI-Compatible Endpoints #9367

Description

@raiyan-shaikh-510

Kiro Product

IDE

Feature Description

Currently, Kiro appears to be limited to its built-in model providers. It would be extremely valuable to allow users to connect their own AI providers and self-hosted models.

I would like Kiro to support:

Bring Your Own API Key (BYOK)
Custom API endpoints
OpenAI-compatible APIs
Local model providers
Self-hosted inference servers

Examples include:

Groq
OpenRouter
Ollama
LM Studio
vLLM
LiteLLM
OpenAI-compatible self-hosted endpoints

Proposed Configuration

Provider: Custom
Base URL: http://localhost:11434/v1
API Key: Optional
Model: qwen3-coder, deepseek-r1, llama-4, etc.

or

Provider: Groq
API Key: user-provided
Model: user-selected

This would allow Kiro to work with any provider that exposes an OpenAI-compatible API without requiring dedicated integrations for every new model vendor.

Use Case

Many developers already run their own AI infrastructure or have subscriptions with providers other than the default models supported by Kiro.

Common use cases include:

Using Groq for faster inference and lower cost
Running local models through Ollama or LM Studio
Using enterprise self-hosted AI deployments
Keeping source code inside a private network
Reducing AI costs by using existing API credits
Experimenting with different coding models
Using specialized models such as DeepSeek, Qwen, Llama, or custom fine-tuned models

For teams building commercial software, BYOK and local model support can significantly reduce operating costs while providing more flexibility and control.

Additional Context

Many modern AI development tools already support custom model providers and OpenAI-compatible endpoints. Supporting BYOK would make Kiro more attractive for developers who prefer self-hosted or third-party AI infrastructure.

A generic OpenAI-compatible provider would likely cover most use cases while minimizing ongoing maintenance effort for the Kiro team.

This feature would enable users to bring their own infrastructure rather than requiring Kiro to add native support for every new model provider individually.

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions