Choose remote model UIs by their API contracts

Summary

For a CPU-only Linux frontend that calls a separate inference server, Open WebUI offered the broadest source-verified LLM sampling controls and a practical ordinary text-to-speech baseline. Big-AGI was the lighter alternative for browser-stored conversations and multi-model comparison. Speakr lite was the strongest conditional speech-to-text choice, but application login, timestamp availability, and subtitle filenames remained important limitations. These are October 2026 source-based recommendations, not tested deployments. [1–8]

No reviewed product established a complete browser reference-upload voice-cloning flow against the inspected mlx-audio API. No purpose-built music UI was verified as a drop-in match for the inspected MiniMax-Music3 backend. Reusing Open WebUI's TTS transport for music was a plausible but untested inference from its configurable request body. [2, 9, 10]

Method and collection date

The underlying survey inspected public documentation, repository source, release metadata, container manifests, and issue activity on 21 October 2026. Its deployment scenario is generalized here to a CPU-only linux/amd64 frontend and a separate Apple Silicon inference backend. No product was installed, started, signed into, or deployed; no end-to-end requests were tested.

This report distinguishes documented controls, inspected request construction, and runtime compatibility. An advertised OpenAI-compatible endpoint does not establish support for every sampling parameter, model-discovery convention, upload flow, or streaming format. Container manifests establish advertised architectures, not successful startup. Default-branch findings can differ from released images. All feature, release, licensing, and maintenance statements below describe the October 2026 snapshot, not a current-product guarantee.

Public citation URLs were rechecked on 2 November 2026 using scripted HTTP HEAD requests, falling back to GET on errors, with redirects, a browser User-Agent, a 15-second request timeout, and pacing of about one request per second per host. References 5, 45, and 63 returned HTTP 429 and are not machine-verifiable. Registry references 53–55 returned HTTP 401 and are likewise not machine-verifiable without authentication; their architecture statements remain historical observations from the original survey. The other retained references returned HTTP 200. Reachability does not revalidate page content or product behavior.

Findings

1. Speech generation: remote TTS is not the same as reference-upload cloning

UI	Remote address and authentication	Ordinary TTS finding, October 2026	Reference-upload cloning finding	Evidence
Open WebUI	Base ending `/v1`; outgoing Bearer key	Practical baseline with configurable model, voice, and extra JSON	No verified upload flow; a reference path must already exist on the inference server	[1, 2]
SillyTavern	Complete `/v1/audio/speech` URL; stored outgoing key	Useful fallback with free-text model and voice settings	Inspected proxy sends standard speech fields, not reference uploads	[11, 12]
mlx-audio UI	Configurable browser base and port; no outgoing key setting found in inspected page	Separable frontend, but fixed model/voice assumptions	Backend accepts cloning fields; inspected UI does not send them	[9, 13, 14]
Speaches UI	Remote origin without `/v1`; UI key forwarded as Bearer	Genuine remote mode, but model/voice discovery differs from mlx-audio	No reference-upload TTS flow found	[15–17]
Kokoro-FastAPI UI	Same-origin API; arbitrary remote base/key not established	Does not meet the generic remote-backend requirement as supplied	Reference-based tuning is documented as distinct from reproducing a voice	[18–20]

mlx-audio's cloning request refers to a server file. At the inspected revision, SpeechRequest requires model and input and accepts optional string fields ref_audio and ref_text. The handler tests whether ref_audio exists on the inference server and loads that path. A missing path returns HTTP 400. This is not a browser File, uploaded byte stream, URL, or base64 contract. Placing an authorized recording on the inference server can enable an API call, but it does not create a browser upload-to-clone workflow. [9]

The mlx-audio frontend has Next.js standalone output. Its inspected TTS page combines NEXT_PUBLIC_API_BASE_URL and NEXT_PUBLIC_API_PORT, then appends /v1/audio/speech. Those frontend values do not establish runtime reconfiguration of an already-built image. The page sets JSON content type without an outgoing authorization setting and uses fixed model/voice choices. A separately hosted page is therefore not automatically a generic authenticated audio client. [13, 14]

