Protocol core

The Bricoop protocol is the contract an application and a provider both implement so Bricoop can route between them. The application sends a request in the protocol’s common shape; Bricoop adapts it to the selected provider, streams the response back, and reports any error in a normalized category the application can act on. The protocol never carries credentials in the request body and never buffers a full response when streaming.

Requests

An application sends a request that names the model slot, the capability it wants to use, and the message payload. Bricoop reads the request, resolves the selected provider and model, adapts the payload to the provider’s API, and forwards it. The application never talks to the provider directly; the local connection layer is the only path.

Responses

Bricoop normalizes the provider’s response to a common shape the application expects, whether the provider returns a chat completion, a tool call, or an image. The application reads the normalized response and renders it; it never has to understand the provider’s native format. This normalization is what lets every supported application work with every supported provider.

Streaming

Token and stream events pass through Bricoop with no buffering of the full response. Bricoop adapts each chunk to the protocol’s streaming shape and forwards it immediately, so the application can render tokens as they arrive. The connection layer adds latency measured in microseconds, not seconds, because it never waits for the full response.

Errors

Errors are normalized into explicit categories: invalid credentials, rate limit, unsupported capability, and provider unreachable. Each category carries the provider and model that produced it so the application can show a precise message. Bricoop never silently degrades an error into a generic failure; an unsupported request is reported as unsupported, not as an empty response.

Versioning

The protocol is versioned with schema_version and minimal_client_version. A client below the minimum is rejected explicitly at handshake, with the required version named, so the user knows to upgrade. A provider or application that targets a newer schema than the running client is also rejected, preventing a half-working combination from ever forming.