They asked where their stuff lives.
On Friday 6 November, Rye Smith and I ran Claude office hours for the Claude Community. A good crowd turned up, all of them using Claude for real work. Some write code every day. Some have never opened a terminal.
I expected questions about the new models. Which one to use, whether the latest release is worth switching for, how it compares to the competition.
Instead, almost every question was about plumbing and trust. Here are five of them, with the answers we gave.
"Should my project run in the cloud or on my own machine?"
It depends on where your data lives.
If your project depends on local files, say a second-brain folder or a pile of documents on your laptop, a local project is the simpler choice today. If you want it reachable from anywhere, move that data somewhere that's always on, a Mac mini at home or a cloud store with a connector, and point Claude at that instead.
Rye's tip was a good one: treat a powerful machine as a small server and remote into it when you need it. I do the same thing. My desktop runs all the time and I reach it from my laptop when I'm away.
The honest longer answer is that for most people this distinction is going to fade. The tools are moving towards "it just runs, wherever."
"Is GitHub actually safe for private code?"
Yes. A private repository is about as safe as the Gmail, Google Drive or OneDrive accounts you already trust with your business.
The caveat is the other direction. Someone else's public repository is not automatically safe just because it's on GitHub. Read what you clone, the same way you'd read a skill before you install it.
"Can I back up my database there?"
Short answer: no.
GitHub is built for text files. HTML, CSS, TypeScript, Python, Markdown. It tracks changes line by line, which is exactly what you want for code and exactly what you don't want for images, PDFs, Word documents or database dumps.
If your database lives on a private server, make sure the hosting provider's backup cycle is actually switched on and that you've tested a restore at least once. That's the backup. Not a commit.
"Does Claude pick the right model when it hands work to sub-agents?"
Mostly, yes. In my experience Opus already sends quick file lookups to Haiku and heavier work to Sonnet without being told.
If you want more control, you can set a default model per project, and you can write your own preferences down in a Markdown file so Claude picks them up next time. One attendee already does this, and it's a neat habit.
"Can Claude be jailbroken like the model I saw on X?"
This one comes up more than you'd think.
The "jailbroken" or "abliterated" models you see online are open-weight models. Someone downloaded the weights and retrained them to strip the safety layers out. You can only do that with a model you can run yourself.
Claude is a hosted model. You don't get the weights, so that particular trick isn't possible. It's worth knowing the difference, because those stripped models have been linked to some nasty real-world exploits. I went deeper on agent security in OpenClaw security best practices.
What I Took Away
Not one question about benchmarks.
Capability isn't what's holding people back. They've already seen what these tools can do. What slows them down is the boring stuff underneath. Where does my data go? Who can see it? What happens if I get it wrong?
Those sound like technical questions. They're really questions about trust, and in a company they're leadership questions. When nobody answers them, people either stop using the tools or quietly use them on personal accounts, which is worse.
If you look after a team, three things go a long way:
- Write down where company data is allowed to go. One page is enough.
- Pick a default setup (which account, which tools, which folders) so nobody has to guess.
- Name one person people can ask without feeling silly.
We'll keep running these sessions. Bring your plumbing questions. They're the good ones.
What's the question your team keeps asking that nobody has answered yet?
If you're further along and want to know where your team actually sits, try the 5 levels of agentic software development. I also post lessons like this most weeks on LinkedIn.