|
Some checks failed
* Support Open WebUI 0.12.0 servers without the version warning The vendored Open WebUI source now points at the v0.12.0 release, and the newest server version Conduit accepts without a compatibility warning rises from 0.11.4 to 0.12.0. Servers newer than 0.12.0 still see the warning, and 0.11 servers stay supported. * Keep skill instructions when exporting and importing skills from Open WebUI 0.12 Open WebUI 0.12 exports each skill as a package of files, with the instructions in its root SKILL.md, and no longer sends the top-level content field. Conduit read only that field, so exported skills came out with empty instructions, and importing a file exported by 0.12 created empty skills. Skills now take their instructions from the SKILL.md file when the server sends files, as 0.12's own import does, and fall back to content for 0.11. The export file carries both content and the package files, so 0.11 and 0.12 servers can each import it, and importing a 0.12 package passes its files on so a 0.12 server keeps any supporting files. * Offer folder sharing only to the folder's owner or an admin Open WebUI 0.12 lets only a folder's owner or an admin change who it is shared with; someone the folder was shared with for editing now gets a 403. Conduit still offered Share folder to them, so it failed when used. The folder menu now offers Share folder for your own folders, and for folders shared with you only when you are an admin, as Open WebUI's web client does. Project settings stays with anyone who can edit the folder. * Say why sign-in stops when Open WebUI asks for two-step verification With two-step verification on, Open WebUI 0.12 answers a password or LDAP sign-in with the next step to take (enroll, verify or recover) instead of a session, and answers an account still awaiting approval with a pending step. Conduit looked only for a session token, so sign-in failed with a generic message, and signing in again with the saved password on launch kept the credentials and tried again on every start, each attempt counting toward the account's sign-in limit. Sign-in now recognizes these answers. The sign-in page says the account uses two-step verification, which Conduit does not support yet, and suggests signing in with SSO, which goes through Open WebUI's own sign-in page where the step can be finished, or with a session token from Open WebUI on the web. An account awaiting approval is told so. Signing in again with saved credentials treats either answer as final: it clears the credentials it tried and lands on the sign-in page with the reason, without retrying. Servers without two-step verification answer as before, so pending accounts there behave as they did. * Keep new chats temporary when the server requires temporary chats Open WebUI 0.12 refuses to create a chat for a non-admin whose permissions turn on both temporary chats and enforced temporary chats. Conduit did not read that permission, so a new chat queued its creation, the server refused it, and the message waited behind it without being sent or showing an error. Conduit now reads the permission the way Open WebUI's web client does. While it is enforced, every new chat starts temporary, a chat not yet saved becomes temporary as soon as the permissions arrive after sign-in, and the temporary chat toggle and Save chat action are hidden. Chats that already exist on the server go on as before, and admins are unaffected. * Show the error Open WebUI 0.12 saved when a reply fails without a socket When Conduit sends a message without a live socket, Open WebUI 0.11 answered a failed reply with a JSON null and saved the error on the message, and Conduit then read the saved reply. Open WebUI 0.12 answers the same failure with the provider's error status, or a 400, while still saving the error. Conduit treated that as a failed send, so the saved error never showed, and a queued send retried, only to be refused with 409 "Message already exists or has an invalid ID." because the reply had already run. When a completion for a saved chat fails, Conduit now checks the chat on the server. If the reply is already there, finished, with an error or with content, it reads that reply the way it already does after a JSON null, so the saved error or answer shows and a retry stops instead of repeating. A failure the server saved nothing for, such as an unknown model, still fails the send with its reason, as before. * Keep the session when a model's provider rejects a message with 401 or 403 A message that failed with any error mentioning 401 or 403 reloaded the sign-in state. Open WebUI 0.12 passes a provider's own status through, so a bad upstream API key on one model reloaded the user's session over a problem that had nothing to do with it. The failure now only marks the reply with its error. The auth interceptor already decides when the session has ended, from the session endpoint, as it does for every other request. * Show which tool is asking for approval in chats that are not saved With tool approval set to ask, Open WebUI 0.12 asks to approve a tool call in a chat that is not saved through a socket confirmation that carries only the call: its id, name and arguments. Conduit showed a confirmation's title and message, which this request does not have, so the approval appeared blank. A confirmation for a tool call now shows the tool's name over its arguments, formatted the same way as an approval in a saved chat. Approving or declining still answers true or false, as the server expects. * Answer Open WebUI's terminal and MCP requests so replies are not held up Open WebUI 0.12 asks the client for a terminal's AGENTS.md through request:terminal and waits up to 5 seconds, and asks it to fill in an MCP server's elicitation through request:elicitation, waiting up to 240 seconds. It also checks whether a user terminal is open through request:terminal:state, waiting 2 seconds. Conduit answered none of them, so each turn that triggered one sat until the server gave up. Conduit now answers at once: no terminal data, no user terminal open, and a cancelled elicitation, which the server treats as the user declining so the tool goes on. The request:interaction:done note that follows such a request is ignored. * Sign in to Open WebUI accounts that use two-step verification Open WebUI 0.12 can require two-step verification with an authenticator app. A password or LDAP sign-in then answers with the step to take instead of a session, and Conduit could only say it did not support it. The sign-in page now takes that step itself, the way Open WebUI's web client does: - An account with an authenticator asks for its six-digit code, or for one of its recovery codes instead. - An account signing in for the first time since two-step verification became required adds an authenticator. Conduit shows the setup key to copy, the server's QR code for an authenticator on another device, and a button that hands the key to an authenticator app on this device. Once a code confirms it, the account's new recovery codes are shown, with a way to copy them, before signing in, as the server never shows them again. - An account whose authenticator an administrator reset takes the recovery token they gave, then adds a new authenticator. A wrong code, an expired step and too many attempts each get their own message, and Back returns to the sign-in form. Once the step succeeds, the session is signed in to and remembered as the password or LDAP sign-in would have been. Signing in again in the background with a saved password still cannot answer a second step, so it stops as before and the sign-in page now asks the user to sign in again and enter their code. Changing the authenticator or making new recovery codes from Settings stays on the web for now. * Wait for a running reply to finish before showing it after a refused retry When a queued send was retried while the reply it had already started was still running, Open WebUI 0.12 refused the retry with 409, and Conduit read the saved reply once and closed it as finished. The user was left with part of an answer marked complete. Conduit now reads a saved reply in place of a refused request only once the server has finished it, with its answer or its error. While it is still running, the retry fails as before and tries again later, by when the reply has finished. * Check the session when Open WebUI refuses a message with 401 or 403 Open WebUI refuses a message with 401 or 403 both when the session has ended and when a model's provider rejects its own API key, which 0.12 passes through. Since a refused message stopped reloading the sign-in state, an ended session went unnoticed by a send. A message refused with 401 or 403 now asks the session endpoint once. The auth interceptor reports a refusal there as the session ending, as it does for every other session check, while a provider's refusal only marks the reply with its error. * Let the two-step sign-in reach the server before there is a session Conduit's API client refuses, without sending it, any request to an endpoint that needs a session while it has none. The two-step sign-in routes were treated as such endpoints, so every code, setup and recovery token was refused locally, and the sign-in page said the code was wrong. The four routes the sign-in uses (verify, enroll/start, enroll/confirm and recover) are now public, like sign-in itself: they authenticate with the challenge token in their body, and are sent without a session token. * Ask to start again when a verified session is refused If the server refused the session a correct second-step code had issued, the sign-in page said the username or password was wrong. It now says the step has expired and to sign in again, and the step is kept so the sign-in can be tried once more. The Czech and Slovak text for an administrator's reset now says reset rather than restored, and the code field's listener is removed before the field is disposed. * Label a new authenticator with the account that signed in The account name given to an authenticator app while setting up two-step verification was read from the sign-in form once the server answered, so a field edited meanwhile could label it with another name. It is now taken when the sign-in is submitted. * Sign in with the details as they were submitted The sign-in page read the method, username and password again after waiting to save the server and to confirm leaving the active account, so a field changed during that wait could send different details from the ones checked, and label a new authenticator with a third. It now takes them once, when the form is submitted, and uses them throughout. |
||
|---|---|---|
| .github | ||
| android | ||
| assets | ||
| docs | ||
| hermes-src@939e45c91d | ||
| ios | ||
| lib | ||
| openwebui-src@15818d88fd | ||
| packages | ||
| pigeons | ||
| scripts | ||
| test | ||
| third_party | ||
| tool | ||
| .gitignore | ||
| .gitmodules | ||
| .metadata | ||
| analysis_options.yaml | ||
| cargokit_options.yaml | ||
| devtools_options.yaml | ||
| l10n.yaml | ||
| LICENSE | ||
| paseo.json | ||
| PRIVACY_POLICY.md | ||
| pubspec.lock | ||
| pubspec.yaml | ||
| README.md | ||
| THIRD_PARTY_NOTICES.md | ||
Conduit
A native mobile client for Open WebUI, your own model endpoints, and self-hosted agents.
Connect · Screenshots · Features · Getting Started · Privacy · Build from Source
Open WebUI is excellent on the desktop. On mobile it breaks down at the edges: authentication behind a reverse proxy, streaming that drops when the app backgrounds, getting a screenshot into a prompt, starting a chat from the home screen. Conduit is a real Flutter app built to close that gap, and as of 4.0 it works with or without an Open WebUI server at all.
Your chats live on your device first. Nothing routes through a backend the maintainer operates.
Ways to connect
On first launch Conduit asks how you want to connect. Pick one, add the others later, and skip any sign-in you don't need.
| Open WebUI | Your self-hosted server | Full feature set: chats, folders, notes, channels, workspace, tools, web search, image generation |
| Direct | OpenAI-compatible, Ollama, OpenRouter | Talk straight to a provider or a model on your own machine. No Open WebUI account required |
| Apple On-Device | Apple Intelligence | Run Apple's local model offline on eligible iOS 26 devices without an API key |
| Apple PCC | Apple Private Cloud Compute | Use Apple's private cloud model on eligible iOS 27 devices without an API key |
| Hermes | Your self-hosted agent | An agent that runs tools, asks before sensitive steps, and works on a schedule |
Direct connections cover OpenAI-compatible endpoints (Chat Completions or Responses), LM Studio, Azure-style API versions, native Ollama, and first-party OpenRouter. Bring an API key, or skip it for a local endpoint that doesn't want one. Direct connections you already configured in Open WebUI come along automatically. Keys and custom headers stay in platform secure storage.
Apple On-Device is an iOS-only Direct provider backed by Apple's local SystemLanguageModel. It requires iOS 26 and Apple Intelligence, works offline, and supports streaming, sampling controls, and JSON-schema responses with a 4K context window. Image input, reasoning controls, and tool calling are not available.
Apple Private Cloud Compute is an iOS-only Direct provider. It uses Apple's Foundation Models framework, streams responses through the same chat path as other Direct models, and requires iOS 27, Apple Intelligence availability, and Apple's managed PCC entitlement. It supports image input, reasoning levels, sampling and output limits, JSON-schema responses, live quota/context status, and an optional on-device fallback for PCC network failures. Tool calling is not enabled.
Hermes Agent connects to your own Hermes server. You watch its tools work live, approve sensitive steps before they run, and let scheduled agents run while you sleep. Conversations and schedules get their own tab, and Conduit only exposes the capabilities your server actually reports.
Screenshots
| Chat | Connect | Chats | Voice |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
What you get
Chat that survives mobile
Token-by-token streaming over WebSocket. The transcript holds its place while a response grows, pinned prompts stay put, and long conversations load without stalling the UI. Search across conversations, organize with folders, pin what matters, or start a temporary chat that leaves nothing behind.
Rendering that holds up on a phone
Native Flutter surfaces, not a web view wrapped in a shell:
- syntax-highlighted code blocks with copy and preview
- Mermaid diagrams rendered natively
- LaTeX and math
- expandable reasoning, tool-call, and code-execution sections
- inline citations, source cards, and follow-up suggestions
- Chart.js embeds
A real Workspace
Models, knowledge, prompts, tools, and skills as native screens with unified settings navigation. Sections you don't have permission for simply don't appear.
Everything else
| Area | What's included |
|---|---|
| Files and media | Uploads, re-attaching previously uploaded server files, multimodal prompts, clipboard image paste, audio attachments |
| Notes | Autosave, pinning, AI-generated titles, AI enhancement, audio recording, all available offline |
| Channels | Threads and reactions, when your server enables them |
| Voice | Voice input with on-device or server speech recognition, plus a full voice-call mode |
| Home screen | Widgets on iOS and Android for new chat, mic, camera, photos, and clipboard; app quick actions; iOS App Intents and Shortcuts |
| Sharing | Share-sheet ingestion from other apps straight into a prompt |
| Terminal | Interactive sessions over WebSocket with a file browser, shown only when your server exposes it |
| Personalization | Light, dark, and system themes; five accent palettes; adaptive Material and Cupertino UI; haptics |
| Languages | 14 locales: English, German, Spanish, French, Italian, Japanese, Korean, Dutch, Russian, Simplified and Traditional Chinese, Czech, Slovak, Polish |
Server-dependent features (channels, notes, web search, image generation, toggle filters, terminal) appear only when your deployment exposes them.
Built for self-hosted reality
Most mobile clients assume a plain login form. Real deployments rarely look like that.
- Every auth path Open WebUI offers: username and password, LDAP, manual JWT entry, SSO and OAuth providers.
- Reverse proxies actually work:
oauth2-proxy, Authelia, Authentik, Pangolin, and Cloudflare Tunnel, by capturing the right cookies and session state on-device. - Custom headers during setup for environments that require
X-API-Key,Authorization, or organization routing headers. - Credentials in Keychain or Keystore, never plain-text local storage.
- Tracks upstream: Conduit supports Open WebUI 0.11.
Getting started
Install from the App Store or Google Play, then pick how you want to connect.
Open WebUI
- Launch Conduit and choose Open WebUI.
- Enter your instance's base URL.
- Add any required custom headers.
- Sign in with username and password, LDAP, JWT, SSO, or proxy auth.
- Pick a model and start chatting.
Direct connection
- Launch Conduit and choose Direct connection.
- Add an OpenAI-compatible or Ollama profile with its base URL and any API key or custom headers.
- Test the connection, enable it, and select a discovered or manually entered model.
- Choose whether new direct chats use Open WebUI history when one is signed in, or stay only on this device. Existing chats keep their current location.
- Start chatting. No Open WebUI account required.
Apple On-Device
- On an eligible iOS 26 device, launch Conduit and choose Apple On-Device.
- Conduit checks Apple Intelligence and local-model availability. No API key or network connection is required.
- Start chatting. New Apple-only installations keep Direct history on the device unless you later enable Open WebUI history.
Apple Private Cloud Compute
- On an eligible iOS 27 device, launch Conduit and choose Apple Private Cloud Compute.
- Conduit checks Apple Intelligence and PCC availability. No API key is required.
- Start chatting. New PCC-only installations keep Direct history on the device unless you later enable Open WebUI history.
Hermes Agent
- Launch Conduit and choose Hermes Agent.
- Enter your Hermes server URL and
API_SERVER_KEY. - Optionally set a memory key to scope the agent's long-term memory to you. One is generated automatically on first chat if you leave it blank.
- Open the Hermes tab for conversations and scheduled agents.
Privacy
- Chats, notes, and drafts are stored on your device. Notes and drafts stay available without a connection.
- Credentials use platform secure storage: Keychain on iOS, Keystore on Android.
- No third-party analytics or advertising SDKs.
- Diagnostic logging is local and transient.
- No developer-operated backend relays your data. Traffic goes from your device to the server or provider you configured, and nowhere else.
- Signing out lets you choose what stays behind. Clearing everything clears on-device chats too, and fails safely rather than half-deleting.
Full details in PRIVACY_POLICY.md.
Build from source
See docs/BUILDING.md for requirements, submodules, codegen, verification, project layout, and troubleshooting.
git clone --recursive https://github.com/cogwheel0/conduit.git
cd conduit
flutter pub get
dart run build_runner build
flutter run -d ios # or: flutter run -d android
Clone recursively and run build_runner. The Mermaid renderer is a submodule,
and generated Dart files are git-ignored.
Contributing
Conduit is actively developed and feedback is welcome.
- Bugs → GitHub Issues
- Features, deployment notes, questions → GitHub Discussions
Unsolicited pull requests are not the primary contribution path right now. Open an issue or discussion first so changes line up with the roadmap.
Enterprise and white-label
For private distribution, internal deployment support, or a custom enterprise/white-label build, open a discussion or reach the maintainer at cogwheel@cogwheel.app.
Support
If Conduit is useful to you, you can support development through GitHub Sponsors or Buy Me a Coffee.
Acknowledgements
- Supported by the Vercel OSS Program.
- Tested with BrowserStack.
- Code review provided by
.
License
Released under the GPL-3.0 License.
Conduit is an independent client and is not affiliated with Open WebUI.