For Open WebUI, the inspected settings are AUDIO_TTS_ENGINE=openai, AUDIO_TTS_OPENAI_API_BASE_URL, AUDIO_TTS_OPENAI_API_KEY, AUDIO_TTS_MODEL, and AUDIO_TTS_VOICE. The base ends /v1. AUDIO_TTS_OPENAI_PARAMS supplies extra JSON; release-pinned transport merges those extras into the speech request and posts to {base}/audio/speech. It can carry ref_audio and ref_text only when the reference file is already available to the backend. That makes it a flexible read-aloud interface, not a verified cloning workbench. [1, 2]

SillyTavern instead takes the full speech endpoint. Its inspected proxy sends model, input, voice, response_format: mp3, and speed, with a Bearer token in the Authorization header. This avoids a dependency on automatic voice discovery but does not add arbitrary cloning parameters. [11, 12]

Speaches has a real remote override through LOOPBACK_HOST_URL, an origin without /v1, with ENABLE_UI=true. The UI key is forwarded upstream; the server's API_KEY protects its own API and is a different setting. Its TTS tab expects model details at /v1/models/{model_id} containing data.voices[].name. The inspected mlx-audio backend instead exposes /v1/audio/voices?model=... and lacks that model-detail route. Remote connectivity alone does not resolve this schema mismatch. [9, 15–17]

Kokoro-FastAPI derives its API root from the page location and configuration, then calls same-origin speech endpoints. Its optional Inno Tuner accepts reference audio for English timbre, pitch, and rate steering; the documentation distinguishes this from voice reproduction. It should not be presented as mlx-audio voice cloning. [18–20]

2. Transcription: Speakr is conditional, not a complete match

Speakr lite was the strongest candidate for remote transcription, language selection, and usable text downloads. Configure TRANSCRIPTION_CONNECTOR=openai_whisper, TRANSCRIPTION_BASE_URL ending /v1, a nonempty TRANSCRIPTION_API_KEY, and the served model ID in TRANSCRIPTION_MODEL. ASR_BASE_URL belongs to another connector. Automatic model discovery filters for whisper, so non-Whisper model IDs require manual configuration. Arbitrary headers other than a Bearer token in the Authorization header were not established. [3, 21]

Its download route supports TXT/Markdown and templates. The SRT template depends on timed segments; plain text cannot manufacture timestamps. Even SRT-formatted template output is attached with a .txt or .md filename rather than a conventional .srt extension. Login/access checks remain on the inspected download and main application paths. Consequently, Speakr is not a verified anonymous, frictionless subtitle-export solution for every remote model. [4, 5, 22]

The other transcription candidates had distinct gaps:

Speaches UI: real remote origin/key support and audio upload/recording, but no language control or transcript-file download control was verified. Its streaming mode uses a Speaches-specific SSE contract; nonstreaming is the narrower initial interoperability target. [15, 23]
Scriberr: the inspected adapter accepts a key and language but posts to a literal OpenAI transcription URL. Its configurable LLM features do not establish a configurable STT upstream. TXT/SRT behavior was not source-verified in this survey. [24]
Whishper: documents upload, subtitle editing, and TXT/JSON/VTT/SRT output, but its host settings address its own API/model stack rather than an arbitrary OpenAI transcription backend. Its inspected v3 README said that branch would not receive further updates while a rewrite proceeded; the rewrite was not evaluated. [25, 26]
mlx-audio UI: inspected language mapping and download controls were incomplete. The “Detect” choice sent English, other choices lowercased language names rather than mapping ISO codes, and detail-page export handlers were placeholders. Visible controls therefore did not establish working detection or downloads. [27, 28]

3. Music: matching an endpoint name is insufficient

The inspected MiniMax-Music3 server uses /v1/audio/speech, but its request is not ordinary TTS with added prompt, lyrics, and duration fields. It requires model, nonempty input for lyrics, and nonempty instructions for style. It accepts WAV output, an integer seed defaulting to 0, and max_new_tokens from 1 to 9000, defaulting to 1500. stream:true returns HTTP 400. [10]

Duration derives from max_new_tokens / active.model_config.frame_rate. At the README's stated 25 Hz, a 250-token/frame budget corresponds to about ten seconds, and generation can stop earlier. A compatible interface must expose that budget or translate duration using the loaded frame rate rather than send an unsupported duration field. [10, 29]

