launchdock: one local gateway for Claude and GPT across coding tools

The credential sprawl launchdock targets

Every coding assistant wants its own login. OpenCode, Codex, Claude Code, Droid and Pi each keep credentials and model configuration in their own place, and the README lists avoiding separate credentials and configs everywhere as the first reason people use launchdock. The project also frames the goal as using OpenCode or Codex with the accounts you already have, rather than buying API access separately.

The intended reader is a developer who runs more than one of those tools on the same machine and is tired of re-authenticating per tool. It is not a hosted service. launchdock is a local process that holds managed credentials and presents one endpoint to whatever client you point at it. The README names a second audience too: people who want to push managed auth to a personal server, which the auth push command handles.

How the gateway exposes three API surfaces

launchdock runs on http://localhost:8090 and speaks three request formats. The README's support matrix is the clearest description of the design: /v1/chat/completions serves both GPT and Claude with OpenAI-compatible chat semantics and tool calls; /v1/responses serves both models with native OpenAI Responses semantics; /v1/messages serves Claude only, in the native Claude Messages format. GPT is not available on /v1/messages.

The three surfaces differ in how reasoning is surfaced. On /v1/chat/completions, thinking arrives through compatibility fields such as choices[].delta.reasoning_content, which the README calls the best default for broad client compatibility. On /v1/responses, reasoning comes through native events and items, including response.reasoning_summary_text.delta and reasoning output items. The README describes /v1/responses as the preferred endpoint for the richest reasoning lifecycle, and that phrasing is a claim about the project's own endpoints, not a benchmark.

One mechanism is worth calling out because it is the kind of thing that silently breaks clients. Claude OAuth internally prefixes tool names with mcp_ when talking to Anthropic. launchdock strips that prefix before returning tool or function names, so a client still sees get_weather rather than mcp_get_weather. Without that strip, tool dispatch in OpenAI-compatible clients would fail against names the client never registered.

State is file-based and the README lists the paths: ~/.launchdock/launchdock.pid, ~/.launchdock/launchdock.log and ~/.config/launchdock/config.json. The top-level repository layout shows the CLI split across auth_cli.go, launch_cli.go and runtime_cli.go, with a web/ directory and an internal/ package tree. Legacy llm-mux code is preserved on the legacy/llm-mux branch rather than deleted.

Installing launchdock and running a first request

The README gives a single install path: a shell script piped to sh. The same script accepts LAUNCHDOCK_VERSION to pin a release and INSTALL_DIR to change the destination.

curl -fsSL https://raw.githubusercontent.com/nghyane/launchdock/main/install.sh | sh
launchdock version

After that, the quickstart logs into each provider, lists what was stored, starts the runtime, and launches a tool with configuration written for it.

launchdock auth login claude
launchdock auth login openai

launchdock auth list
launchdock start
launchdock launch opencode --config

The README states that launchdock launch checks credentials, starts the local runtime if needed, writes tool config when required, and then launches the tool. The --config flag on the OpenCode path merges into an existing OpenCode config instead of overwriting unrelated keys, which matters if you have hand-edited that file.

To confirm the gateway is up, the README suggests querying the model list on port 8090.

curl http://localhost:8090/v1/models

You should see the Claude and GPT models the local provider exposes. If you need Claude thinking through an OpenAI-compatible client, the README provides two aliases, claude-sonnet-4-6-thinking and claude-opus-4-6-thinking, which enable thinking automatically for clients that do not serialize Claude thinking config reliably. For OpenCode specifically, the README says to prefer those aliases over client-side thinking configuration through a custom OpenAI-compatible provider.

Where launchdock stops being the right tool

The support matrix is the first hard boundary. If your client only speaks the Claude Messages format and you want GPT behind it, launchdock will not help: /v1/messages is Claude only, and the matrix marks GPT with a dash there. Claude on that surface reuses the same managed Claude account auth as the OpenAI-compatible endpoints, so there is no separate key path to fall back on.

The second boundary is the auth model itself. launchdock is built around account logins through the native Claude and OpenAI flows, not around pasting API keys. If your organisation issues API keys and forbids interactive account login on developer machines, the project's central mechanism does not apply to you, and the README offers no API-key alternative.

The third is operational. The README documents auth push as installing or updating launchdock on the remote host automatically and then importing your managed credentials. It does not document a rollback, a dry run, or a way to inspect exactly what lands on the remote before it happens. Pushing credentials to a server is a one-way operation as documented, so treat the target host as something you are willing to modify. There is also no documented multi-user story: the state paths are per-user files under ~/.launchdock and ~/.config/launchdock, which fits one developer per machine, not a shared team gateway.

Finally, the release history is short and the version numbering is not monotonic. The recent releases list shows v0.1.2 on 2026-04-01 and v0.1.1 on 2026-03-28, but also a v2.2.8 tagged on 2026-01-30, which predates both. That v2.2.8 entry is consistent with the preserved legacy llm-mux code rather than with the current 0.1.x line, but the README does not explain the relationship, so pinning a version from a badge or a tag list without reading the release notes is a real way to install the wrong thing. The last push to the repository was on 2026-05-01.

launchdock against a plain API-key proxy

The obvious alternative is a conventional LLM proxy that holds provider API keys and forwards requests, the shape most teams already run. The difference is in what gets stored and what gets reused. A key-based proxy is configured once with secrets and every client authenticates to the proxy; launchdock instead performs the native Claude and OpenAI logins itself and reuses that managed auth across local tools, which is why the README can offer auth push to a personal server as a feature.

That choice cuts both ways. A key-based proxy is trivial to rotate and to scope per team, and it does not care whether the upstream provider offers an interactive login. launchdock depends on those login flows existing and continuing to work, and its value is concentrated in the reuse of a single account session. If your upstream access is already key-based, launchdock adds a layer without removing one.

The second alternative is simply configuring each tool directly. That is less work than it sounds for a single tool, and it is what launchdock is replacing. The project only pays off once the number of tools, or the number of machines, makes per-tool credential management the actual cost.

Licence and what maintenance costs you

launchdock is MIT licensed, and the repository carries a LICENSE file at the top level. MIT permits commercial and private use, modification and redistribution with the licence text retained. That is a permissive baseline, but it says nothing about the upstream terms attached to the Claude and OpenAI accounts the gateway logs into; those are separate agreements between you and each provider, and the README does not address them. None of this is legal advice.

Upgrade cost is low on the surface. The README lists launchdock update alongside start, ps, logs, restart and stop, and the install script accepts LAUNCHDOCK_VERSION for pinning. The genuine cost is configuration drift: launchdock launch opencode --config rewrites tool config, and the README only guarantees that it merges rather than overwrites unrelated keys for OpenCode. No equivalent merge guarantee is stated for codex, claude-code, droid or pi, so a version bump that changes what gets written is something to check against your own config files rather than assume. The logs at ~/.launchdock/launchdock.log are the place to look when a launch succeeds but requests fail.

Editorial conclusion

Adopt launchdock if you already hold Claude and OpenAI accounts, use more than one of the five supported tools, and want a single local endpoint on port 8090 instead of duplicated keys. Skip it if you only run one tool, need a hosted multi-tenant gateway, or cannot accept that the README documents no rollback for auth push. Before relying on it, verify the install script against install.sh in the repository, confirm your client works against the endpoint your tool actually uses, and test auth push against a throwaway host first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nghyane/launchdock on GitHub
4. README
5. Releases