Troubleshooting

Symptoms first. Each entry says what the state actually is, not just what to type.

Start by getting the daemon's own view:

saylek status

Add --watch to live-tail it while something is settling.

Install and startup

saylek: command not found

The binary installed to ~/.saylek/bin but that directory is not on your PATH. Open a new shell first, since the installer edits your shell profile and the current session will not have picked it up. If it still fails, add ~/.saylek/bin to PATH yourself.

The daemon is not running

saylek start

The installer registers a user-level service, so this is normally only needed after a manual stop.

First call

model_not_found

The daemon is up but has no model loaded. A fresh install is expected to be in this state.

saylek gpu wizard     # guided: pick and fetch a model
saylek model ls       # confirm it was discovered

If you dropped a .gguf into ~/.saylek/models/ yourself, tell the daemon to look again:

saylek model rescan

HTTP 503, no inference backend compiled in

You are running a binary built with no inference backend. This only happens on a from-source build: cargo build --release without a --features flag compiles, but the result cannot serve.

Rebuild with a backend that matches your hardware: cpu (portable), cuda (NVIDIA), or metal (Apple Silicon). Released binaries already carry one.

Requests fail and nothing is available to serve them

A request for a model your machine cannot serve locally needs another machine that is online and serves it: another machine of your own, a machine shared with you, or a machine in a group you joined. If none is, the call fails until one comes back. Check with saylek status.

Every request fails after you enabled local-only

This is local-only working as designed, not a bug. Local-only stops Saylek routing your request to anyone else: it serves locally or it fails. If your machine cannot serve the model you asked for, every such request now fails.

(One scope note, since it surprises people in the other direction: local-only governs Saylek's own routing. It does not override a proxy upstream you configured yourself, which still receives requests that resolve to it.)

Either load a model you can serve locally, or turn local-only back off in ~/.saylek/config.toml:

[federation]
local_only = false

See Privacy and egress.

Nothing egresses even though local-only is off

A request leaves only for a machine that serves the model you asked for: one belonging to someone who shares with you, or another machine of your own. If you joined a group, one an organization runs or one anyone can join, anyone in it can serve it too. If none of them serves it, the request fails. The local daemon answers federation_miss, or federation_unavailable when the failure is temporary. Check what you can reach:

saylek models --account

Connecting an app

401 or 403 from the hosted endpoint

Your API key is wrong, revoked, or not being sent. A key's secret is shown once, at creation, so if you did not save it, create a new one rather than hunting for it.

Claude Code ignores your key

ANTHROPIC_API_KEY overrides ANTHROPIC_AUTH_TOKEN. Unset it:

unset ANTHROPIC_API_KEY

saylek claude withholds it from the session it starts, so this only bites when you set the variables by hand. It does not edit your shell profile or any other file: if you exported ANTHROPIC_API_KEY yourself it is still set afterwards, and a plain claude still sees it.

404 on the hosted endpoint

Almost always the /v1 suffix, which differs by dialect and is easy to cross over:

The model id is rejected

Saylek carries the advertised model id verbatim. There are no claude-* or gpt-* aliases. List what is actually being served to you and use one of those ids:

curl https://api.saylek.com/v1/models -H "Authorization: Bearer YOUR_API_KEY"

Web search is unavailable or refused

Connecting a model does not add web search. Where your client and model support tool calling, use a search tool your client runs itself. Check the client's tool results rather than assuming a generated answer came from a search.

On the Anthropic Messages endpoint, requests declaring provider-run tool types such as web_search or web_fetch are refused with HTTP 400 before dispatch. The error names the unsupported tool type and links to the setup guidance. This is about the declared tool type, not simply a tool's name. Disable the unsupported provider tool and, where your client supports it, configure a client-run alternative. For Claude Code, follow Web search.

Sharing your machine

You are sharing but your machine shows as offline

Check that the daemon is running and reachable, and that saylek host status reports it connected. Sharing is a separate step from connecting: a connected machine shares only after you turn sharing on, on its page under Machines or with saylek host start.

Your own work feels slow while serving

Work you send from your own machine to its local Saylek API takes priority on its GPU. If it arrives for a model that is serving someone you share with, their request is stopped before it finishes, rather than immediately. If you are not seeing even that, capture saylek status --watch output and tell us, because that is a defect rather than a setting.

Still stuck

Reach us from /support. Include what you ran, what you expected, and what happened, plus the output of saylek status.

Next steps

• Quickstart: the first-run path.
• Privacy and egress: local-only, in full.
• CLI reference: the command tables.

Last checked 2026-09-24 · read as markdown at /docs/troubleshooting.md