Your Own Assistants API, Auto-Generated from OpenAI's Spec

What it does

OpenOpenAI replicates the stateful slice of OpenAI’s Assistants API—assistants, threads, messages, runs, and file attachments—on your own hardware. It stores state in Postgres, queues background run processing in Redis via BullMQ, and serves a REST API through Hono. The routes and TypeScript types are generated automatically from OpenAI’s official OpenAPI specification, so the official Node.js and Python clients work out of the box once you point them at your server.

The interesting bit

Compatibility is treated as a code-generation problem rather than a maintenance burden: because the types and routes are scraped directly from OpenAI’s spec, staying current is meant to be mechanical. The architecture also cleanly separates the stateless HTTP API from the async task runner, letting you scale run execution independently from request handling.

Key highlights

• Wire-compatible with the official Assistants API; existing SDKs need only a new baseURL
• Auto-generated routes and types from OpenAI’s OpenAPI spec reduce manual drift
• Supports custom models, custom retrieval logic, and sandboxed testing of GPT-like assistants
• Horizontally scalable: stateless API server plus async runner backed by Redis
• S3-compatible storage for file attachments

Caveats

• The built-in code_interpreter tool is not yet implemented
• Retrieval currently supports only plain text and markdown, returning full file contents rather than semantic chunks
• Underlying chat completions still require an OpenAI API key; local model support is described as straightforward to add but not yet present

Verdict

Teams that need on-premise assistants, pluggable retrieval, or a staging environment for GPT actions will find this useful. If you are happy with OpenAI’s managed service and don’t need custom infrastructure, skip it.