Drop-in compatible: matching the OpenAI transcription API on localhost
Point an existing OpenAI transcription client at the local server and OpenASR answers a focused subset of the same HTTP shape — three endpoints, six response formats, offline by default, and explicit about what it does not implement.
Most transcription code is already written against one HTTP shape: a multipart upload, a model field, a response_format, and JSON back. The cloud hop is the only part you actually want to move. OpenASR’s local server answers that same shape on loopback, so the change is a base URL rather than a rewrite — with one honest qualification carried throughout: it mirrors a focused subset of the OpenAI transcription API, never the whole thing.
Three endpoints on loopback
openasr serve brings up a default-loopback HTTP server, and three of its routes mirror the OpenAI transcription HTTP shape: GET /health for liveness, GET /v1/models to list the locally available model ids, and POST /v1/audio/transcriptions for the work itself.
$ openasr serve --addr 127.0.0.1:8080
# OpenAI-compatible transcription subset on loopbackThe transcription endpoint accepts the multipart fields a familiar client already sends and returns one of six response formats — json, text, srt, vtt, verbose_json, and markdown — which covers both programmatic callers and subtitle workflows from the same route. The subtitle side asks for srt or vtt and gets a caption file directly, out of the same call that produced the transcript.
$ curl -s http://127.0.0.1:8080/v1/audio/transcriptions -F file=@fixtures/sample.wav -F model=whisper-small -F response_format=json”Compatible” means a subset, on purpose
To set expectations precisely: this is not full OpenAI compatibility. The FAQ states it plainly — OpenASR implements a focused local transcription subset plus local realtime routes, not the entire API surface. Routes, parameters, and behaviors outside that slice are simply not present, and the docs say so rather than failing in surprising ways.
Not the full API
OpenASR answers /v1/audio/transcriptions, /v1/models, and /health — not the broader OpenAI API. Treat it as drop-in for transcription, and check the docs before assuming any other route exists.
Nothing leaves, nothing arrives on its own
There is no hosted inference service in this path. Normal flows are offline by default, and there is no model/runtime auto-download surface — the FAQ is explicit that there are no automatic model downloads during CLI, API, or default tests. Models arrive only when you ask: openasr pull resolves a catalog entry and installs an .oasr pack through the shared core pull engine — the same engine reachable from the daemon’s POST /v1/models/{id}/pull and the desktop build’s Models page.
You switch a base URL, not your client — and nothing is fetched, sent, or installed that you didn’t ask for.
on the localhost transcription subset
Know the lane
The active lane is deliberately conservative: offline and final-only, no beam search, and no multilingual product guarantees. So a client pointed here gets a faithful subset of the request/response shape, but you should not read OpenAI’s full feature set — or any multilingual quality promise — into the word “compatible.” It is drop-in for what it implements, and explicit about the rest.
The point of the subset is small: keep the integration surface familiar, keep the audio and the model on the machine that runs openasr serve, and don’t pretend to be more than that. Switch the base URL, keep your client, and read the docs for the edges.