The surveyed music interfaces do not establish a ready-made match:

ACE-Step UI: ACESTEP_API_URL supports genuine separation from an ACE-Step 1.5 Gradio backend, with lyrics/style and generation controls. That protocol is not the MiniMax speech JSON contract. Remote upstream key/header support was not established. [30]
Original ACE-Step, YuE-UI, and MusicGPT: the inspected products run local inference. Serving their browser pages remotely does not relocate inference to an arbitrary backend. MusicGPT's code and model-weight licensing also differ: MIT code versus separately noncommercial MusicGen weights. [31–33]
A separate ACE-Step 1.5 studio: documents a configurable API base and task endpoints /release_task and /query_result. This is evidence that remote music interfaces exist, not evidence of MiniMax compatibility; lifecycle, container, and authentication metadata were not fully assessed. [34]
mlx-audio UI: no music page or required MiniMax instructions request was established. [13, 14]

Open WebUI TTS reuse remains an untested option. Its extras merge could supply static administrator-managed instructions, max_new_tokens, response_format: wav, and stream:false; normal TTS input would supply lyrics. This follows from the two source contracts, not a successful music request. It does not provide verified per-generation style/duration controls, long-running playback behavior, or response compatibility. A dedicated form or adapter is future engineering, not a product delivered by this survey. [1, 2, 10]

4. LLM playgrounds: inspect the transmitted fields

Candidate	System prompt and ordinary sampling controls	Generic remote `top_k`	Model discovery	Streaming/comparison and qualification	Evidence
Open WebUI	Temperature, top-p, and max output; provider rules still apply	Control documented; inspected payload preserves non-None extensions; backend must implement them	`{base}/models`; manual IDs available	Rendered streaming; broadest verified sampler path; dedicated Playground comparison not freshly established	[6, 35, 36]
Big-AGI	System/temperature/max output; model-dependent top-p replaces temperature	Not found in inspected common registry/standard adapter	LocalAI listing with capability/name heuristics	Rendered streaming and Beam comparison; lighter browser-storage choice	[7, 8, 37–39, 64]
llama.cpp llama-ui	Rich llama-server sampler settings	Supported as a llama-server parameter, not proof of generic operation	OpenAI plus llama-specific management endpoints	Static frontend possible, but coupled to llama-server; simultaneous comparison not established	[40–42]
LibreChat	OpenAI presets with temperature, topP, and maxTokens	Fixed `addParams.top_k` possible; editable generic control not proven	`models.fetch:true` on custom endpoints	Rendered streaming; account and MongoDB complexity	[43, 44]
LobeHub v2	Individual generic controls not fully traced	Unverified	`OPENAI_MODEL_LIST` exists; refresh path unverified	Current v2 requires server DB; old client-only advice does not apply	[45, 46]
NextChat	System/temperature/top-p; generic text `max_tokens` omitted in inspected code	Absent from inspected request construction	Disabled by default; enabled path filters `gpt-`/`chatgpt-`; manual IDs needed	Rendered streaming; lightweight but weaker arbitrary-model contract	[47, 48]
Hugging Face Chat UI	Detailed current controls not all verified	Legacy documentation does not establish current behavior	README documents `${OPENAI_BASE_URL}/models`	Rendered streaming; MongoDB-backed, including embedded default	[49, 50]
OpenPlayground	Historical parameter/logprob controls	Current support unverified	Current support unverified	Historical side-by-side reference; inspected history stopped in June 2023	[51, 52]

Open WebUI: use a base ending /v1, with explicit model IDs when discovery fails. Its inspected payload helpers preserve parameters beyond the named conversion map, so omission of top_k from that map does not mean it is dropped. Documentation describes an integer top-k control spanning 0–1000. This establishes a request path, not proof that a particular backend honors the parameter. [6, 35, 36]

Big-AGI: for a generic backend, the survey favored a LocalAI source configured with an origin without /v1. LOCALAI_API_HOST and LOCALAI_API_KEY are the corresponding server variables. Its LocalAI dialect keeps max_tokens, whereas its OpenAI dialect converts that field to max_completion_tokens. The standard adapter removes temperature when top-p is supplied, and no top-k forwarding was found in the inspected path. Browser storage and Beam can outweigh those sampler limitations for comparison-focused use. [7, 8, 37–39, 64]

