Getting Started with Nilux AI: From Install to First Task

Nilux AI is a terminal-native coding assistant. It lives in your shell as a thin CLI, but the real intelligence — the agent logic, system prompt, tool orchestration, and cross-session memory — runs on a server "brain" that the CLI talks to. You bring your project and your plain-language requests; Nilux reads and edits files, runs commands, searches the web, and connects to external tools, all from inside the terminal you already work in.

This guide walks you from an empty terminal to your first completed task. Budget about five minutes.

1. Install the CLI

Nilux is distributed as a global npm package. You'll need Node.js 18 or newer.

npm install -g @nilux-ai/code

That's the entire footprint on your machine. There's no heavy local runtime to configure — the client is intentionally thin, and everything that makes it smart lives on the server.

Confirm it's on your PATH:

nilux --help

2. Authenticate

Nilux ties usage to your account, so the first step is pairing the CLI. Authentication happens in your browser rather than by pasting secrets into the terminal. When you start the CLI unauthenticated, it opens a sign-in page (or shows you a link to open); you log in to your Nilux account and confirm the request, and the CLI receives its credentials and stores them on disk. After that first pairing you won't be asked again on the same machine.

3. Add a little balance and pick a model

Nilux is pure pay-per-use. There's no subscription and no per-seat fee: you top up a balance and pay only for the tokens you actually consume. New accounts start at $0, so add a small amount before your first run — even a couple of dollars is plenty to explore, since a typical task costs a fraction of a cent to a few cents.

You choose which coding model handles your requests with /model inside a session. There are exactly two models: Standard (fast and economical — great for everyday edits, refactors, and questions) and Pro (stronger reasoning for gnarlier, multi-step problems). Start on Standard, switch to Pro for a hard task, then switch back. Your remaining balance updates as you go.

4. Run nilux and give it a first task

Change into a real project directory and launch a session:

cd ~/code/my-project
nilux

Nilux picks up the project context automatically. Describe what you want in plain English — no special syntax:

Add a --verbose flag to the CLI that prints each step as it runs.

Nilux explores the relevant files, reasons about the change, and comes back with a proposed edit rather than silently rewriting your code.

5. Review the proposed diff — approve or reject

This is what makes Nilux safe on real code: it shows you the change before it happens. When Nilux wants to modify a file, it presents a diff and waits. You can approve it, reject it if the approach is wrong, or redirect — reject and add a note about what you actually want, and Nilux revises. Nothing is written to disk until you agree.

6. Approve a command run

Real tasks need commands run too — installing a dependency, running tests, building. When Nilux wants to run something, it asks first and shows you the exact command. Approve it and Nilux executes it locally, reads the output, and continues. Because the command runs on your side, the "brain" never touches your shell directly; it can only ask, and you decide.

7. Slash commands and permission modes worth knowing

A few slash commands go a long way. Beyond /model, you can check your balance and start a fresh conversation from inside a session.

Approval behavior is governed by four permission modes:

• default — asks before edits and before commands.
• accept-edits — auto-approves file edits, still asks before commands.
• plan — proposes a full plan and touches no code until you accept it.
• auto — runs without stopping to ask; fast, and best kept for well-scoped, low-risk work you're actively supervising.

Plan mode deserves a callout. Before a big or ambiguous change, it lays out its intended steps for you to approve, and no files are touched until you're happy with the approach. A good rhythm for anything bigger than a one-file tweak: use plan mode to agree on the approach, then default or accept-edits to execute, then review the key diffs.

8. Give it a project memory

Nilux already carries cross-session project memory — start a session tomorrow in the same project and it remembers the context. You can sharpen that by leaving a short instructions file at the root of your project describing the things you'd tell a new teammate:

Project notes for Nilux
Package manager: pnpm (never npm)
Run tests with: pnpm test
Source lives in src/, tests alongside as *.test.ts
Conventional commits; never push to main directly

Keep it short and factual. Nilux reads context like this at the start of a session, so it stops re-discovering your setup every time.

Where to go next

You now have the full loop: install, authenticate, top up, ask, review, approve. When you're ready to go deeper, explore configuration (session defaults and behavior), the full tool set (file, command, and web capabilities), and MCP for connecting external tools and data sources — a first-class part of how Nilux talks to the systems you already use.

Start small: give Nilux a real task in a real project, review its first diff, and approve it. Questions? Reach the team at [email protected].