A desktop agent becomes risky the moment a useful answer can turn into a file edit, command, upload, or browser action. Nerva is an upcoming project built around keeping that boundary visible: an assistant should do useful work without asking you to give up control of your files, credentials, or decisions.

That makes Nerva different from a chat window that only returns text. The planned product can read a codebase, inspect a local document, propose a change, ask for permission, run an approved tool, and show what happened. The important part is the control loop around the model.

This is a product design in progress, not a claim that every feature below is already released. The goal of this article is to explain the direction clearly and show why local-first matters for an agent that can take actions.

The short answer

Nerva is planned as a local-first, provider-agnostic desktop agent for real computer work.

  • Local-first: local models and local context are the default path where practical.
  • Provider-agnostic: users can connect compatible APIs instead of being trapped in one model vendor.
  • Permissioned: the agent must ask before sensitive or consequential actions.
  • Auditable: plans, tool calls, results, retries, and verification should be visible.
  • Unlimited in product usage: the app is intended to avoid an artificial message quota. Third-party API limits, model pricing, device hardware, and local compute still apply.

    • That last distinction matters. “Unlimited” can describe how Nerva is licensed or how many tasks the app lets you start. It cannot remove an API provider's rate limit, subscription cost, token limit, or terms.

    Why a local-first agent is different from a chatbot

    A chatbot usually receives a prompt and returns an answer. An agent has a larger responsibility because it may read a repository, edit a file, execute a command, or operate a browser.

    The risk is not only that the model gives a wrong answer. The risk is that a plausible answer becomes an unreviewed action. A model might select the wrong directory, expose a secret in a log, overwrite a user's work, or treat an untrusted README as an instruction.

    Nerva's planned boundary is therefore:

    user request
    -> understand and plan
    -> permission check
    -> approved tool call
    -> observe the result
    -> verify the outcome
    -> show evidence to the user

    The model proposes. The permission layer decides. The tool gateway performs only an allowed operation. The user gets a result that can be checked instead of a confident sentence with no trail.

    What local-first protects

    Local-first does not mean that every byte must stay on the device forever. It means the product starts from the question: does this task need to leave the machine?

    For example, summarizing a local Markdown file may be possible with a local model. Fixing a TypeScript error in a repository may need only the files involved in the error. A cloud model might be useful for a difficult architecture discussion, but the user should be able to see what context will be sent before that happens.

    The planned design treats these as separate choices:

    | Choice | What it controls | | --- | --- | | Local only | No provider API is used for the task | | Ask before cloud | The user approves the context before sending it | | Redacted cloud | Secrets and selected paths are removed first | | Provider API | A configured remote model handles the approved request |

    This is more useful than a vague privacy badge. A serious tool should show the boundary at the moment it matters.

    Nerva's useful work surface

    The product is aimed at tasks that benefit from context and verification:

  • Explore a repository and explain how its modules connect.
  • Draft a small code change and show the exact diff.
  • Run a test or build after the user approves it.
  • Inspect logs and connect an error to the relevant source file.
  • Organize notes, PDFs, DOCX files, spreadsheets, or presentations.
  • Work with browser content while keeping the action visible.
  • Create a checkpoint before a risky edit and make rollback possible.

    • This is why the product should not be framed as an autocomplete tool. Autocomplete helps write the next line. Nerva is intended to help complete a bounded task and prove what changed.

    What “unlimited” should mean

    The word is attractive, but it needs a precise promise. A responsible version of the promise is:

    > Nerva does not impose a small message quota on the user's workflow. Users remain responsible for local compute, connected provider pricing, API quotas, and the resources their tasks consume.

    That model is better for a desktop agent than hiding the real cost behind a fake unlimited badge. A local model may have no per-request bill, but it still uses memory, battery, storage, and GPU time. A provider API may be faster or more capable, but it may charge by tokens or enforce rate limits.

    The product is built around trust

    The most important Nerva feature is not a model name. It is the ability to answer four questions after a task:

    1. What did the agent understand? 2. What context did it use? 3. Which actions did it request and which were approved? 4. What evidence shows that the result is correct?

    That is the standard I use when writing about backend systems too: an implementation is not finished because a tool returned successfully. It is finished when the result is observed, tested, and explained.

    Who Nerva is for

    Nerva is designed for developers, students, researchers, and technical teams who want an agent that works with their existing environment without turning every task into a trip to a hosted dashboard.

    It is especially useful for people who care about local files, private repositories, repeatable workflows, and an audit trail. It is not meant to replace judgment. It should make good judgment easier by exposing the plan, the boundary, and the evidence.

    The honest status

    Nerva is an upcoming project. The local-first architecture, provider routing, permission engine, tool gateway, and audit-first workflow are the direction being designed. The final model support, platform coverage, performance, and pricing will depend on implementation and testing.

    That honesty is part of the product promise. A trustworthy agent should not pretend that a roadmap is a shipped feature. It should show what is available, what is being tested, and what still needs proof.

    For a practical comparison, read how agentic coding tools work and where they fail. For the next technical layer, continue with how Nerva can route work across local and cloud AI models.