llama-ui: a static build and browser conversation storage do not make it a generic OpenAI client. The inspected UI expects /props and several model, slot, tool, and stream-management routes in addition to chat completions. Its development proxy setting is not a demonstrated production runtime base-URL switch. A same-origin proxy to a real remote llama-server is a different proposition from pairing it with an arbitrary MLX endpoint. [40–42]

LibreChat: custom endpoints support a /v1 base, model discovery, headers, and fixed added parameters. Disabling email login or registration does not establish anonymous chat. LobeHub v2 removes historic client database mode and access-code settings; its migration and general startup guidance leave anonymous-mode support unresolved. NextChat illustrates why a visible max-token setting and model picker are insufficient evidence: generic text request construction and model-name filtering can still prevent the intended behavior. Chat UI likewise requires separating current README behavior from legacy provider examples. [43–50]

None of the reviewed products established a normal user-facing inspector for raw SSE events or raw response JSON. Displaying streamed tokens is a different capability. The bounded survey did not find a maintained minimal, no-database interface proven to meet every requested control; it does not establish that none exists. [6–8, 35–52]

5. Deployment state and licensing change the choice

The original October checks found linux/amd64 release-image support for Open WebUI v0.12.3 and Big-AGI v2.1.0, and a Speakr 0.10.15-alpha-lite image. The alpha designation matters. These checks did not establish startup, image/source parity, or compatibility with a particular inference service. [53–55]

Open WebUI uses SQLite by default and persistent backend data. Its documented WEBUI_AUTH=False mode is an initial single-user setup choice, not a supported later toggle between account modes. Big-AGI's basic mode stores conversations/files and settings in the browser without a server database; sharing/sync can add one. It lacks built-in authentication by default, and its documented HTTP Basic option requires a custom build. An external access layer does not automatically remove an application's own login. [56–59, 65]

Speakr lite excludes PyTorch but still persists uploads/transcriptions and retains login in the inspected application. LibreChat requires MongoDB; its default deployment includes additional services that should not all be called mandatory for bare chat. LobeHub v2 requires a server database. Chat UI's unset MONGODB_URL starts embedded MongoDB rather than a no-database mode. These distinctions are operational requirements, not measures of response quality. [22, 43, 46, 49, 60]

License labels must also remain precise. In the inspected snapshot, Open WebUI used a custom license with branding-retention conditions and stated exceptions; LobeHub used an Apache-derived community license with additional commercial-derivative conditions; MiniMax-Music3 used a custom community license with commercial-product attribution and separate authorization above the stated revenue threshold. Technical merit is separate from permission to redistribute or modify. This survey undertook no implementation or reuse and provides no legal opinion. [61–63]

Limitations

The comparison is a historical public-source assessment, not an installation guide or deployment acceptance result. No network path, credential, CORS policy, real model list, login experience, audio playback, subtitle download, or cloning workflow was exercised. Main/canary source can postdate a listed release; Open WebUI's TTS transport was separately inspected at its release tag. Registry tags and documentation can change. [2, 53–55]

The unresolved gaps are material: browser reference-upload cloning, conventional timestamped SRT export across remote models, a purpose-built MiniMax UI, raw-stream inspection, and several authentication/discovery contradictions. Open WebUI-to-MiniMax reuse is explicitly source-inferred and untested. Authentication configuration must not be mistaken for a secure exposure policy. No performance, quality, reliability, or security benchmark was conducted.

Choose remote model UIs by their API contracts

Summary

Method and collection date

Findings

1. Speech generation: remote TTS is not the same as reference-upload cloning

2. Transcription: Speakr is conditional, not a complete match

3. Music: matching an endpoint name is insufficient

4. LLM playgrounds: inspect the transmitted fields

5. Deployment state and licensing change the choice

Limitations

References

Related topics

Research lineage and next questions

How this record connects

Built from

Research that builds on this

Open research gaps

Archived public references

Challenge or extend this research