AIClient has one set of interfaces to access multiple different models?

By /

AIClient-2-API is a free Node.js reverse proxy tool that converts AI models that only support client calls (such as Gemini 3 Pro, Claude 4.5 Opus, Tongyi Qianwen 3 Code Enhancement, Kiro, etc.) into unified and easy-to-use native APIs that are compatible with the OpenAI interface specification, which you can run directly through Docker containers or scripts.
Locally access the localhost:3000 address to open the web console, where you can add keys, switch models, monitor running status, and log conversations – for tools like Cherry-Studio, you can directly integrate and use them without modifying any code.
With this tool, you can seamlessly call a wide range of high-quality, free or low-cost advanced AI models. Breaking through interface limitations through intelligent account pool technology to achieve 99.9% service availability. Significant cost savings and the ability to build your own private dataset based on conversation logs.

Almost everyone who makes AI applications encounters a very real problem:

Models are growing like crazy, but interfaces are becoming more and more fragmented.

OpenAI、Claude、Gemini、Qwen、Kiro……
Each company has its own call method, authentication logic, and parameter format.

But at the same time, a large number of mature tools (chat UI, plugin systems, Agent frameworks) only support the OpenAI API.

This creates a very awkward situation:
The number of models is increasing, but the complexity of the project is increasing exponentially.

An engineering problem that has been encountered repeatedly

Let’s say you already have a full-fledged system:

  • UI / Agent / Plugins
  • Completely based on OpenAI API
  • Call path fixation:/v1/chat/completions

Now you want to do any of the three things:

  • Connect to Gemini
  • Switch Claude
  • Try the effect or cost with Qwen / Kiro

You will find a fact:

You are not “changing the model”, you are “rewriting the interface layer”.

The AIClient-2-API project is essentially an engineering answer to this question.

What is AIClient-2-API?

Summary in one sentence:

AIClient-2-API is an API proxy service that unifies the call methods of different AI clients/models into OpenAI APIs.

For upper-layer applications:

  • You think you’re calling OpenAI
  • The actual underlying may be the Gemini / Claude / Qwen / Kiro / CLI client

The upper level is completely insensitive.

What does this project solve?

OpenAI API is already the de facto standard

Whether you like OpenAI or not, there’s a reality that can’t be avoided:

OpenAI API has become the de facto industry protocol.

A large number of ecology is directly written to death:

  • Request structure
  • role design
  • Return to formatting
  • Flow cytometry specifications

The strategy of AIClient-2-API is not to “reinvent the interface”, but to completely adapt to this reality.

What is done is not a model, but a “protocol translation”

From an engineering perspective, it is more like this layer structure:

应用 / Agent / UI
 ↓
 OpenAI API 协议
 ↓
 AIClient-2-API
 ↓
 Gemini / Claude / Qwen / CLI

It only cares about three things:

  1. How to receive the request
  2. Request how to convert
  3. How responses return uniformly

The model itself is not the point, but the interface consistency.

Why can it access the “unofficial API/CLI model”?

This is the most concerned point for many people when they see this project.

AIClient-2-API does not only support the official API, but:

  • Gemini CLI support
  • Client authorization mode is supported
  • Support for non-standard model call flows

Its idea is:

Since the client can use it, there must be a reusable call path.

These capabilities are “servitized” by simulating client authorization, token management, request encapsulation, etc.

From an engineering point of view, this is a reverse-biased + biased adapter work, not a model-level innovation.

About risk and boundaries

There are some boundaries that naturally exist for such projects:

  • Unofficial interfaces may fail at any time
  • The client protocol may be modified
  • Commercial compliance requires self-assessment

AIClient-2-API is not an “official solution” but a utility under the engineering trade-off.

Whether to use it depends on your scenario and risk tolerance.

It solves “interface fragmentation”

If we look at it from a broader perspective, the existence of such projects itself says one thing:

The problem of large models has shifted from “model capabilities” to “engineering integration costs”.

The value of AIClient-2-API is not how many models it supports,
It is that it acknowledges and addresses a reality:

Unified interfaces are more important than chasing models.

Github：https://github.com/justlovemaki/AIClient-2-API
Tubing:

Scroll to Top