Skip to content
Docs

Anthropic-Compatible API

Lifeboat implements the Anthropic message protocol, so clients and coding agents that speak it work against a private model with a base-URL change.

Endpoint Notes
POST /v1/messages The main endpoint. Streaming supported.
POST /v1/messages/count_tokens Token counting before sending.

Both are routed by the same load balancer as everything else, with the same headers and the same capacity behaviour.

The Anthropic schema carries the system prompt as a top-level field, not as a message with a system role — a system-role entry is invalid there.

So Lifeboat merges a configured system prompt into that top-level field rather than into the message list. Without that branch, an operator’s configured prompt would apply on the OpenAI endpoint and silently vanish here.

This protocol is block-structured: a tool call is a block that opens, receives its input as fragments, and closes. That makes it stricter than the OpenAI shape, where clients accumulate arguments by index and tolerate ordering slack.

The practical consequence, and what to check if tool calls fail on this endpoint but not the other: a fragment arriving out of order relative to the text around it can leave a tool block’s input incomplete, which a client reports as unparseable input or as a tool call with an empty name. Lifeboat holds text back rather than closing a tool block whose input is not yet complete, so the block that reaches the client is well-formed.

If you are seeing either symptom, check the server’s engine and Lifeboat version first — this class of problem is a protocol-level ordering issue, not a model quality issue, and the same model on the OpenAI endpoint will look fine.

Whether tool calls are produced at all depends on the server’s tool-call parser matching what the model emits. Lifeboat corrects that automatically at start when the model’s own chat template proves the format, and audits it. See Tool-call troubleshooting.