Skip to content
minimachine.
← The path
Step 23 · Working well Easy · 8 min

📚Resources, help & troubleshooting

The links that matter, the communities where you can ask your questions, and the reflexes for when something jams. Your address book for what comes next.

There you go, your machine is running and your agent is working. One simple truth remains: you won’t remember everything, and one day something will break. That’s normal. This guide is your address book, the docs that are authoritative, the people who answer, and the moves to make when things go sideways.

The official documentation

When a technical doubt comes up, the official source always beats the tutorial copied ten times over. Here are the authoritative pages, by tool:

Learning and getting inspired

Beyond troubleshooting, this is where you step back and discover what’s moving:

  • Anthropic Engineering, Anthropic’s posts, including the Claude Code best practices. Reading that genuinely changes how you steer an agent.
  • Hugging Face, the hub of open-weight models. Just about everything that ships for local use passes through there.
  • r/LocalLLaMA, the pulse of the local-model community. New releases, homegrown benchmarks, field reports.
  • Artificial Analysis, model comparisons (speed, quality, price) on measured data rather than gut feeling.

Where to ask for help

The most cost-effective reflex: someone has already hit your error. Really. Paste the exact message into a search engine, and you’ll often land on the solution written by a stranger who was struggling just like you six months ago. And if not, these places welcome questions:

The troubleshooting reflexes

When something breaks, don’t panic. There’s an order of operations that resolves 90% of cases:

Actually read the error message

Don’t close it in a panic. Most errors say exactly what’s wrong, in plain words. Take ten seconds to read it.

Give it to your agent

Paste the error into Claude Code or OpenCode. Decoding cryptic messages is precisely what it does best. Often it diagnoses and proposes the fix right away.

Look at the service logs

If it’s a service that’s failing, the logs talk: journalctl -u <service> -e for the last lines, and systemctl status <service> to see if it’s running and why it crashed.

Search for the exact error string

Copy the most precise bit of the error (not all of it, just the key sentence) into a search engine. Someone has been there before you.

git is your 'undo' button

If you broke something while editing, and you were committing regularly, you roll back painlessly. That’s the whole point of commits as a safety net, detailed in Securing access.

Reboot

Yes, really. A reboot fixes more problems than we like to admit, stuck services, finicky mounts, a wonky state. Worth a try before despairing.

Keeping the machine in shape

A few commands worth knowing for a quick health check:

htop          # CPU/RAM load in real time, and who's eating what
df -h          # disk space, models fill it up FAST
ollama ps      # which models are loaded in memory right here, right now

And for maintenance that runs on its own: automatic security updates (unattended-upgrades, configured in System settings) keep the system patched without you thinking about it. It’s the kind of thing you set up once and forget, exactly as it should be.