I built an offline AI assistant that can actually use your computer

completely agree — trust has to come from more than simply saying “offline.” Being able to understand and verify what the assistant actually did is a much stronger foundation.

We’re also thinking along those lines for more complex actions. The important part is making automation feel powerful without making it feel unpredictable, especially when an action could have meaningful consequences.

CorePilot is still evolving, and improving that balance between autonomy, transparency, and user control is one of the areas I’m particularly interested in developing further.

The screen-understanding side is something we’re still developing further, so I’d rather not go too deep into the underlying implementation yet. What I can say is that our approach is designed around keeping the experience as local and lightweight as possible, while gradually expanding what CorePilot can understand and act on.

Your publishing workflow is actually a great example of where this could become useful — repetitive cross-platform tasks are exactly the kind of workflows we want CorePilot to make easier without depending on a cloud service being available.

Exactly — keeping execution local is a core part of what we’re building, not just a marketing feature.

For model updates, we want to keep the user in control rather than forcing changes on them. CorePilot is designed so the local models remain accessible to the user, which also gives them flexibility to manage or replace models depending on their system and needs.

We’re still refining the update process, but the principle is simple: an update should improve CorePilot without unexpectedly breaking an existing local workflow. And as the project grows, maintaining that stability will remain a priority.

Exactly. That’s one of the things we care about most — CorePilot should fit into the way people already work rather than forcing them to change their workflow around another AI tool.

And I agree about context. That’s a much deeper challenge than simply executing individual commands, and it’s an area we’re continuing to explore as CorePilot evolves. The long-term goal is to make it feel increasingly natural and useful without taking control away from the user.

Exactly. I think the really interesting shift is when AI moves beyond answering questions and starts helping people actually accomplish things. That’s the direction we’re taking with CorePilot — combining automation, context, and user control while keeping privacy at the center.

We’re still refining a lot of the deeper parts of the product, so I’m excited to share more as CorePilot evolves.

That’s a fair criticism, and the 522MB is something I’ve thought about quite a lot. The main reason is that CorePilot includes local models, and even a lightweight local AI stack naturally takes some space. We’ve optimized it as aggressively as we reasonably can, and getting it down to around 522MB was already a significant part of that work.

Even if we moved toward letting users download the models separately after installation, the total footprint would still be roughly in the same range — it would mostly change when the space is used, rather than eliminating it.

As for retention, CorePilot is still at a relatively early stage and we’re currently focused on getting it into more users’ hands and learning from real usage. I don’t want to pretend we have enough data for strong retention numbers yet, but the feedback from the users who have tried it so far has been mostly very positive, which is encouraging.

I agree that the real test is whether CorePilot becomes something people keep using after the initial curiosity wears off. That’s one of the things I’m most interested in learning from the next stage.

Absolutely, and that’s something we take very seriously. CorePilot is designed to give users powerful automation without taking away their control.

For potentially destructive actions, especially things like deleting or modifying files, we want the user to remain in control rather than letting the agent blindly execute everything.

And yes, part of the larger vision is for CorePilot to eventually replace or consolidate many separate utilities into one intelligent local-first toolset — while keeping the user’s data and decisions under their control.

That’s exactly the distinction we’re thinking about. CorePilot is designed for both casual and power users — the goal isn’t to make people understand local models, but to give them powerful automation without requiring technical knowledge.

Offline-first is not just our current positioning; it’s part of CorePilot’s identity. The long-term goal is for a large part of CorePilot to remain offline permanently. Any functionality that requires online access should only go online when the user explicitly asks for it, and the user should always be able to completely disable those online capabilities whenever they want.

In other words, we don’t want to build another cloud AI assistant and simply add an offline mode. CorePilot is offline by nature, and we want to preserve that philosophy as the product grows — just at a much larger scale.

So the target isn’t only developers who want to tinker with local models. It’s also everyday users who simply want their computer to work for them without having to give their data to the cloud.

That’s exactly the challenge we’re thinking about. Our goal is to keep screen understanding local as well. If an online model is ever used for a specific capability, it will be completely optional and explicitly controlled by the user — never required for CorePilot to function.

There are some similarities in the idea of giving users more control through AI, but CorePilot is broader in scope. It’s designed as a local-first computer assistant with system control, automation, scheduling, monitoring, tools, and both casual and power-user workflows. The long-term goal is to go beyond executing commands and make CorePilot genuinely understand the user’s context and computer.

Exactly. That’s also part of our long-term vision. With enough support, we plan to eventually develop models specifically optimized for CorePilot and expand it into a truly cross-platform product. The goal is to make the experience more capable while keeping the local-first approach at its core.

I completely agree, and this is actually one of the directions we’re seriously considering.

But the vision for CorePilot is much bigger than the product you see today. The current Windows version is essentially the foundation.

