Skip to content

OpenAI Assistants API: using the VIDAI Control Plane as the backend

The Assistants API keeps state (assistants, threads, messages, runs) on the server side. The control plane's shipping surface covers the underlying model calls; the server-side state objects (creating assistants, threads, runs) are not proxied today.

If you rely on the Assistants API for its stateful model, the recommended path is to point your Assistants-API calls at OpenAI directly and use the control plane for your Chat Completions / Responses traffic — where the routing, cost tracking, guardrails, and chargeback we ship actually apply.

Alternatively, migrate the specific flow you built on Assistants API to the Responses API — the Responses API's previous_response_id covers most conversation-continuation patterns and is fully routed by the control plane. See OpenAI Responses API.

Where thin support DOES apply

Runs that boil down to a single /v1/chat/completions call under the hood behave normally. If your Assistants-shaped integration is really just "one prompt → one reply" wrapped in Assistants API scaffolding, migrating that call to the Chat Completions path via client.chat.completions.create(...) puts it fully under the control plane. See OpenAI SDK.

Attribution

Whatever routes to the control plane's Chat Completions endpoint counts on Request Logs and Chargeback. Calls that terminate on OpenAI's Assistants surface (thread create, run create, etc.) do not appear on our reports today.

If something's off

Raise an issue at github.com/vidaiUK/vidai-quickstart/issues describing the Assistants-API pattern you're trying to route. We're actively considering coverage for common Assistants sub-patterns and your use case helps us prioritise.

Where to go next