Unificando a Inferência de IA Multimodal: Por que você deve conhecer o AIClient2API

Ao criar aplicações de IA ou prototipar fluxos de trabalho agentivos, frequentemente precisamos experimentar vários modelos de linguagem grande (LLMs) para encontrar o ajuste ideal. No entanto, como diferentes provedores utilizam estruturas de API e protocolos distintos, alternar entre eles geralmente exige uma refatoração de código tediosa e atualizações constantes na lógica do seu backend.

O AIClient2API resolve exatamente esse desafio. Ele atua como uma camada de proxy inteligente que simula solicitações de cliente de plataformas como Gemini CLI, Antigravity, Codex, Grok e Kiro, encapsulando-as em uma interface de API única, padronizada e compatível com OpenAI. Além da unificação de protocolos, ele oferece um painel de Web UI para monitorar o status em tempo real de cada nó.

---

Principais Recursos

• Troca de Modelo sem Custo: Escreva seu código de integração uma vez usando formatos padrão do SDK da OpenAI e alterne entre provedores de backend dinamicamente sem modificar sua lógica de negócios.
• Console de Gerenciamento Visual: Inclui um painel de Web UI para gerenciamento de configuração em tempo real, monitoramento de status de saúde, testes de API via Playground integrado e auditoria de logs de solicitação.

---

Arquitetura Técnica e Implementação

O projeto baseia-se em uma arquitetura modular voltada para IA, construída em Node.js para lidar com a tradução de protocolos e manter alta disponibilidade:

plaintextCopy
1[ Sua Aplicação (Cherry-Studio / Cline / Código Personalizado) ]
2                           │ (Solicitação Padrão OpenAI / Claude)
3                           ▼
4            ┌─────────────────────────────┐
5            │     Gateway AIClient2API    │
6            └──────────────┬──────────────┘
7                           │
8             ┌─────────────┴─────────────┐
9             ▼                           ▼
10     ┌──────────────┐            ┌──────────────┐
11     │  Adaptadores │            │ Pool de Prov.│
12     └───────┬──────┘            └───────┬──────┘
13             │                           │ (Health Check / Cooldown)
14             ▼                           ▼
15     ┌──────────────┐            ┌──────────────┐
16     │ Sidecar TLS  │            │ Failover e   │
17     │ (Go uTLS)    │            │ Fallback     │
18     └───────┬──────┘            └───────┬──────┘
19             │                           │
20             └─────────────┬─────────────┘
21                           ▼
22   [ Backends: Gemini, Grok, Kiro...]

1. Padrões de Estratégia e Adaptador

Quando uma solicitação atinge o gateway, o sistema identifica o provedor de modelo alvo e a encaminha através de um adaptador de serviço específico. O adaptador traduz payloads padrão da OpenAI ou Claude para a estrutura exata exigida pelo cliente upstream (como a estrutura CLI interna do Gemini ou os endpoints do Grok), lidando perfeitamente com respostas padrão e de streaming (text/event-stream).

2. Pools Inteligentes de Provedores e Cadeias de Fallback

Para garantir confiabilidade de nível de produção, o proxy gerencia um pool de contas e endpoints:

• Health Checks e Cooldown Automatizados: O sistema realiza heartbeats periódicos. Se um nó falha ou dispara um limite de 429 Too Many Requests, ele é colocado em uma fila de cooldown temporária e contornado automaticamente.
• Fallback entre Tipos: Se um tipo inteiro de provedor ficar sem cota, o gateway pode cascatear as solicitações por uma cadeia de fallback pré-configurada (por exemplo, mudando de gemini-cli-oauth para gemini-antigravity), desde que os protocolos sejam compatíveis.

3. Simulação de Fingerprint TLS (Sidecar TLS)

Certos serviços upstream aplicam verificações de rede rigorosas e bloqueiam solicitações que não correspondem a fingerprints TLS de navegadores. Para resolver isso, o projeto incorpora um proxy Sidecar TLS escrito em Go (usando uTLS). Ele emula handshakes TLS padrão do Chrome e lida automaticamente com a negociação HTTP/2 para evitar erros 403 Forbidden.

---

Integração de Ecossistema: Suporte Nativo ao AtlasCloud

Em atualizações recentes, o AIClient2API introduziu suporte nativo ao AtlasCloud, uma plataforma de inferência de IA multimodal tudo-em-um.

O AtlasCloud agrega modelos altamente econômicos como Qwen 3.6, DeepSeek v4 pro, Kimi k2.6, GLM 5.1 sob um único endpoint. Integrar o AtlasCloud ao seu pool do AIClient2API oferece vantagens específicas:

• Troca Sem Emendas e Throughput Estável: Você pode alternar entre capacidades de raciocínio do DeepSeek, processamento de linguagem do Qwen e geração multimodal sem atrito. A infraestrutura empresarial subjacente garante taxas de concorrência estáveis.
• Templates prontos para uso: O repositório inclui predefinições de configuração no provider_pools.json.example, juntamente com caminhos de roteador dedicados, permitindo que você comece a operar imediatamente.

Esta configuração é altamente benéfica para desenvolvedores que participam do Coding Plan Promotion econômico do AtlasCloud para minimizar custos de infraestrutura.

---

Primeiros Passos

1. Implementar via Docker:
2. Bash

plaintextCopy
1docker run -d -p 3000:3000 -p 8085-8086:8085-8086 -p 1455:1455 -p 19876-19880:19876-19880 --restart=always -v "seu_caminho/configs:/app/configs" --name aiclient2api justlikemaki/aiclient-2-api

1. Configurar via Web UI: Acesse http://localhost:3000 (senha padrão: admin123) para adicionar suas credenciais e gerenciar seus provedores visualmente.
2. Roteie seu Tráfego: Aponte seu cliente de desktop de IA preferido ou SDK de backend para sua instância de gateway local.

Para detalhes completos de implementação, documentação e opções avançadas de configuração, visite o repositório no GitHub.

👉 AIClient2API