> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Is the Difference Between Official-Relay and Reverse-Engineered APIs?

> APIYI is official-relay by default. Compare official-relay and reverse-engineered APIs on stability, protocol compatibility, caching, concurrency, and long-term sustainability, and learn how to choose between Claude_Reverse, Codex_Reverse, Gemini_Reverse, and official-relay groups.

## Short answer

**Official relay** means resources forwarded through a vendor's official API or official cloud marketplace. **Reverse-engineered (reverse)** means access obtained through unofficial interfaces. When both routes call the same model, single-turn answers can be very close. The real differences are **stability, protocol compatibility, feature completeness, cache efficiency, concurrency, and long-term sustainability**.

* **APIYI is official-relay by default.** Reverse groups are a supplement for personal learning, cost-sensitive workloads, and non-critical tasks.
* Production workloads, coding Agents, and enterprise customers: prefer official relay.
* Personal learning, simple chat/translation/summarization, and cost-sensitive workloads: reverse groups are usable.
* APIYI currently has exactly three text/coding reverse groups: `Claude_Reverse`, `Codex_Reverse`, and `Gemini_Reverse`. Other vendors' text models use the official-relay `Default` / `SVIP` groups by default.
* Image `-all` / `-vip` models are a separate reverse line, mostly served by `Default`; some models that need URL output use `image2_OSS`. Check the console for the exact mapping. They are not part of those three groups.
* APIYI labels the source in group names and documentation. Reverse groups are never presented as official direct connections.

> [!NOTE]
>
> These are typical patterns, not a claim that every official-relay channel beats every reverse channel. Official relay also runs into vendor capacity limits, and a high-quality reverse resource pool can be temporarily better on speed, concurrency, or stability for some workloads. Judge the specific channel, time window, and your own tests.

This article is about APIYI groups in general, not one specific model. For model-level differences, check the model documentation and run your own tests.

## Official-relay and reverse groups on APIYI

Separate the **group** from the **model**: the group is the channel on the token, and the model is the `model` field in the request. APIYI uses groups to organize sources and use cases, but a general group can contain both official-relay and reverse image models.

