Desktop LLM gateway
The gateway that runs on your desktop.
Solidway sits between your application and your model providers. Requests and responses pass through byte for byte, while failover, load balancing, circuit breaking and telemetry happen around them.
v0.1.0 · Linux · Windows · macOS · AGPL-3.0
- gateway
- running · 127.0.0.1:6565
- console
- built in, signed in
- tray
- always on
routes
3
API keys
5
requests today
12,480
- 1
- installer, gateway and console included
- 3
- platforms: Linux / Windows / macOS
- 0
- servers to deploy separately
Solidway
Three things Solidway does not ask of you
Most gateways assume a server and an ops team. Solidway starts from the machine you already use.
- 01does not
It does not require a server
The installer carries the gateway and the console, so a laptop is enough to start. When a team needs shared access, the same binary runs as a Linux service (deb/rpm + systemd) on your own server.
- 02does not
It does not hand your accounts to anyone else
Upstream credentials are encrypted on your disk with a local master key, and the process contacts no external control plane at runtime.
- 03does not
It does not hide what happened
Requests, tokens, latency, failovers and provider incidents are recorded per route, API key, provider and model, and are queryable in the built-in console.
Linux · Windows · macOS
One app, the whole gateway
Solidway starts as a desktop app: one install puts the gateway, the console and the account pool on your own machine. It also runs as a Linux service, so the same setup can be shared by a team.
One install, the whole stack
The installer carries the gateway binary and the console. No server, no container, no separate service package to add afterwards.
Tray and start at login
Close the window and the gateway keeps serving from the tray; enable start at login to have it ready after a reboot.
Same engine as the server
Pooled accounts, failover before the first byte, usage attribution and incidents behave identically — only the packaging differs.
Console in a webview
The console opens inside the app and is signed in with a process-scoped token; the admin password is optional and can be set later.
Features
What runs alongside the forward path
Forwarding is the fast path. Everything here is evaluated per request, outside the bytes you send.
Failover
Ordered fallback chains across providers, models and keys. Each attempt carries its own timeout budget, so a slow primary cannot consume the whole request deadline.
failover
Load balancing
Weighted distribution across keys and endpoints, with health-aware scoring that adjusts to observed latency and error rates instead of a fixed table.
load-balancing
Circuit breaking
A target that reports a credential, quota, access or rate-limit failure is held out of rotation. It returns to service after a single probe confirms it can serve again.
circuit-breaking
Desktop app
The same gateway as a desktop application for Linux, Windows and macOS: one install carries the gateway and the console, starts at login, lives in the tray, and needs no server.
desktop-app
Self-hosted
One static binary, installed as a deb/rpm package or unpacked by hand, inside your own network. No external control plane is contacted at runtime.
self-hosted
Analytics
Requests, tokens and latency broken down by route, API key, provider, model and owner, so usage can be attributed to the team that produced it.
analytics
Incidents and alerts
Provider failures are recorded as incidents with duration and attempt counts, and pushed to a webhook with retry and per-provider throttling.
capacity-alerts
Architecture
Transparent by design
The request path has three stages, and only the middle one is ours.
client
Client
Your application, any SDK
gateway
rustSolidway
Routing, accounting, health
- select target
- record usage
- judge health
- preserve bytes
primary
upstream 5xxprovider-a/gpt-6-astra
fallback
returns responseprovider-b/gpt-6-astra
A request that fails on the primary target is served by the next target in the chain.
Rust
Written in Rust
One statically linked binary. No garbage collector, no interpreter, and no runtime package to install on the host.
No garbage collector
Memory is released at deterministic points, so the tail of the latency distribution is not affected by collection pauses.
One file to ship
The build produces a single binary for x86-64 or arm64. There is no runtime package, no sidecar and no version matrix to maintain.
Flat memory under load
Throughput scales with available cores. Steady-state memory is bounded by the configured connection pools rather than by a heap.
Memory safety at compile time
In safe Rust, the borrow checker rejects the class of defects that produce buffer overflows and use-after-free before the binary is built.
Observability
Usage and incidents
Every request produces a usage record. Records are queryable in the console and retained according to the policy you configure.
dashboard (sample)
last 24h- requests
- 1,284,930
- error rate
- 0.31%
- p99 latency
- 1.42s
- tokens
- 48.2M
+4.1%
-0.12%
+0.04s
+6.3%
latency distribution
| target | share | errors | state |
|---|---|---|---|
| openai / gpt-6-sol | 52% | 0.18% | serving |
| anthropic / claude-sonnet-5-5 | 31% | 0.24% | serving |
| bedrock / claude-opus-5-5 | 14% | 1.10% | degraded |
| azure / gpt-6-astra | 3% | — | held |
sample data, shown for layout
Next step
Talk to us about your architecture
Tell us how your traffic is shaped today. We will walk through where a forward path fits, what the failure policy should look like, and how the gateway would be deployed in your environment.
No pricing on this page. Every deployment is scoped individually.
- A review of your current provider and key layout
- A failure policy matched to your error classes
- A deployment shape for your network