# Custodian — Your Offline AI Assistant for Safe Desktop Automation > Source: > Published: 2026-10-19 06:14:28+00:00 [The video introduces the project and its workflow. We also created illustrative interface artwork to explain the intended user experience. Generated interface images are labelled as illustrations; the repository's execution records describe the tested behavior and remaining gaps.](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fac0kvnjjda0igdv2bl8c.png) Custodian is a desktop application. The current delivery target is a Windows installation with a local runtime and model. A downloadable public release still needs clean-machine and offline installation acceptance. [Explore the Custodian repository on GitHub](https://github.com/paarth293/Custodian) The code is licensed under **Apache 2.0**. Useful starting points are the desktop application in `apps/desktop`, the native libraries in `crates`, and the local inference service in `services/agent`. The [README](https://github.com/paarth293/Custodian/blob/main/README.md) explains the current scope. The [honesty register](https://github.com/paarth293/Custodian/blob/main/HONESTY.md) documents limitations, and the [documentation index](https://github.com/paarth293/Custodian/blob/main/docs/README.md) connects the plans, capability register, and verification records. We keep those distinctions visible because a feature can exist in a core library before it is fully connected, packaged, and accepted through the desktop application. Custodian combines **Qwen open-weight models**, local inference through **node-llama-cpp**, a **Tauri and React** desktop interface, and a **Rust** execution layer. The Node and TypeScript agent interprets requests and proposes bounded plans. Native code validates the plan and the permitted operation before acting. This separation is central to the design. Understanding a sentence does not itself grant authority over a file. A proposed workflow must resolve to registered capabilities, valid paths, and the applicable permissions. Unsupported requests need a clear refusal or clarification. For the example above, the supported execution path is: We are also working on standing permissions for bounded recurring work, so familiar tasks do not need the same interaction every time. The scope of the permission still matters: a reusable permission should describe what the assistant may actually do. Recovery shaped the implementation as much as the happy path. Task state, operation receipts, and restart behavior help the application distinguish a finished action from work that was interrupted. The goal is to make the outcome understandable even when a process fails. We evaluated Laya as an additional validation layer. It remains experimental and inactive in the accepted file-workflow path; we are not presenting that experiment as a deployed security control. The recorded local verification checkpoint includes **478 passing Rust tests, 144 JavaScript tests, and 72 Python tests**, with eight Rust tests intentionally ignored. These are scoped engineering results. Model factual quality, repeated optimized application runs, broader document and media support, and clean-machine installation remain open acceptance work. One lesson from the model evaluations was especially useful: an answer could satisfy a text-matching check while still making an incorrect claim. That is why we retain failed cases, inspect meaning, and keep actual operation verification separate from the model's explanation. Local execution is part of the product's usefulness. A team working with private project folders should be able to use supported workflows without sending its prompts and file context to a hosted model API. Once the runtime and model are installed, the offline path can operate on the user's machine. Open weights let us inspect and compare model choices against our own tasks, run inference locally, and investigate failures with repeatable cases. We can work on the prompts, decoding behavior, and planning constraints while keeping the execution contract under our control. The open-source application also lets another developer inspect what a permission allows, how a file operation is verified, and what recovery actually does. Those are useful properties for software that changes someone's working environment. There is a practical business benefit too: the offline path avoids a hosted model's per-request inference bill. Hardware, support, maintenance, and model performance still have costs. Our opportunity is to make a useful local workflow affordable and dependable enough that a small team would pay for the surrounding service. For Custodian, openness makes it possible to improve the assistant around real local tasks and let users examine the machinery that carries them out. Our first users are **us: me and my team members**. We use Custodian regularly while developing it, and our day-to-day use cases feed back into the next round of improvements. That gives the project a practical starting point. We are asking the assistant to help with the same local work we encounter while building it: finding files, choosing the right source and destination, checking the result, and recovering when an operation needs to be reversed. Supported workflows are the starting point; unfamiliar requests help expose what still needs work. The feedback loop is simple: use the app, identify the point of friction, turn it into a concrete case, improve the implementation, and check the result again. A confusing status message can matter as much as a missing capability when someone is deciding whether to trust the outcome. At this stage, our adoption evidence is internal team use. We have no paid-user result to report in this submission. The next commercial test is whether someone outside the development team can install Custodian, complete a recurring task, understand the outcome, and find enough value to pay for setup or support. We want the product to earn a place in a person's daily work. Our own team is where that process begins. We are entering the **overall Side Hustle challenge**, with local open-weight AI at the center of the product. No partner-specific prize category is claimed in this draft. **Paarth Gupta** · [@paarthgup001 on DEV](https://dev.to/paarthgup001) · [GitHub](https://github.com/paarth293) **Contact:** [paarthgup001@gmail.com](mailto:paarthgup001@gmail.com)