Our long-term goal is to build a truly capable personal AI that doesn’t just answer questions or execute predefined commands, but can understand the user, understand their environment, see what’s happening on the computer, and eventually act intelligently based on context.

Privacy and local execution are important foundations for that vision. We want users — and eventually organizations — to be able to trust what they give this AI because the core intelligence can remain under their control.

So I think the enterprise use case you mentioned is very interesting, but for us, it’s only one part of a much larger direction.

Thanks! We’ve put a lot of thought into CorePilot’s architecture, with a strong focus on keeping execution lightweight, responsive, and reliable—even on very modest hardware.

One thing we’ve intentionally built into CorePilot is flexibility around its local models. Users can access and replace the models themselves, so the system can be adapted to their hardware. A more capable machine can run a stronger model for better accuracy, while lower-end systems can use lighter models to keep things responsive.

In the current Windows version, CorePilot primarily relies on native Windows APIs and system-level capabilities for execution, rather than continuously running an OCR/vision loop. Users interact with it through a broad natural-language command system, which translates their requests into actions.

Vision-based interaction is something we’re very interested in for the future. The long-term goal is not simply to control the computer, but to make CorePilot capable of actually understanding what it sees, understanding context, and acting accordingly.

And that ties directly into our cross-platform roadmap—the current Windows version is the foundation, not the final destination.

Thanks for the thoughtful questions. In the current version, CorePilot uses four lightweight local models, each dedicated to a specific task:

• A model for long-form speech-to-text

• A model for short speech recognition

• A model for detecting claps/whistles

• A speaker-recognition model

We deliberately kept the core command system lightweight instead of adding a separate NLP model at this stage. CorePilot currently uses a fairly deep command grammar that can parse and organize multiple long and complex commands, then execute them sequentially. This helps keep latency low, especially on lower-end hardware.

CorePilot is offline-first by design. The local models and core system-control functionality don't require sending user data to a remote AI server. Online capabilities are optional and can be enabled or disabled by the user. This is also why we expose the local models to the user rather than hiding them behind a black box.

The current installer is around 522 MB, and the installed/extracted footprint is around 1.5 GB.

For multi-step tasks, the current system can break down and queue multiple commands through its command grammar and execute them in order. That said, I agree that truly deep, open-ended tasks are a different challenge. One of our future goals, if the project gets enough support, is to develop a dedicated NLP system for CorePilot so it can understand much deeper and more complex instructions rather than relying primarily on the current grammar-based approach.

That's ultimately where we want to take it: not just a local assistant that executes commands, but an AI that can understand the user's intent, context, and environment and act accordingly, while keeping the user in control.

Absolutely — I think that’s exactly where the interesting part begins.

We don’t want CorePilot to simply have more permissions; we want it to understand when it should act, when it should ask, and when it should leave the decision to the user.

Keeping sensitive context local is a big part of that philosophy. Developer workflows are also an area I’d love to explore, especially repetitive tasks where an assistant can save significant time without sending the project context to a remote service.

And honestly, the current product is only the foundation. The long-term vision is to make CorePilot much more context-aware — able to understand what’s happening around the user and make useful decisions while keeping the user in control.

I’d definitely be interested in hearing what your team at GeekyAnts has learned from working on similar human-in-the-loop problems.

I think you’ve identified one of the most important questions around CorePilot.

I agree that “an AI that controls your computer” will eventually become a crowded space. That’s why offline-first isn’t just a feature we added to CorePilot — it’s part of the foundation we’re building on.

There are definitely users and organizations for whom sending screen data, files, or sensitive context to a cloud service simply isn’t an option. That makes offline operation a requirement rather than a preference.

At the same time, I don’t want to limit CorePilot to that market. The bigger vision is to build a personal AI that can understand the user, their computer, and their context, while keeping that intelligence as local and controllable as possible.

So I think the sharper question is exactly the one you raised: not “who wants an offline AI?”, but “who needs one?”

That’s a question I’m going to think much more seriously about as we define CorePilot’s next stage.

Absolutely — reliability and user control were things we paid close attention to while building CorePilot.

First, the assistant’s core is powered by four fully local models. They’re lightweight enough to run on relatively low-end systems. After installation, users can even see the models themselves and choose to remove or replace them.

Second, CorePilot provides a detailed Logs section where users can inspect what the assistant is doing, including very granular system activity. Nothing is meant to happen behind the scenes without leaving something you can inspect.

CorePilot also gives the user control over its online and offline capabilities. By default, it is fully offline and does not require a server connection. Users can even verify this themselves through Windows Task Manager and check whether CorePilot is sending or receiving network data.

Privacy, transparency, and user control are fundamental to how we’re building CorePilot. We want the user to know what the assistant is doing, where it’s running, and what it’s accessing.