**APIYI is official-relay by default.** Groups that are mostly official relay include `Default`, `SVIP`, `ClaudeCode`, `Claude_Enterprise`, `CodexResponses`, `image2Enterprise`, and `NB-Enterprise`, plus the video groups `SeeDance2` and `Wan&HappyHorse`. See [Groups](https://docs.apiyi.com/en/groups.md) for the full list, discounts, and model coverage.

### Reverse groups (supplement)

| Reverse group | Coverage | Multiplier | Best for |
| - | - | - | - |
| `Claude_Reverse` | 24 Claude models, excluding newer releases such as `claude-fable-5-2` and `claude-haiku-5-5` | 0.5 | Personal learning, non-production |
| `Codex_Reverse` | 9 models including `gpt-5.6-*`, `gpt-6-*`, and `gpt-6.1-*` | 0.5 | Cost-sensitive Codex, non-production |
| `Gemini_Reverse` | 11 models from Gemini 2.5 to 3.8, excluding Gemini 4 | 0.5 | Gemini CLI, learning, non-production |

Reverse groups are a supplement and do not promise the same SLA, concurrency, or feature completeness as official relay.

> [!NOTE]
>
> `Default` / `SVIP` are mostly official relay, but they also contain reverse image models such as `gpt-image-2-all`, `gpt-image-2.6-all`, and the `-vip` series. Check both the group and the model, not just the group name.

## Core differences: it is not only model intelligence

### Stability and performance

| Dimension | Official relay | Reverse | Business impact |
| - | - | - | - |
| Model behavior | Native, consistent | Mostly close, with occasional differences | Single-turn answers usually differ little |
| Model authenticity | Verifiable source | Depends on supplier transparency | Validate with a fixed test set |
| First token | Lower and predictable | May add a proxy or queue | Affects real-time and streaming UX |
| Overall speed | Affected by official load | Varies with the resource pool | Leave retry and timeout headroom for batches |
| Concurrency and peaks | Explicit RPM / TPM or quota | Depends on the account pool and scheduling | More likely to hit 429 or queuing at peaks |
| Caching | Full official cache mechanism | Cache control parameters may not pass through | Long conversations and fixed prefixes cost more |

### Protocol and features

| Dimension | Official relay | Reverse | Business impact |
| - | - | - | - |
| Parameter compatibility | Full official parameters and structures | Some parameters may be incompatible or ignored | Run regression tests for complex calls |
| Streaming | Native and standardized | Usually supported, with possible buffering or format differences | Tune first-token UX and client timeouts |
| Tool Calling / MCP | Native and reliable | Higher chance of structure or ordering issues | Agent task success rate drops |
| Structured JSON | Schema guaranteed by the official capability | Schema may not be strictly enforced | Downstream parsing needs tolerance |
| Multimodal | Full official support | Image, audio, or video may be missing | Validate multimodal workloads with small traffic |
| Context length | Official limit with clear constraints | May be limited by the reverse chain | Stress-test long documents and conversations |
| Thinking / reasoning control | Official reasoning parameters and response format | May not be fully reproducible | Reasoning budgets and chain handling are affected |
| Usage and error codes | Official metering and clear error types | May be estimated or mapped incorrectly | Billing reconciliation and retries need tolerance |

### Versions, compliance, and sustainability

| Dimension | Official relay | Reverse | Business impact |
| - | - | - | - |
| Model version updates | Follows the official lifecycle | May lag or change without notice | Keep a rollback plan for pinned versions |
| SLA and troubleshooting | Official support channels | Depends on the reverse supplier's support | Enterprises should focus on guarantees |
| Resources and risk control | Relatively controlled when used compliantly | Upstream account pools, risk control, and interface changes | Keep a backup channel for critical workloads |
| Commercial compliance | Covered by the vendor's commercial API terms | Outside the vendor's official API terms | Assess compliance before enterprise production |
| Price and long-term cost | Transparent; procurement discounts possible | May be cheaper, with higher hidden operations cost | Calculate total cost, not just unit price |
| Long-term sustainability | Relatively stronger | Depends on the availability of unofficial links | Prefer official relay for long-lived projects |

> [!NOTE]
>
> Reverse resources are outside the vendor's official commercial API terms. This article is a technical explanation, not legal advice. Assess compliance for your own enterprise procurement and production use.

## Why Agents should still prefer official relay when single-turn quality is close

A coding Agent's success rate is not determined by single-turn answers. One malformed tool-call argument, one missing JSON field, or one interrupted stream can fail and restart an entire task. Single-turn quality can look identical while multi-turn success rates diverge.

Three problems are amplified in Agent workloads:

* **Tool-call structure**: Reverse chains may rewrite or ignore parameters, increasing the chance of wrong function names, argument order, or nesting.
* **Cache prefixes**: System prompts, tool definitions, and history form a long prefix across turns. If the reverse chain cannot pass `cache_control` through, cache hits drop and both cost and latency rise.
* **Error codes and retries**: Inaccurate error mapping can make retry logic treat a recoverable error as fatal, or the other way around.

> [!TIP]
>
> For Claude Code, Codex, Gemini CLI, and OpenClaw workflows, prefer official relay by default. Use reverse groups only as a cost supplement or for non-critical tasks.

## When to prefer official relay, and when reverse is acceptable

| Scenario | Recommendation | Why |
| - | - | - |
| Coding Agents (Claude Code / Codex / Gemini CLI) | Prefer official relay | Tool calls and multi-turn tasks demand protocol consistency |
| Long context and complex multi-turn chat | Prefer official relay | Cache prefixes and context pass-through are more complete |
| Simple chat, translation, summarization | Reverse is acceptable | Single-turn quality is close and cost is lower |
| Tool Calling / MCP workflows | Prefer official relay | Parameter structures, ordering, and error codes are more reliable |
| High-concurrency batch generation | Prefer official relay; stress-test reverse | Concurrency depends on official quota or the reverse resource pool |
| Image generation | Official relay / enterprise groups; test mature reverse options | Output format, success rate, and 4K stability vary widely |
| Enterprise production | Official relay | Compliance, SLA, and troubleshooting are more complete |
| Extremely price-sensitive | Compare total cost first | Retries, failed work, and operations cost must be included |

## Caching is more than a hit rate

Official Claude caching has explicit prefix matching, `cache_control` markers, and 5-minute / 1-hour TTLs. The `cache_creation_input_tokens` and `cache_read_input_tokens` fields show writes and reads directly. OpenAI uses automatic prefix caching; Gemini uses implicit caching with a moderate hit rate.

If a reverse chain only forwards requests and cannot fully pass cache-control parameters, hit rates drop. Long conversations, fixed system prompts, and large tool definitions amplify the cost difference. When choosing a channel, do not only ask whether caching exists; measure the actual cache-read share for the same prefix.

See [Does APIYI support cache billing?](https://docs.apiyi.com/en/faq/cache-billing.md) for cache mechanics and billing, and [Claude prompt caching](https://docs.apiyi.com/en/api-capabilities/claude-prompt-caching.md) for Claude parameters.

## How to evaluate a channel: five metrics

If you need to choose between official relay and reverse, run a fixed test set and record these five numbers:

| Metric | How to calculate | Watch out for |
| - | - | - |
| Request success rate | Successful requests ÷ (total requests − client-side 4xx) | Exclude your own parameter errors |
| Effective cache hit rate | Cache-read tokens ÷ input tokens | Same model, same prefix, same group |
| P95 latency | Measure first-token and total duration separately | Do not rely on averages |
| Agent task completion rate | Share of fixed tasks that are finally delivered | Closer to real usage than single-turn quality |
| Cost per successful task | (Request cost + retry cost + failed work) ÷ successful tasks | Include failures |

Cache fields differ by vendor: Claude exposes `cache_read_input_tokens`, while OpenAI uses fields such as `prompt_tokens_details.cached_tokens`. Read the field from the actual response.

> [!TIP]
>
> Single-turn benchmarks only show whether the model can answer. These five metrics show whether the channel can run a business.

## APIYI channel principles

* **Official relay by default**: APIYI uses vendor official APIs and official cloud marketplaces by default. Reverse is a cost supplement, not the default channel.
* **Label the source**: `Claude_Reverse`, `Codex_Reverse`, and `Gemini_Reverse` are marked as reverse in group names and documentation. They are never described as official direct connections.
* **Production prefers official relay**: `Default`, `SVIP`, `Claude_Enterprise`, `CodexResponses`, `image2Enterprise`, and `NB-Enterprise` carry production traffic. For image models, choose by the specific model's source.
* **Official relay for complex Agents**: Tool calls, multi-turn tasks, and long context demand protocol consistency.
* **Reverse for learning and cost optimization**: Reverse groups do not promise the same SLA, concurrency, or feature completeness as official relay.
* **Enterprise customers**: Use `Claude_Enterprise`, `image2Enterprise`, or `NB-Enterprise` when guarantees matter. Contact support for SLA and procurement options.
* **Channels change**: Upstream resources, model versions, and group multipliers can change. Trust the console and [Live Updates](https://docs.apiyi.com/en/live.md).

If you only look at single-turn answers, official relay and a good reverse channel can look very close. What official relay is really worth is **behavioral consistency, predictable stability, complete features, and long-term sustainability**. For production businesses, those four determine support cost and customer retention, not just unit price.

## Related docs

> [card] [Groups](https://docs.apiyi.com/en/groups.md)
>
> All groups, multipliers, discounts, and selection guidance by vendor and model

> [card] [Tokens & Groups](https://docs.apiyi.com/en/faq/token-and-groups.md)
>
> Create tokens and configure primary and fallback groups

> [card] [What Is a Group?](https://docs.apiyi.com/en/faq/groups-explained.md)
>
> User groups vs token groups

> [card] [Cache Billing](https://docs.apiyi.com/en/faq/cache-billing.md)
>
> Cache behavior and billing for Claude, OpenAI, and Gemini

> [card] [GPT Image: Official vs Reverse](https://docs.apiyi.com/en/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md)
>
> Parameter, price, and quality differences for image models

> [card] [Model Pricing](https://docs.apiyi.com/en/models/index.md)
>
> Prices and specifications for every model


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.