Most AI coding tools assume the model connection is theirs. You sign in to their service, their key is on their server, and the client is a window onto an account you do not control. I wanted the opposite arrangement: a client where the model connection belongs to the person running it.
Oliviacode is that client. You paste your own key, point it at any compatible endpoint, and the app ships no provider, no key, and no endpoint of its own. If you stop paying your provider, you change the endpoint. The app does not care.
What is actually in the box
A long-lived session process with a sidecar. The window talks to a local sidecar over a socket rather than embedding the runtime. If the sidecar does not come up, the launch rolls back instead of leaving a half-open window on screen. That rollback is boring to write and very obvious when it is missing.
Three egress lanes. Direct, a local SOCKS bridge, and Tor. The Tor lane allocates its SOCKS and control ports per launch instead of assuming the defaults, so two copies of the app do not fight over the same socket. It binds the HTTP bridge on port 0 - the kernel picks a free port - and reports back what it actually got. Shutdown goes through the control socket rather than killing a process and hoping.
The first version reported tor exited during bootstrap for every failure, which is useless: a lock on the data directory, a port already taken, and a genuinely broken binary all looked identical. The current one retries once on a fresh data directory when the failure is a lock or a bind, and maps the remaining causes to something a person can act on.
Local web tools. There is an MCP server in the app that exposes web_search and web_fetch. The search backend URL and key are user-supplied, same as the model. Nothing is proxied through a service I run, because I do not run one.
Why BYOK is the interesting part
The moment a client ships its own endpoint, three things follow: your prompts go through someone else's account, the price is set by that someone, and the client's roadmap is really a roadmap for that endpoint. BYOK separates those. It also means the client has to be honest about compatibility - the moment the model is a variable, the tool has to work with the variable instead of assuming one vendor's quirks.
Practically that means the provider layer is a shell: a base URL, a key, a model name, and a wire format. No default endpoint compiled in. If the repository ever grew a hardcoded URL, the whole premise would be dead, so it is the one thing worth guarding in review.
Packaging
Windows gets an NSIS installer. macOS and Linux builds come out of the same release workflow. The installer carries the runtime binary and a version file, and the release pipeline checks that the version inside the payload matches the tag - a mismatch is the kind of bug that ships quietly and confuses everyone for a week.
The licence is MIT. If you want to fork it and put your own provider in, that is the point.
What I would like feedback on
Two areas where the bugs live:
- The Tor lane. Bootstrap timing, data directory reuse, and shutdown behaviour under a slow network. If you have run Tor inside a desktop app and have opinions about lifecycle, I want them.
- Packaging. Windows installer edge cases, macOS notarisation, and the Linux AppImage/deb split.
Repository: https://github.com/9562295450/Oliviacode
Discord for release notes and Tor-lane questions: https://discord.gg/kDcRCu6ek
If you try it, the useful report is the one that says which lane, which OS, and what the log said - not just "it did not work".
Top comments (0)