Simulates Gemini CLI Kiro client requests, compatible with OpenAI APIs. You can make thousands of Gemini model requests per day, and use Kiro’s built-in Claude model for free. Easily connect to any client through API to make AI development more efficient!
This project is called AIClient-2-API (by justlovemaki), and the following is an introduction to it + working principle + usage + precautions to help you understand:
1. What is the project?
AIClient-2-API is a proxy/adapter tool (HTTP service written in Node.js) that “emulates/encapsulates/proxies” multiple large model interfaces (such as Gemini CLI, Qwen Code Plus, Kiro-Claude, etc.) that can only be used in client/proprietary environments into a unified interface compatible with OpenAI APIs. In other words, if you have a client/app/tool that currently only supports calling OpenAI-formatted APIs, you can deploy this project and let it transparently call these other models without changing the client logic.
The official README says it can:
- Simulate client requests like Gemini CLI, Qwen Code+, Kiro Claude, etc.
- Provide an OpenAI API-compatible interface (which adheres to OpenAI’s request format) for clients or tools to use.
- Supports thousands of Gemini model requests per day; There is also “free access to the Claude model built into Kiro”.
2. Core functions/features
Here are some of its standout features:
| Function | Role/Benefits |
|---|---|
| Multi-model unified access | You only need to configure the model provider (Gemini, Claude, Qwen, OpenAI, etc.) to switch between different models through a unified interface. |
| OpenAI compatible interface | If the client or tool is designed to only support OpenAI’s API, it can also be directly connected to this service without much change. |
| Account pool / polling / failover / downgrade | If there is a problem with an account/token, it will be automatically switched. You can also downgrade some models if they are licensed or have limited services. Improve reliability and availability. |
| Architecture for Policy Patterns & Adapter Patterns | To facilitate the addition of model providers; Decouple API details from different service providers. |
| Log / prompt logging | All prompts can be logged for debugging, auditing, and even building your own private datasets. |
| Docker support | Easy to deploy and isolate environments. |
3. Working method / technical details
In simple terms, it works like this:
- Deploy this service (on-premises or on the cloud) and start an HTTP interface to listen for a port. Configure the model provider, OAuth credentials/tokens, etc. to be used.
- The client/tool (assuming the OpenAI API) sends the request to the AIClient-2-API address (e.g.
http://localhost:3000/v1/chat/completionsor similar path). - The service confirms which back-end model service to be configured. It could be OpenAI, Gemini CLI + OAuth, or Claude (via Kiro or via Claude’s own API), etc.
- Convert the request to the format required by the backend service, and handle the authentication, token, model name, etc.
- After receiving the results of the backend service, the result format (response body) is converted into the format expected by the OpenAI interface and returned to the client. It’s as if the client is actually calling OpenAI.
There are also some additional mechanics such as:
- Provide account pools: A provider can have multiple accounts/credentials, and automatically switch when one account has problems or reaches the limit.
- Request retry: If a request fails, it can be automatically retried (there are relevant parameters in the configuration).
- Control methods for system prompts: Override, append, dynamic, etc.
- Request log: Can be saved to a file.
4. Application scenarios / Who is it suitable for
This program is suitable for:
- If you have some clients or tools that only support the OpenAI interface format, but you want to use other models (Gemini, Claude, Qwen, etc.) and don’t want to change the client code, then you can use it to switch models “without change”.
- If you want to manage the credentials and accounts of multiple model service providers in a unified manner, you want to achieve high availability, reduce the single point limit, or improve resource utilization.
- I want to build a proxy in a local/private environment to debug prompts, log logs, control system prompts, or use it for experimental purposes.
- It is suitable for study/research/personal/small-scale projects; When used in a production environment, attention should be paid to stability, safety, and compliance.
5. Risks/precautions
- Legality/Terms of Service: Some models/service providers’ terms of use may prohibit bypassing quotas/API restrictions. The use of such proxies may conflict with the terms of the service provider, so be aware of contractual/policy issues.
- Security: You will put API token/OAuth credentials in the configuration/file, which may be leaked if not used correctly. Logs may record sensitive prompts/user content, be aware if it’s a privacy or trade secret.
- Stability & Maintenance: Because you rely on multiple third-party services (different models/OAuth processes/vendor policies, etc.), changes in any one place (e.g., OAuth process updates, API policy changes) may cause invalidation. Keep up with these changes.
- Performance & Latency: One more layer of proxies will have a little extra latency. Also, if the backend model is throttled/the service is slow, it will also affect the experience.
- Resource Consumption/Cost: While there are terms of “free” or “high request quotas,” these free quotas are limited and subject to change. Paid models/services may be required for heavy usage.
6. Summary
Overall, AIClient-2-API is a useful tool that can save you a lot of compatibility/interface adaptation if you want to switch between multiple model services and have a unified calling method (based on OpenAI’s format). It is more inclined to the role of agent/middle layer rather than providing the model inference itself.
Github：https://github.com/justlovemaki/AIClient-2-API
Tubing: