# OpenAI and Ollama compatibility

> How an LMSP service stays compatible with existing OpenAI and Ollama clients through a thin data-conversion layer over one execution core, and where that compatibility ends.

Source: https://madeforagent.com/lmsp/1.0/compatibility/
Language: en
Specification: LMSP 1.0 (draft)
Updated: 2026-11-08

## 8.1 OpenAI-compatible endpoints {#openai}

A service **SHOULD** offer an OpenAI-compatible interface next to the LMSP interface, and declare it in `interfaces` with `kind` set to `openai`. To cover existing clients, a service that does so **MUST** implement at least these endpoints under the `/v1` prefix:

| Endpoint | Notes |
| --- | --- |
| `GET /v1/models` | Lists the models of the LMSP catalog. Each `id` is the LMSP model id. |
| `POST /v1/chat/completions` | Chat Completions, with and without streaming. |
| `POST /v1/responses` | The OpenAI Responses shape. |
| `POST /v1/embeddings` | The LMSP 1.0 core interface has no embeddings endpoint. The adapter serves this endpoint directly, for models whose `capabilities.embeddings` is `true`. |

These endpoints accept the same bearer tokens as the LMSP interface. A client that speaks the OpenAI protocol sets the LMSP token as its API key.

A first implementation can start with `/v1/models` and `/v1/chat/completions` ([page 12](https://madeforagent.com/lmsp/1.0/mvp.md)).

## 8.2 Ollama-compatible endpoints {#ollama}

A service **SHOULD** also provide these endpoints, so that clients written for Ollama work too:

| Endpoint | Notes |
| --- | --- |
| `GET /api/tags` | Lists the models of the LMSP catalog. |
| `POST /api/chat` | Chat. |
| `POST /api/generate` | Plain text generation. |

A service that provides them declares an interface with `kind` set to `ollama`.

## 8.3 One execution core {#core}

The compatibility layer **MUST** only convert data. It **MUST NOT** create a second set of model management logic. A request on a compatibility interface is mapped to an LMSP response, runs on the same core and adapter as a native request, and uses the same model catalog and authentication.

```text
OpenAI Chat Completions
          |  request mapping
          v
     LMSP Response
          |  backend adaptation
          v
llama.cpp / Ollama / vLLM / other runtimes
```

On the `/v1` and `/api` endpoints, a service **SHOULD** report errors in the format that the corresponding API defines, so unmodified clients can parse them. The LMSP interface always uses `application/problem+json`.

## 8.4 Boundaries {#boundaries}

Compatibility has limits, and they are worth stating plainly:

- An existing OpenAI-compatible client usually needs only a changed `base_url`. It does not gain LMSP discovery automatically.
- Only clients that support LMSP can discover a service automatically, read its detailed capabilities, resume event streams and manage asynchronous tasks.
- No server-side protocol can make a client work if it cannot be configured and accepts only official cloud addresses.