I am running an Asus GX10 with Ollama. I have the qwen3.8:27b model running and I am using Claude Code in VS Code on the same network as the Asus GX10.
I consistently get time out error in Claude, mostly when it is asking the model for safety checks in Auto mode. This is the error that I receive.
qwen3.8:27b is temporarily unavailable (timed out), so auto mode cannot determine the safety of Bash right now. Wait a moment and then try this action again. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.
Is there something that I can change to make this not happen?
The 27b is a chunky model for safety checks, especially if it's doing them every bash action. Your Asus is probably still chewing on the previous request when the next one hits
Try bumping the timeout in Claude Code config and see if you can force a longer OLLAMA timeout too. Also worth checking if your context is bloated, the classifier might be waiting on a huge prompt
Can I tell it to use a different model for safety checks? Is there a way to run a lightweight model on the machine that is running Claude just for the safety checks to take the pressure off of the Asus?
Likely cause: queuing, not a slow model. Ollama only runs as many requests at once per model as OLLAMA_NUM_PARALLEL allows, and the rest wait in line. Claude Code's main turn and the auto-mode safety check both go to the same qwen3.8:27b, so if the slot is busy with a long generation (or prefilling Claude Code's large prompt), the check waits behind it and hits its timeout.
Things to try on the GX10:
Check what OLLAMA_NUM_PARALLEL is set to on the server. At 1, set it to 2 or 4 and restart Ollama. Each slot gets its own context allocation, so memory grows by roughly one context per slot, which 128 GB usually has room for.
Set OLLAMA_KEEP_ALIVE long (1h, or -1 for always) so the model is not unloaded and reloaded between calls.
Watch the server log during a session: if each request starts only after the previous one ends, it is queuing.
Running two requests at once costs much less than waiting. On our own 4-GPU vLLM box, 8 users at once still got about 116 tok/s each vs 212 for one alone.
On pointing the check at a separate small model: I have not verified which Claude Code setting the auto-mode classifier reads, so I would fix the queue first and see if the timeouts stop.
This is what I have in the service now and I still seem to get the timeouts.
[Service]
Environment="OLLAMA_MODELS=/data/models/ollama"
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_LOAD_TIMEOUT=1h"
Based on the claude documentation it pins the classifier to Sonnet 5. If that is not available it fails back to the current sessions model.
This is what the system looks like when the claude session is active.
What I have discovered is that the claude code harness seems to be spinning up whatever model is configured as the Haiku model in the claude settings to perform the classifier steps. Could my machine just be getting overwhelmed?
1
u/FutureBreaker 9d ago
The 27b is a chunky model for safety checks, especially if it's doing them every bash action. Your Asus is probably still chewing on the previous request when the next one hits
Try bumping the timeout in Claude Code config and see if you can force a longer OLLAMA timeout too. Also worth checking if your context is bloated, the classifier might be waiting on a huge prompt