Why not perform API format conversion

You might be wondering: why don’t we convert all models into an OpenAI-compatible format like other proxy services do? This article will explain our design philosophy.

Core reason

1. Interface parameters vary greatly between different vendors

Each AI provider’s API has its own unique parameters and capabilities:

Forcing everything into a single format means:

• Forced to discard certain parameters — features not supported by the target format will be ignored
• Forced to add certain parameters — had to introduce default values for compatibility
• Inconsistent behavior — the same request may behave differently before and after the transformation

2. Specific characteristics of CLI tools

Using the Gemini CLI as an example, the official CLI interface requires a predefined prompt (System Prompt). If we convert this into the standard API:

Native CLI request → [translation layer] → standard API format ↓ lock part of the system prompt ↓ model behavior changes

The result is:

• The model’s capabilities are not fully represented
• Strange, hard-to-explain behavior occurs
• Users find it difficult to determine whether an issue lies in the conversion layer or in the model itself.

3. Unable to meet the advanced users’ fine-tuning needs

For developers who make extensive use of AI, precise control over model parameters is crucial:

<Callout type="warn"> Format conversion will result in:

• Inaccurate mapping of parameters such as Temperature and Top-p
• Advanced parameters for specific models cannot be passed through
• The chunk format for streaming output may change
• Token counting methods may be inconsistent

</Callout>

These details may be imperceptible to regular users, but for professional users who need to fine-tune models, they can be critical issues.

There are already mature solutions in the community

If you really need a unified API format, there are already very mature open-source solutions available in the community:

New API

New API is a powerful API management and transformation platform:

• Supports format conversion for multiple models
• Provide a complete log of the conversion process
• Customizable transformation rules
• Open-source and transparent, with issues that can be fully traced

One API

One API is another popular option:

• Unified management of multiple API channels
• Support load balancing
• Comprehensive limit management

<Callout type="info"> By using these open-source projects, you can: 1. Fully control the transformation logic 2. View detailed transformation logs 3. Adjust parameter mappings according to your needs 4. Quickly locate issues when problems occur </Callout>

Our design philosophy

• Ensure an authentic, official experience*

Our goal is to ensure that users have an experience that is completely consistent with the official API.

• ✅ One-to-one parameter mapping with no loss or tampering
• ✅ Response format is exactly the same as the official one
• ✅ Keep error messages unchanged to facilitate troubleshooting
• ✅ Immediate support for new features, no need to wait for adaptation in the translation layer

User request → AI Code With → Official API ↓ Passed through as-is, no modifications ↓ Official response returned as-is

Summary

We chose native passthrough because:

1. Professional users need precise control — the user experience must not be degraded due to limitations of a conversion layer 2. Easier troubleshooting — when issues occur, you can be sure they come from the model’s own behavior, not from an added conversion layer 3. Mature community solutions — if you need format conversion, there are better specialized tools available

<Callout type="info">

• Our commitment*: We guarantee that every model you use will provide an experience identical to the official one.

</Callout>

Related reading

• CLI vs API Pricing Differences — Learn why CLI and API pricing differs for the same model
• Route Selection — Choose the access route that works best for you