Troubleshooting
Most problems fall into one of four buckets: the model server, GPU selection, ports, or the browser. Start with whichever matches your symptom.
The agent won’t respond / no model
Atomic Agent can’t do anything without a healthy model server behind it. Check the daemon first:
atomic-agent models statusThis polls the server’s /health endpoint. If it doesn’t report ok:
- Nothing is running. Start the managed daemon:
atomic-agent models start. - No model selected. Pull and select one:
atomic-agent models pull qwen-3.5-4bthenatomic-agent models use qwen-3.5-4b. - The daemon timed out. Managed mode waits up to 30s for
/healthto returnok. A large model on a slow disk can exceed that on first load — runmodels startagain; the model is cached after the first pull.
”Insufficient VRAM” or the model won’t load
Atomic Agent computes a VRAM budget before loading a model. On macOS it uses 75% of unified memory; on Linux and Windows it reads the selected GPU’s reported VRAM.
- Pick a smaller model. The default
qwen-3.5-4bis the lightest starting point. Runatomic-agent models listfor the catalog. - Confirm the right GPU was picked. Enumerate devices and select one explicitly:
atomic-agent models devices # list detected GPUsatomic-agent models use-device auto # or: cpu | Vulkan0 | Vulkan1 …auto prefers a discrete GPU over an integrated one, even if the integrated GPU reports more memory. Force cpu if you want to run without the GPU entirely.
Port already in use / can’t reach the server
The managed llama-server defaults to http://localhost:8000. If another process holds that port, or you run the server elsewhere, point Atomic Agent at the right URL:
export ATOMIC_AGENT_LLAMA_URL="http://127.0.0.1:8080"Or set localModels.url in config.json. In external mode, Atomic Agent only connects — it never spawns a server — so make sure your llama-server is actually up and reachable at that URL. It probes /health and /props at startup to detect the model profile.
The browser tools don’t work
Browser binaries aren’t bundled — install Chrome, Edge, or Chromium yourself first. Then, if launching fails:
# Point at the right channel or an explicit binaryexport ATOMIC_AGENT_BROWSER_CHANNEL=chrome # chrome | msedge | chromiumexport ATOMIC_AGENT_BROWSER_EXECUTABLE_PATH=/path/to/chromium
# Attach to a browser you already run, instead of launching oneexport ATOMIC_AGENT_BROWSER_CDP_URL=http://127.0.0.1:9222Inside a container or CI, the browser sandbox can fail to start. Disable it only in those environments:
export ATOMIC_AGENT_BROWSER_NO_SANDBOX=1 # containers / CI onlyMissing tools on Linux
Some desktop tools (clipboard, notifications, window control) depend on small system packages that aren’t bundled — for example xclip, libnotify/notify-send, and wmctrl. Atomic Agent probes for them at startup and reports what’s available in its capabilities summary, so if a tool is missing it simply won’t reach for it. Install the ones you need — see the Installation → Linux notes.
A config change didn’t take effect
Config is cached at runtime. Secrets written to .env (like a Telegram token) and some config edits are picked up after a restart, not mid-session. Restart the agent, or reset the cache, if a change doesn’t seem to apply.
Still stuck?
- Re-read the relevant page: Installation, Local models, or Configuration.
- Check the FAQ.
- Open an issue on GitHub with your OS, the output of
atomic-agent models status, andatomic-agent models devices.