Nod from n8n Labs in Daily Use: What This Agent App Actually Requires

At the end of October, an agent app was already doing work on my machine while it officially did not exist yet. My screenshot from 27 October 2026 shows its chat: a dark interface, three task cards for that day, and the hint below that I could also connect Nod through Telegram or WhatsApp. The status line reads "Keep Nod running, so I can reply" while the laptop is closed and the machine at the office keeps working. On 10 November 2026, n8n Labs announced the app publicly; the first listed release, v0.6.1, carries that same date, and v0.6.2 followed on 11 November 2026. My own start therefore fell before the public release, in the phase ahead of it. I spell this out because nearly every number in this post comes from documentation, license text and release packages I fetched myself between 10 and 11 November 2026.

Nod is the agent app from n8n Labs for macOS 14 and Windows 11. It runs on your own machine inside a private virtual machine with its own browser, and it works there on files, commands and web pages. You pick the model provider freely: a cloud API or your own OpenAI-compatible server. The app is licensed under Apache 2.0 and costs nothing itself; the model provider bills its own usage separately.

A single-player tool next to a shared workflow

n8n draws the line against its own automation server in one sentence, verbatim: "A lot of what people build in n8n is multiplayer … Nod is for a single player." The automation server, hosted in-house by many companies for years, is a team instrument: shared workflows, roles, access rights, approvals. Nod is a program for one person, with its own workroom of files, shell and browser on exactly one machine. If you do not know the server yet, our post on self-hosted workflow automation with n8n explains the starting point.

For installation, the repo ships more than two installers: nod-arm64.dmg and nod-x64.dmg for the Mac, nod-Setup-x64.exe plus a runtime package and nod-install.ps1 for Windows. On top of that there is a nod-install.sh for running it on a headless server yourself. The desktop app is the most convenient path, then, yet it is not the only one.

The model hurdle: tool calls and 64,000 tokens

Nod works entirely through tools, and the documentation leaves no doubt about it: "A model that supports tool calls. Nod does all its work through tools, so a model without them can only chat." And further: "At least 64,000 tokens of context. Nod's instructions and tools take about 20,000 tokens before your first message. Most servers start with 4,096, and some cut Nod's instructions off without an error."

This is exactly the sentence where a retelling loses precision, so let me separate three things:

A model without tool support can answer in Nod but never act. That is by design, a missing capability of the model, a limitation of the pairing.
A server stuck on its factory 4,096 context cannot hold the full instruction set. Some servers then truncate silently, without an error message, and the agent no longer knows who it is supposed to be.
Below 65,536 tokens of context, Nod itself switches into a visibly reduced mode: shortened instructions, tool descriptions loaded one at a time. It keeps running with less equipment in that case, and it does not collapse into a mere chatbot shell.

Anyone attaching a local model therefore has to give the server two things: tool acceptance and enough context. Nod's own documentation names the flag example --enable-auto-tool-choice --tool-call-parser for vLLM.

Measuring our own lane against this hurdle

We run an in-house inference lane at our site: vLLM 0.32.0 on four cards, with LiteLLM as the gateway in front and four harnesses riding on it daily. On 11 November 2026 I measured read-only whether this lane clears both Nod hurdles. To get the model's answer I sent exactly one small probe request with a single arithmetic tool through the gateway.

Unit of measurement	Nod's requirement	Our lane, measured 11 Nov 2026	Verdict
Tool calls per probe (count)	mandatory, otherwise chat only	vLLM flags `--enable-auto-tool-choice --tool-call-parser qwen3_xml` active; probe answers with `finish_reason: tool_calls` and the arguments `{"a": 27, "b": 43}`	met
Context per request (tokens)	at least 64,000	`--max-model-len 220000`, KV cache in nvfp4	met
System load before the first message (tokens)	around 20,000 per the vendor	probe message with one tool: 330 prompt tokens; the 20,000 describe Nod's full tool list, a size that is not ours	note

The measured subject in all three rows: the model flashnext-hybrid on four RTX 5090 cards, routed through LiteLLM. Both hurdles Nod sets are cleared by our lane according to this measurement. The test is useful for anyone with a lane of their own, too: it is exactly two server flags and one context value, and both are checked in five minutes, before the first real job goes wrong.

The data path whenever Nod touches your apps

The honest question about a program like this is where the bytes travel. For sign-in and app connections, the documentation says verbatim: "By default, app requests and results pass through n8n's hosted connection service and Composio. Source installs can select a trusted connection service." Composio here is a separate third-party vendor for tool connections. Anyone who gives Nod a Gmail connection sends requests and results across those two external services. Operators who run Nod from source can register their own connection service according to the documentation; the desktop app uses the preset.

Two more data paths belong in the complete picture. The start page states openly that n8n receives usage data in addition to update checks, and that you can turn this off at any time in the settings. And: sign-in links deliberately never travel over the messenger channels; they always open the app's own browser, so a compromised messenger cannot reach your logins.

Taken together, the dividing line is clean. Model traffic goes to the provider you chose yourself, which means it stays in your building when the server is yours. App traffic goes over third-party services by default. Knowing both halves is the basis for any decision about whether this fits your house.

What sits under the hood

The stack the repo itself documents: TypeScript on Node.js 24, Fastify as the server, React for the interface, PostgreSQL with pg-boss for queues, the Pi agent runtime at the core, agent-browser for the browser, Electron as the wrapper; tools arrive via MCP, connections via Composio. I check license questions at the repo's license file, because the badge in the README would not count as evidence: the LICENSE file here contains the genuine Apache-2.0 text, and the GitHub API reports the same license.

The state of the repository metadata as of 11 November 2026: created on 25 September 2026, 260 stars, 35 forks, 6 open issues, last push on the same day. Six weeks between creation and public release is tight; we would not draw a verdict on product quality from that alone, still we are allowed to carry the question about maturity with us. As a vendor figure we did not recompute: n8n rates the long-term quality of the memory at 93.2 percent on the LongMemEval benchmark, and describes cost limits at which the agent checks back in once spending passes five dollars.

Who can start today and who should wait

For a Mac or Windows workstation where an agent should complete tasks across the day, Nod deserves a look, precisely because the execution stays in your building and the model is yours to pick. Two checks should be done before the first real assignment. First the model side: tool acceptance and at least 64,000 context, both measured; the table above shows how that is settled in five minutes for a lane of your own. Second the data-path side: which app connections ride the default relay, and does that match your privacy line? Whoever has clarified both and then wants to allow actions needs one more thing, a division of which actions an agent may carry out unattended. Our stages for that are laid out in the post on staged agent approvals and click fatigue. Everything we have written about AI in live operations comes together in the AI in production hub, and anyone who wants their own inference lane built for agents like these will find us through our IT services for local AI and model operations. My concrete closing advice: run Nod for a week on your own lane with everyday tasks and no app connections at all, check the telemetry in the settings, then add single connections one by one.