Allow self-hosted / custom STT endpoint instead of hardcoded OpenAI / ChatGPT

[L0GYKAL]

Summary

Allow configuring a custom Speech-to-Text endpoint (URL + model + auth header) so users can route voice transcription to a self-hosted Whisper / Faster-Whisper / whisper.cpp server instead of OpenAI / ChatGPT.

Motivation

Voice transcription is currently hardcoded to OpenAI / ChatGPT endpoints:

• apps/ios/Sources/Litter/Models/VoiceTranscriptionManager.swift — https://chatgpt.com/backend-api/transcribe and https://api.openai.com/v1/audio/transcriptions.
• apps/android/app/src/main/java/com/litter/android/state/VoiceTranscriptionManager.kt — same two endpoints, model field gpt-4o-mini-transcribe.

For users who:

• Run their own Whisper/whisper.cpp/Faster-Whisper server on their LAN or VPN,
• Are subject to data-residency / privacy constraints,
• Don't want voice audio leaving their network,
• Or already pay for a different STT vendor (Deepgram, AssemblyAI, etc. with OpenAI-compatible endpoints),

…there is no way to redirect transcription without forking the apps.

Concrete ask

Per-server (or global) STT config with at least:

• stt.endpoint — full URL of the transcription endpoint.
• stt.model — model field sent in the multipart form (default gpt-4o-mini-transcribe for OpenAI-compat servers, configurable).
• stt.auth_header — optional, e.g. Authorization: Bearer <token> for self-hosted servers behind an auth proxy. Empty/None for open LAN deployments.
• (Optional) stt.disabled for users who want to suppress voice transcription entirely.

When set, the existing transcribe(wav:authMethod:token:) path uses these instead of the hardcoded ChatGPT/OpenAI URLs. The OpenAI multipart contract (form fields file, model, plus standard transcription params) is the same as what whisper.cpp's server example and many self-hosted Whisper wrappers already implement, so for OpenAI-compatible servers no protocol change is needed — only URL/model/auth.

For genuinely non-OpenAI-shaped APIs (e.g. raw whisper.cpp), a small adapter layer per provider could come later; the immediate win is OpenAI-compatible endpoint redirection.

Why this is worth solving in Litter

• Two files, one branch each in VoiceTranscriptionManager.{swift,kt}.
• No new mental model — same multipart contract.
• Unblocks privacy-sensitive and air-gapped self-hosters who run Codex on a bastion already (see also Support SSH ProxyJump / bastion routing for remote Codex servers #123).

Alternatives considered

• MITM proxy on the network rewriting chatgpt.com/api.openai.com to a local server — fragile, needs a custom CA on the device, breaks the moment Litter pins certs.
• Fork the apps — defeats the point of using the upstream client.

Happy to test on iOS/Android beta channels once landed.

[L0GYKAL]

Reading CONTRIBUTING.md and AGENTS.md after filing this — happy to take a shot at it if you're open to the feature, but I want to align on shape before writing code so it doesn't bounce on a parity / "Prefer Rust first" violation.

My read of the conventions is that STT endpoint config is exactly the kind of thing that belongs in shared/rust-bridge/codex-mobile-client/ (per-server config field, UniFFI-exposed enum/record), with iOS VoiceTranscriptionManager.swift and Android VoiceTranscriptionManager.kt reading it through the generated bridges rather than each holding their own copy. The auth-token storage stays platform-side (Keychain / EncryptedSharedPreferences) but the shape of the config and the choice of "use ChatGPT vs OpenAI vs custom endpoint" lives in Rust.

Roughly:

1. Extend the per-server config record in codex-mobile-client with something like

   enum SttBackend {
     ChatGpt,                       // current default
     OpenAiApi,                     // current OpenAI path
     Custom { endpoint, model, auth_header_name },
   }
   

   auth_header_value referenced by name, stored in platform secret store.
2. Regenerate UniFFI bindings.
3. iOS VoiceTranscriptionManager.transcribe(...) and Android equivalent switch on the Rust-owned enum instead of the current isChatGPT boolean.
4. Settings UI on both platforms gets a small "Transcription" section per server.

Two questions before I start:

1. Is the feature itself in scope? I don't want to scaffold this if you've already decided self-hosted STT is out (e.g., for support-burden reasons).
2. Is the Rust-first shape above what you'd want, or do you have a different layering in mind? Specifically: should the backend choice be a Rust enum, a free-form URL string in Rust, or pushed entirely to platform settings with Rust just plumbing bytes?

Either way, I won't open a PR until you weigh in — per CONTRIBUTING.md "Open an issue first if you're proposing anything non-trivial."

[dnakov]

Reviewed current main. This is not implemented yet: iOS and Android still hardcode the ChatGPT/OpenAI transcription endpoints in their platform VoiceTranscriptionManager files. The proposed Rust-first shape is the right direction for parity: shared Rust owns the backend/config record, Swift/Kotlin only read the selected config and perform platform audio/token handling. Leaving this open pending product scope; I did not open a PR because this needs the endpoint/auth storage contract decided first.