AI coding assistants have gone from novelty to daily driver in a remarkably short time. Many developers now keep one open in a terminal tab or an editor pane, delegating the tedious parts of the job and reaching for it when they're stuck. That shift is real, and it isn't reversing.
But as these tools matured, a set of quiet frustrations got baked into how they work — the kind you stop noticing because you've learned to work around them. We built Nilux AI because we didn't want to keep working around them.
The problems we kept running into
Three things bothered us about the current generation of AI coding tools.
They forget your project. You spend a session teaching the assistant the shape of your codebase — the conventions, the decisions, why a thing is done the way it is. Then you close the terminal. Come back tomorrow and it's a blank slate again: you re-explain the same context, re-establish the same ground rules, before you can get any real work done. The assistant is stateless by design, so the burden of continuity falls entirely on you. On a project you return to daily, that tax adds up fast.
The pricing rarely matches what you actually use. Flat monthly subscriptions and per-seat plans are convenient to buy and easy to forecast — but they systematically overcharge the majority of developers. Usage on real teams is uneven. A few people run the assistant constantly; most use it in bursts, some barely at all. A flat fee means the light and moderate users subsidize the heavy ones, and everyone pays for a ceiling they'll never hit. Worse, the actual cost drivers — context size, token throughput — are invisible to you. You get a bill, not a breakdown.
The help lives outside your workflow. A lot of real development happens in the terminal — inside SSH sessions, in tmux panes, on remote boxes. Yet plenty of AI tooling keeps pulling you out of it: a GUI to open, a web dashboard to live in, an "open in your browser to continue." Every context switch is friction, and friction is where flow dies. If the work is in the terminal, the assistant should be too.
Each of these is understandable from a vendor's point of view. A stateless client is simpler to build. Subscriptions smooth revenue. A polished GUI demos well. But none of them are actually good for the developer doing the work.
The design decision at the center of Nilux
Working on this, we kept coming back to a single observation: the hard, valuable part of a coding assistant isn't the raw model. It's the orchestration around it — the system prompt, how tools are defined and called, how a long session's context is managed before it overflows, how the assistant decides what's worth remembering across days of work. That's where a coding assistant is actually good or bad. And it's the part that's genuinely hard to get right.
So we built Nilux around that idea. The "brain" lives on the server: agent logic, the system prompt, tool orchestration, context management, the compaction that keeps long sessions coherent, and the cross-session memory. The thing you install is a thin client:
npm install -g @nilux-ai/codeThat client handles what has to be local — reading and writing files, running commands, executing tools, showing you diffs and asking for approval, speaking MCP. Everything intelligent happens on the server and streams down to your terminal. Keeping the orchestration server-side is what lets us keep improving it — the prompt, the tool-calling, the memory — without shipping you a new client every time, and it's what makes the next two things possible.
Memory that survives the session
This is the piece we cared about most, because it's the frustration we felt most. Nilux carries project memory across sessions — decisions, conventions, the shape of the codebase — scoped to each project. Close the terminal, come back tomorrow, and the assistant picks up where you left off instead of asking you to re-explain everything. Because the memory and the orchestration both live server-side, that continuity is maintained for you rather than reconstructed by hand at the start of every session.
That memory is the foundation for the rest of how Nilux works. Subagents and multi-agent workflows let you delegate larger tasks and have them coordinate. First-class MCP support lets you wire in your own tools and data sources. Four permission modes and a dedicated plan mode keep you in control of what the assistant is allowed to do and let it think through an approach before it touches anything. Together it behaves less like a stateless chatbot and more like something that knows your work.
Pricing that matches what you run
Nilux is pure pay-per-use. No subscriptions, no seats, no monthly minimum. You top up a balance and pay for the tokens you actually consume — nothing when you're not working. New accounts start at $0, so you can try it before you've spent anything. Light users pay little. Heavy users pay for exactly what they use. Nobody subsidizes anybody, and the cost is grounded in real usage instead of an opaque flat fee.
We also spend real engineering effort keeping the per-token cost down. KV-cache optimization keeps the cacheable prefix of a conversation stable, so it can be reused across turns instead of reprocessed from scratch — and that saving lands on your bill, not just ours. For the models themselves we keep it simple: two clearly-scoped tiers you pick between with /model — Standard for everyday coding and Pro for heavier reasoning — so you can dial the horsepower up or down per task without wading through a menu of options.
Terminal-native, on purpose
There's no GUI to open, no web dashboard you have to live in. Nilux runs in the terminal, which is where a lot of real development already happens — inside SSH sessions, in tmux panes, on remote boxes. The thin client keeps that footprint small and the workflow close to the metal, so reaching for the assistant doesn't mean leaving the environment you were already working in.
What this means for you
Strip away the architecture talk and it's straightforward. The assistant remembers your project instead of making you re-teach it every day. You pay for what you actually run, not a flat fee sized for someone else's usage. And it lives in the terminal, where the work already is. The part that makes a coding assistant genuinely good — the orchestration and the memory — is the part we put our effort into, running on the server and delivered through a client thin enough to stay out of your way.
An honest invitation
Nilux AI is early. We're a small team at Nilux Labs, and we'd rather tell you that plainly than dress it up with numbers we haven't earned. What we can stand behind is the design — server-side orchestration, memory that persists, pay-per-use, terminal-native — because every piece of it exists to take a real, recurring frustration off the developer's plate. If that resonates, the fastest way to judge it is to run it:
npm install -g @nilux-ai/codeOpen it in a project you know well, and see whether it fits the way you actually work. If something's rough or missing, tell us — at this stage that feedback genuinely shapes the product. Reach us at [email protected].