SillyTavern API errors: what each one means and how to fix it

Quick answer: four places every error comes from

SillyTavern does not run any model itself. It is a client that sends your chat history to whatever Custom Endpoint you configured and shows you back whatever that endpoint returns, error included. Every failure sorts into one of the four buckets above. Work through them in order rather than guessing. First confirm the URL and key are structurally correct, then isolate whether SillyTavern or the provider is the actual source of the problem with a direct curl call, and only then look at the request itself. The table further down maps exact status codes and messages to which bucket each one belongs to.

• Endpoint URL: wrong path, wrong protocol, or a path SillyTavern already appends itself.
• API key: whitespace from copy-paste, a revoked key, or the wrong Chat Completion Source selected.
• Model ID: wrong casing, a deprecated ID, or an ID your key is not entitled to.
• The request itself: too many calls too fast, or a context window the current chat has outgrown.

How the request travels, and where it breaks

SillyTavern runs a small local server even in the desktop build, and your browser tab talks to that server, not directly to the provider. When you click Connect or send a message, SillyTavern's own backend makes the actual outbound call to your Custom Endpoint with the key in the Authorization header, waits for a response, and relays whatever comes back to the browser. That extra hop changes what a given error is actually telling you. If SillyTavern's backend cannot reach the URL at all, a DNS failure, the wrong protocol, a typo, you get a generic connection error that has nothing to do with your key. If the URL is reachable but the provider rejects the request, you get whatever HTTP status the provider chose to send back, and SillyTavern just displays it. If the URL is reachable and the provider replies with something SillyTavern was not built to parse, a stream cut off mid-token, a response reshaped by an intermediary, you get a parsing error that looks like a SillyTavern bug but is really a shape mismatch further up the chain. Self-hosted and remote installs add one more failure mode. Open SillyTavern in a browser pointed at an install running on another machine, and the browser itself can block a request over CORS before it ever reaches SillyTavern's backend. That shows up as a console error that looks identical to a bad key or a dead endpoint, even though neither is wrong.

Every SillyTavern API error, decoded

Match what you are seeing against the left column. The middle column is where the fault usually sits, and the right column is what to check first, in the order it is worth checking.

Why these errors catch people off guard

None of this is specific to SillyTavern. Any Chat Completion client hits the same categories of failure because it is talking to the same kind of OpenAI-compatible endpoint underneath. Knowing which bucket an error belongs to is most of the debugging work; the rest is confirming it with a request that bypasses SillyTavern entirely.

• A green Connect light only proves /v1/models answered. It says nothing about whether /chat/completions will accept your next message, so a working dropdown can still be followed by a 429 or a context error a few turns later.
• SillyTavern's own error toasts are generic by design, because they wrap whatever text or status the provider sent back. The same toast wording can mean different things on different providers.
• Chat Completion and Text Completion read different fields entirely, so a key or URL that is correct in one mode shows as broken in the other simply because the wrong panel is active.
• Rate limit and context errors are not configuration mistakes. They mean the request itself was too big or too frequent for what the key allows, and re-pasting the URL again will not change that.
• Browser extensions, ad blockers, privacy tools, sit between the SillyTavern tab and the outbound request, and can silently strip a header or block the call, producing a connection error that looks exactly like a bad key.

Hosted APIs vs local backends: different failure modes

SillyTavern supports both a hosted Chat Completion source and local Text Completion backends like KoboldCpp or text-generation-webui. They fail in different ways, and knowing which one you are running narrows the search immediately.

Fix it in this order, not at random

Most SillyTavern support threads skip straight to reinstalling or re-entering every field. The order above is faster because it isolates which single field is wrong instead of touching all of them at once.

• Copy the URL again from scratch instead of editing the old one in place. Stray characters left over from a previous paste are the single most common cause of a URL that looks right but is not.
• Paste the key into a plain text editor first to check for hidden whitespace or line breaks, then paste the cleaned version into SillyTavern.
• Hit /v1/models directly with curl before touching SillyTavern again. A model list coming back means the key and URL are both fine and the bug is inside the saved SillyTavern configuration.
• Copy the model ID out of that same /v1/models response instead of typing it from memory; casing and punctuation both matter.
• If you are getting 429s, stop mashing regenerate. Space requests out, or keep a second budget model configured as a fallback so one throttled model does not stall the whole session.
• If context errors keep appearing, lower Context Size and Max Response Tokens together. Trimming the lorebook usually does more good than shaving the reply length.
• If nothing above explains it, point the base URL at a different OpenAI-compatible endpoint for one test message before spending more time on the original provider. APIsRouter is one pay-as-you-go option with no subscription, useful for checking whether the problem follows you to a new provider or was specific to the old one.
• Rotate the key if you ever suspect it leaked: a shared screenshot, a public repo, a pasted config file. A leaked key fails unpredictably long before you notice it is gone.

Confirm the fix with curl and Python before reopening SillyTavern

Before changing anything else inside SillyTavern, take the URL, key, and model ID out of the app entirely and test them with a plain HTTP client. The -i flag on curl prints the response status line and headers, which tells you immediately whether you are looking at a 401, a 429, or something else, instead of reading SillyTavern's generic toast. A short Python script wrapped in a try/except block gives the same detail without reading raw HTTP: catch the status error and print its body directly instead of relying on whatever SillyTavern's UI decided to summarize.

curl -i https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer sk-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role": "user", "content": "Say ready."}],
    "max_tokens": 20
  }'

FAQ