Both interfaces can reach LingCoreX through one platform, but they do not expose the same request shape, error semantics, or caching controls. This page focuses on what changes operationally.
These are the differences that most often affect tooling, observability, and production behavior.
| Topic | OpenAI-compatible | Anthropic-native |
|---|---|---|
| Primary endpoint | /v1/chat/completions or /v1/responses | /v1/messages |
| Authentication | Authorization: Bearer | x-api-key header |
| Messages shape | OpenAI-style role/content JSON | Anthropic-native messages payload |
| Tool behavior | Depends on what the tool exposes through OpenAI format | Closer to Anthropic-native semantics |
| Explicit cache controls | Not exposed in the request shape | Can preserve Anthropic-native cache behavior when supported |
| Error interpretation | Often OpenAI-style semantics | Closer to Anthropic-native semantics |
A request can succeed through both interfaces while still behaving differently at the edges.
OpenAI-compatible access is usually the easiest path for broad tooling support. It is the better default when your editor, CLI agent, or SDK already expects OpenAI-style chat completions or responses calls.
Anthropic-native access becomes more important when you want request behavior that depends on the native shape itself, especially explicit cache-related behavior and Anthropic-native client expectations.
This is why 'the request works' is not the same as 'the request preserves every native behavior.' The format still shapes what the client can express.
Pick the interface based on the caller, not on marketing labels around the model family.
Your SDK, editor, or CLI agent already works best with OpenAI-style routes.
You need the request semantics that belong to the Anthropic-native path itself.