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

# Chat Completions Compatibility

> Understand the Starfire AI OpenAI-compatible chat-completions surface, when to use it, and when to choose Starfire-native Responses instead.

# Chat completions compatibility

Starfire's Developer Platform is designed to support a familiar chat-completions compatibility surface for software already built around that request model.

## Resource

The Alpha v1 architecture includes:

```http theme={null}
POST /v1/chat/completions
```

Confirm the current request/response schema in the active OpenAPI or Developer Portal before production use.

## Use compatibility when

Choose the compatibility surface when your application already expects a message-array conversational contract and does not need Starfire-specific long-running resources.

Typical uses:

* chat UI integrations
* simple prompt/response services
* existing OpenAI-style client abstractions

## Choose Starfire-native Responses when

Use `/v1/responses` for capabilities that need Starfire-specific reasoning, tools, project context, or richer response/run behavior that does not map cleanly to compatibility fields.

## Model eligibility

The selected model must be visible to the credential and support the required input/tool behavior.

## Streaming

Where enabled by the active contract, streaming returns incremental output. The client must still handle interruption, cancellation, and final usage/error state.

## Compatibility is not identical infrastructure

A familiar request shape does not mean Starfire is merely proxying one provider. Starfire can apply its own identity, policy, model catalog, metering, routing, and observability layers.

<Warning>
  Do not depend on provider-specific undocumented fields that Starfire has not declared part of the compatibility contract.
</Warning>