Launched this week
Bob's CLI
A local-first AI coding CLI that adapts to you
246 followers
A local-first AI coding CLI that adapts to you
246 followers
Bob's CLI runs on your own hardware with zero API costs, zero data leaving your machine. Bob lives in your terminal, sees your actual files, and writes code only with your explicit approval. What makes it different: auto-detect local AI models, behavioral DNA profiling that adapts to how YOU work, autonomous code review + auto-fix, conversation forking, deep dives, and SovereignLink — remote execution from any device while your code stays home. Free to start. Sovereign by design.
Bob's CLI
Hey Everyone 👋 Kemone here, founder of Bob's Workshop.
I built Bob's CLI because I was tired of a lie this industry keeps selling: that you need to quit your job, raise capital, and go all-in to build something real. That's gatekeeping dressed up as hustle culture. The truth? You can keep your day job, pay your bills, and still ship production-grade software — if your tools respect your time.
The Reality for Most Builders:
You're a developer with a 9-5. You have a side project — maybe a SaaS, maybe an app, maybe something that could change your life. But you only get 45 minutes on the train. An hour before bed. A lunch break at your desk. And every time you sit down, you waste half that time just remembering where you left off.
What Bob's CLI Actually Solves:
Bob is a senior AI engineering partner that lives permanently in your terminal. He remembers your entire project architecture. He remembers your last conversation. He remembers YOUR patterns — how you think, how you decide, how you build. So when you open that terminal at 6am before work, there's zero ramp-up time. You're immediately productive.
But here's where it gets real — SovereignLink. Start bob serve on your desktop before you leave the house. Now your home machine is a personal AI cloud. On the bus? Send commands from your phone through the web app. At a coffee shop with a Chromebook? bob remote chat "add the payment webhook". Your desktop at home receives it, reads your actual files, generates the fix, writes it to disk. You come home and the feature is waiting for you.
No dropout required. No VC required. No risk required.
Just a developer with a vision, a terminal, and a tool that refuses to waste their time.
What Makes This Different From Every Other AI Tool:
Runs on YOUR hardware — zero API costs on the free tier
Your code NEVER leaves your machine unless you choose
Auto-detects your local model — type bob chat "hello" and it just works
Behavioral DNA profiling — Bob adapts to your style over time
Conversation forking — explore ideas without losing your thread
Autonomous code review — Bob finds bugs while you sleep
One command to push: bob push "shipped it" — stage, commit, push, done
Who This Is For:
The developer who drives for DoorDash but has an app idea. The teacher coding between classes. The parent building after bedtime. The full-time employee who's also a full-time dreamer. You don't need to bet your livelihood to build something incredible. You just need a tool that multiplies the limited time you have.
Install it:
Bash
Your AI. Your hardware. Your schedule. Your future.
I'm in the comments all day — tell me about the project you're building in the margins of your life. I guarantee Bob can help you ship it faster. 🌱
Local-first for a coding CLI is a genuinely interesting architectural choice. Keeping code context local avoids round-trip latency and the data-residency concern that blocks enterprise adoption of cloud-based tools. What's powering the 'adapts to you' part? Is it RAG over the local codebase, fine-tuning on usage patterns, or closer to behavioral prompting based on past interactions?
Bob's CLI
@anand_thakkar1 Great breakdown of the tradeoffs you get the space. To answer your question: it's all three, but layered.
Project context uses RAG over the codebase that handles the "what are you building" awareness. Combined with summarization and dynamic file mapping. But the personalization layer is a completely separate proprietary architecture. Our Frank Engine (built alongside NVIDIA and Google Cloud) maintains a dual-structure memory system short-term interaction patterns and long-term behavioral DNA that profiles how you think, how you make decisions, and what approaches have failed for you before. It's not retrieval. It's not fine-tuning. It's a purpose-built personality engine that self learns your engineering philosophy over time so Bob's responses aren't just contextually accurate they're you-accurate.
The "sovereign by design" framing is appealing, and credit where it's due, I checked the npm package and it's MIT with a public repo, so the code is actually auditable. For a tool that reads all my files and profiles how I work, that's exactly the right answer to "why should I trust it," and it's worth shouting louder than you do.
One thing I'd still love clarified: you mention "Built with Firebase," which is Google infrastructure, while also promising nothing leaves my machine. So where does the "behavioral DNA profiling" actually live, local on disk, or synced anywhere? Spelling out exactly what touches the cloud (auth? telemetry? nothing?) vs. what stays local would make the sovereignty pitch land even harder. Not a gotcha, the open code already won me over, just closing the last gap :)
Bob's CLI
@keirodev Really appreciate you auditing the repo that's exactly the kind of scrutiny we welcome. To answer directly: you choose your storage tier. Tier 1 is fully local your conversations, behavioral DNA, project index, everything lives in ~/.bob/ on your machine. Firebase doesn't exist in that world. Tier 3 is opt-in (NON DEFAULT) sync across our ecosystem (web, mobile, CLI) for users who want cross-device continuity and even then, your source code is never transmitted. Only conversation context and profile data sync. The boundary is: your decision to to activate the explicit gate between "nothing leaves" and "I choose to sync." No telemetry, no silent uploads, no gray areas.
@kemone_phillips That's the answer I was hoping for, and the three-tier model with an explicit opt-in gate is genuinely the right architecture. "Your decision is the boundary" is a clean principle. The one thing I'd push on: that clarity needs to live where the user actually makes the choice, not just in a PH reply to someone who read the source. The moment Tier 3 sync gets enabled is exactly where you should spell out, in-product, what crosses the line ("conversation context and profile data sync, your source code never does") and let people confirm it. An opt-in only earns trust if it's informed at the point of opt-in, otherwise "non-default" quietly becomes "the button I clicked without reading." Do that and the sovereignty pitch is airtight: local by default, cloud only by a deliberate, clearly-labeled choice.
You're already 90% there, just make the gate as loud as your README :)
Local-first with auto-detected local models is a great angle, especially the no-API-bill part. Curious about the day-to-day feel: on a normal laptop with a local model, is it fast enough to keep in the loop while coding, or more of a background reviewer?
Bob's CLI
@ianhxu We've tested it on the NVIDIA RTX 5070 Ti (via Acer Predator) and the NVIDIA RTX 4050 (via HP Victus). On the RTX 5070 Ti, responses come back in 2-4 seconds with a 7B model — fast enough to stay in your flow while coding. The 4050 is slightly slower (4-8 seconds) but still very usable for iterative chat. For Apple Silicon machines like the MacBook Neo (A18 Pro, 8GB unified), a model like Gemma 4 E4B fits comfortably in memory. Based on the hardware specs and Apple's Neural Engine acceleration, we'd expect similar response times to the 4050 solidly in the keep in the loop while coding range.
You say updates ship daily. For users who intentionally keep everything local and don't update constantly, how do you avoid version drift between what you're demonstrating and what they're actually running?
Bob's CLI
@jared_salois Great question. The CLI is distributed via npm, so users control when they update...pnpm update -g @bobsworkshop/cli when they're ready. We version intentionally: core features are stable across versions, and new capabilities are additive, not breaking. If you're on v0.5.6 and we're demoing v0.7.1, your existing commands still work identically you just don't have the new ones yet. We also flag significant updates in the terminal on launch so users know when something meaningful is available without forcing anything. Your machine, your pace.
Nice angle. For a local-first coding CLI, the thing I’d want to see is how it handles the boring failure cases: failed tests, half-applied edits, and leaving a diff that is easy to review or roll back.
Bob's CLI
@kevinzrzgg Really appreciate this question these are exactly the failure cases we obsess over. Today, every file edit goes through an approval gate (nothing writes without your explicit yes), and every approved write auto-backs up the original to .bob-backups/ with a timestamp. Our auto-fix agent also runs programmatic validation before writing if the output looks corrupted, it's rejected and the file is never touched.
Honest gap: we don't have a dedicated bob rollback command yet, thanks to your questions that's now listed as something mandatory to be implemented starting today. Until then, recovery is .bob-backups/ or git checkout. Expect a proper rollback flow in the coming days. (we release updates EVERY day... 😊)
@kemone_phillips @amanda_phillips6 Local-first is a strong direction for coding tools. The more an AI assistant learns from your workflow, the more important it becomes that developers understand what context is being used and can keep control of the environment.
Bob's CLI
@amanda_phillips6 @alpertayfurr 100% agree sovereignty over your own context is non-negotiable for us at Seedling. That's why everything Bob learns about you stays on your machine by default. Your code, your behavioral profile, your conversation history all local in ~/.bob/.
Nothing leaves unless you explicitly choose to sync. Full transparency, full control, always.
Give it a spin: pnpm add -g @bobsworkshop/cli
#DreamBuildGrowTogether🌱
@amanda_phillips6 @bobsworkshop @kemone_phillips That local ~/.bob/ approach is a strong trust signal. For coding assistants, context gets sensitive fast because it’s not just code — it’s habits, decisions, and project history. Default-local with explicit sync feels like the right baseline.