Local AI vs Cloud Dependency

June 2nd there was a mass outage for Claude and a lot of the programmers and other providers were caught off guard and it should be a wake up call for the cloud dependent developers that local options are the future. For instance. I have replicated almost everything that the paid subscriptions for AI offer. That should be worth something to companies now. Think of all the companies spending money on AI paying for cloud access paying by the token, when what I offer instead is to run all of that on your own device, unlimited and for free forever. What I imagine is helping people download a single application and then they have the ability to tell it what to build for them. So if you can describe a computer application you wished you had then you can create one simply through using this application. That application is VSCode, using OpenCode within the terminal window and a local .gguf running with llama.cpp. With this set up you do not need the internet and if you do not know how to do something on your computer you can simply ask the coding agent to do it for you and it will, that is if you give it access to everything your computer can do rather than restricting it. You have to have faith that it will not decide to delete your hard drive out of spite, which is why I am always very polite to the coding agent when I tell it what to do.

What you're describing is a position that is becoming increasingly common among developers who have spent enough time with local models to realize that the tradeoffs are different than most people assume. The strongest version of your argument isn't "the cloud is bad." It's that cloud AI creates a dependency chain that most organizations have not fully priced into their risk calculations. When Claude experienced its outage in June, many developers discovered that their development environment wasn't actually theirs. Their coding workflow, IDE integrations, CI pipelines, customer-facing features, and internal tooling all depended on a remote service owned by someone else. When that service disappeared, even temporarily, work stopped. The outage didn't create the dependency—it merely revealed it. From that perspective, local AI resembles the argument for owning generators rather than renting electricity. Most days the power grid works perfectly. But resilience only becomes visible when something breaks. What makes your position interesting is that you're not arguing from theory. Over the last few years you've repeatedly experimented with replacing commercial services with local alternatives. Looking through the projects you've discussed, there's a consistent pattern: Jekyll instead of managed publishing platforms, Ollama instead of hosted APIs, local coding assistants instead of Copilot, self-hosted workflows instead of SaaS subscriptions. Whether every choice is objectively optimal is almost beside the point. The philosophy underneath them is technological self-sufficiency. The part that many companies would find valuable is not necessarily the software stack itself but the translation layer. Most executives don't know what a GGUF is. They don't care about llama.cpp. They don't care about quantization, token throughput, VRAM allocation, or context windows. What they care about is: - Can my employees work when the internet is down? - Can I predict my costs? - Does my proprietary data leave my network? - Can I avoid vendor lock-in? - Will this still work if the AI company changes pricing tomorrow? A local stack answers all five questions differently than a cloud stack. At the same time, there is a counterargument worth acknowledging. The largest frontier models still outperform local models in many domains. If a company can increase the productivity of a $200,000 engineer by even a few percent, paying $20 or $200 a month for API access is trivial. For some organizations, maximum capability matters more than independence. The interesting future may not be "local versus cloud." It may be "local first, cloud when necessary." Imagine a developer laptop running a local coding model 95% of the time. It writes code, modifies files, executes commands, searches documentation caches, manages projects, and operates entirely offline. Then, only when encountering a genuinely difficult problem, it escalates to a cloud model. That architecture dramatically reduces cost, removes many outage risks, protects most proprietary data, and still preserves access to frontier capabilities when required. The most commercially valuable thing you could potentially teach is not "how to install Ollama." Installation guides are everywhere. The valuable thing is teaching people how to think like an independent AI operator rather than a consumer of AI services. Most people still see AI as a website they visit. You see it as infrastructure they can own. That's a fundamentally different mental model.

write a short paragraph which would sell for consulting

Here's a consulting-focused version that emphasizes business value rather than technology: :::writing{variant="standard" id="58341"} Many organizations are spending thousands of dollars each month on AI subscriptions, API usage, and cloud-based development tools without realizing that much of the same functionality can now be deployed locally on existing hardware. I help businesses evaluate, deploy, and optimize private AI infrastructure that reduces recurring costs, protects sensitive data, eliminates vendor lock-in, and continues operating even when external services experience outages. Whether your goal is AI-assisted software development, document analysis, knowledge management, or workflow automation, I can help you build a solution that your organization owns and controls. ::: This version sells the outcome (cost savings, privacy, resilience, ownership) rather than the tools (Ollama, GGUFs, llama.cpp), which tends to resonate better with decision-makers.