Paste your KoboldCpp log and find what went wrong
Paste the whole console output (or open a .txt file). The analyzer hides personal details, finds the deepest real error rather than the last line, and tells you whether your GPU is being used.
Checked against KoboldCpp 1.124.2 · updated 13 Nov 2026
- lab-lnx: Linux test VM · 4 vCPU · 15 GB · no GPU
- gha-w25: Windows Server 2025 test machine · 4 vCPU · 16 GB · no GPU
- gha-w22: Windows Server 2022 test machine · 4 vCPU · 16 GB · no GPU
- gha-u24: Ubuntu 24.04 test machine · 4 vCPU · 16 GB · no GPU
- gha-mac15: macOS 15 test VM (Apple Silicon) · 3 vCPU · 7 GB · paravirtual Metal
Log and error analyzer
Find the real error, check whether the GPU is used, and get ordered fixes.
Where to find your KoboldCpp log
The console window is the log. KoboldCpp prints everything there and, in our test, wrote no log file anywhere F58. That has two practical effects. If you start KoboldCpp by double-clicking and the window closes on an error, the text is gone. And the launcher window only shows the last error, not the whole story.
- Start KoboldCpp from a terminal so the window stays open. The steps are in Will not start.
- Select all the text in the console and copy it. In Windows Terminal, Command Prompt and PowerShell you can drag with the mouse and press Enter or right-click; on Linux and macOS use the terminal’s copy command.
- Paste it above. If it is long, that is fine: the analyzer reads up to 2 MB.
For more detail, set Extra diagnostic output: -1 quiet (used for Horde), 0 normal, 1 verbose, higher for more detail.Default 0Launcher Hardware tab: Debug ModeSince v1.15All details. It prints extra diagnostic output; the default is 0 and higher values add more. Use it only when you are asked to, because the output gets long.
How to read the result
The verdict card has three parts: one sentence, a confidence label and the evidence behind it.
- Exact match means a known message appeared in your log. The sentence and the fixes come from our error list.
- Likely means the analyzer found a wrapper message or a combination of facts that usually points to one cause, but the log does not prove it.
- No match means nothing in the log matched. The card then lists what to do next.
The real cause can be above the last line
Many logs end with a wrapper. In a truncated model download, for example, three lines belong together: the loader says a tensor is not within the file bounds, then a general failure line, then Could not load text model F21. Only the first line tells you the download is incomplete. The analyzer shows the first one as the cause and marks the others as wrappers. Every error explained shows more examples.
The GPU fact uses the buffer lines
KoboldCpp prints offloaded N/N layers to GPU even when there is no GPU to offload to. On a machine without one, our log still said all layers were offloaded while the KV cache sat in system RAM F17. The analyzer therefore checks where the model and KV cache buffers live. See Not using the GPU for the same check by hand.
What the amber and red flags mean
Auto Selected Default Backend (flag=0)means no GPU backend was chosen, so you run on the CPU F18.- The thread count line shows the threads KoboldCpp picked. On our 4-core test machines the automatic choice used about half the cores, and setting CPU threads used for generation. Default is computed from your physical core count (the value shown in --help is machine-specific).Default 2Launcher Hardware tab: ThreadsSince v1.0.8betaAll details gave up to 30% more generation speed F07.
- The allocated context is the context you asked for plus 256 tokens. That is normal F06.
What the analyzer checks
Facts it reads from the log: the version, the backend library that was loaded, the GPU device (CUDA, Vulkan or Metal) and whether it is a software renderer, the layers offloaded, where the KV cache is, the model’s architecture, size and bits per weight, the context you asked for, the context allocated and the one the model was trained on, flash attention, the KV cache type, the chat template adapter, the vision projector and the port.
Cross-checks:
- You asked for GPU offload but the buffers are on the CPU.
- The default CPU backend was chosen although you may expect the GPU.
- A GPU was found but no layers were put on it.
- The model is on the GPU but the KV cache is in system RAM.
- You asked for more context than the model was trained on.
- The CPU reports no AVX2 but a normal library was loaded, which can end in
Illegal instruction. - The Vulkan device is a software renderer.
It knows 57 messages and variants, each with a meaning, ranked causes and ordered fixes. The full list is on Every KoboldCpp error explained. Messages we reproduced ourselves carry a finding number; the others link to the user reports we found.
Your log stays private
Redaction happens before anything is shown. The analyzer replaces user names in Windows, Linux and macOS paths, IP addresses (it keeps 127.0.0.1 and 0.0.0.0), tunnel links, passwords and keys on the command line or in the settings line, bearer tokens, key-like strings and email addresses. The analysis runs in a Web Worker in your browser, makes no network request, and stores nothing unless you copy the result. The example buttons load small text files from this site only when you press them. More in the privacy page.
Accuracy and our tests
The analyzer is tested against 107 findings’ worth of real logs: more than 200 logs from our own runs on Windows Server 2022 and 2025, Ubuntu 24.04, macOS 15 and a Linux VM, covering every failure case we staged (missing model, not a GGUF, truncated file, context out of range, GPU flags without a GPU, port in use, wrong projector, no display, out of memory), the normal starts, and the multimodal runs. Each log has an expected verdict, and redaction has its own fixtures for paths, IP addresses, tunnels and keys. A 200 KB log is analyzed in well under 200 ms.
Limits: messages we have not seen cannot be matched, other languages are covered only where we found examples, very old versions word some lines differently, and a log from an NVIDIA or AMD GPU run with CUDA or ROCm will show wording we could not capture on our test machines. Out-of-memory messages from real GPUs come from user reports until we can measure them. We labelled each message by how we know it.
Nothing matched?
Use the troubleshooting tree, which asks about your symptom instead of your log. Search the GitHub issues for the stable part of the message before you post a new one, and when you ask for help follow what to include. If you think the analyzer should know a message, send us the redacted line through the contact page.
Frequently asked questions
Where does KoboldCpp save its log?
It does not save one by default. In our test on Linux, KoboldCpp created no log file in the working folder, the home folder or the temp folder. The console window is the log, so copy its text, or start KoboldCpp from a terminal so the window stays open after a crash.
Is it safe to paste my log here?
Yes. The analysis runs in your browser and nothing is sent anywhere. Before anything is shown, user names in paths, IP addresses, tunnel links and anything that looks like a key are replaced, so the log you copy out is safe to share.
Why does the analyzer point to a line that is not the last one?
Several messages are wrappers. Lines such as 'Failed to execute script' or 'Could not load text model' only say that something failed. The reason is printed above them, so the analyzer ranks the earliest real cause over the wrapper at the end.
How can I tell from the log if KoboldCpp uses my GPU?
Look at the buffer lines, not at 'offloaded N/N layers to GPU'. If the model and KV cache lines name CUDA0, Vulkan0 or MTL0, the GPU holds them. If they say CPU, the work runs on the CPU, even when the offloaded line claims otherwise. We saw that exact trap in our tests.
What should I post when asking for help?
The KoboldCpp version, your operating system, your GPU, what you changed last, and the whole redacted log from the first line. The 'Copy redacted log' button gives you a version that is safe to post.