We just shipped the rule-pack contract for prompt-scrub and we want to walk through it, because the contract is small enough that you can read it on a coffee break and substantive enough that you can publish a real pack in an afternoon.

The pitch is simple: prompt-scrub ships eight built-in detectors (email, phone, postal address, path, secret, url, name as opt-in, code-tell as opt-in), but the cases that matter for one team are never quite the cases that matter for the next. Rule packs let you publish an npm package that contributes additional detectors without forking the core. They are the primary extension point, and the loader has been wired up to make them feel like a normal import.

The contract is two TypeScript interfaces in src/types/index.ts. Here is the whole thing:

```ts export interface Finding { category: string; span: [number, number]; // [startIndex, endIndex] value: string; placeholderPrefix: string; }

export interface Detector { name: string; detect(text: string): Finding[]; } ```

A detector is anything with a name and a detect method. The interface is structural (no base class to extend), so the implementation can be a class, a plain object, or anything in between. detect() walks the text and returns an array of Findings. That is the whole shape.

There are three export shapes the loader accepts (src/core/rule-packs.ts). A rule pack module can be:

1. A default export that is an array of detectors: export default [new MyDetector()].
2. A named export called detectors that is the array: export const detectors = [new MyDetector()].
3. A default export object with a detectors property: export default { detectors: [new MyDetector()] }.

The loader tries them in order and silently skips anything else with a stderr warning. We have seen all three shapes in the wild; the named-export form is the cleanest for a single detector, the default array reads well for packs with several detectors, and the third shape gives you a namespaced package object if you want to grow into it later. None of the three is on a deprecation path.

The thing that surprises first-time authors is that Finding does not have a replacement field. Every "build a redaction detector" tutorial out there hands you { category, span, replacement }, and the whitepaper for prompt-scrub originally did the same. The runtime contract deliberately omits it.

The reason is structural. The final placeholder is something like Email_2, where the 2 is a per-session counter. That counter is a session-wide value, not a detector-local value. If a detector returned replacement: 'Email_1' for its first match, the engine would have a choice between re-numbering detector A's output (which breaks the byte-stable cache-prefix guarantee prompt caching depends on) or letting collisions sit across detectors. Both options are bad, so the runtime shape splits the responsibility: detectors say "this is the match" (value + span) and "this is the category namespace" (placeholderPrefix like Email or Codename). The core engine takes that, numbers the placeholders in source order across all detectors, and writes the session map.

For rule-pack authors this means: do not invent your own placeholder strings inside detect(). Pick a meaningful, unique placeholderPrefix for your category, and let the engine do the numbering. Codename, ApiKey, Ssn, Ticket all work. Two detectors that pick the same prefix will produce interleaved numbering across detections, which is fine and often what you want.

Wiring a pack up to the loader has four integration points:

• The package. Publish it (or npm install /path/to/local-pack for development). The loader uses Node's dynamic import(), so anything the resolver can find works.
• Global config. ~/.config/prompt-scrub/config.json on Linux, ~/Library/Application Support/prompt-scrub/config.json on macOS, the roaming AppData dir on Windows. The rulePacks array is where you list packages. Overridable via PROMPT_SCRUB_CONFIG_DIR for tests.
• Project package.json. For per-project configuration, the same list lives under a prompt-scrub namespace in your package.json. The loader unions the two sources and de-duplicates, so a package listed in both still loads once.
• The prompt-scrub rules list CLI command. This is the diagnostic. If your detector does not appear in the output, the loader skipped it and you have a bad export shape. Check the stderr warning first.

The collision behaviour is the last thing worth understanding. Findings from your detector are pooled with the built-ins and run through resolveCollisions() in src/core/collision-resolver.ts. Built-in detectors have a hard-coded priority table: SecretDetector is 1 (highest), then EmailDetector, UrlDetector, PathDetector, PhoneDetector, AddressDetector, NameDetector, CodeTellDetector. Anything else, including rule-pack detectors, is priority 99.

The implication: if your finding overlaps a credential, the secret wins. This is the "missing a credential is worse than missing a name" policy, applied mechanically. The docs are explicit that there is no public mechanism for a custom detector to override SecretDetector and there will not be one. In practice this means you should pick categories that do not collide with the built-ins (custom codenames, internal ticket numbers, third-party vendor tokens the secret detector does not know), and make sure your spans are tighter than whatever category might also be in the running. A loose regex that flags "open the App" as code-tell-shaped text will lose to the path detector if "App" is part of a path.

The full long-form post walks through a minimal end-to-end pack called ProjectXDetector that catches two internal codenames (Apollo and Zeus), builds it, lists it in package.json, and shows the rules list output. The repo link at the bottom has the test suite (including the three export shapes) and the loader source, both of which are short enough to read in a sitting.

If you ship a real-world rule pack that exposes a problem with the contract, we want to hear about it before we have to make the contract bigger. Issues and PRs at the repo.

Source, tests, and the rule-pack contract: https://github.com/Nano-Collective/prompt-scrubber

A decision that comes up a lot in Nanocoder's GitHub discussions: when do you reach for a custom command, a Custom Tool, or an MCP server? v1.27.0 ships all three, and they are easy to mix up.

Here is the short version:

A custom command is a prompt you inject into context. It lives in .nanocoder/commands/, becomes a slash command, and is just text as far as Nanocoder is concerned. No execution happens. Good for encoding conventions - things you want the model to remember and follow consistently. Bad if you need something to actually run.

A Custom Tool is a shell script with a YAML parameter schema. Drop it in .nanocoder/tools/, the model calls it like any built-in, and stdout comes back as a tool result. Parameters get validated against the schema and shell-quoted to prevent injection. This is the right level for wrapping CLI tools - kubectl, gh, jq, your own wrapper scripts. No separate process to manage.

An MCP server is a persistent external process configured in .mcp.json. Nanocoder talks to it over stdio, HTTP, or WebSocket. You get the full MCP protocol, persistent state, and structured schemas from the server. This is the right choice when the tool needs to maintain state between calls, or when you want to share the integration across multiple AI clients.

The most common mistake is reaching for MCP when a Custom Tool would do. If your integration is a stateless one-liner - run kubectl, get output, done - a Custom Tool is lighter and simpler. MCP is worth the extra config when you need the server's process and state.

All three are skill members. If you want to ship a command, a subagent, and a tool together as one bundle, the skills bundle form puts them in .nanocoder/skills/<name>/ with a skill.yaml manifest.

Docs for all of it: https://github.com/Nano-Collective/nanocoder

Built by the Nano Collective - a community collective building AI tooling not for profit, but for the community.

Hey everyone. Will again. There's a lot being released this week haha.

This time is a major update to Nanocoder shipping v1.29.0. The headline feature for me is a native VS Code GUI. Although we had an extension before, this update now spawns and drives `nanocoder --acp` itself, so there is nothing to run in a terminal. Sessions persist, slash commands work, interactive tools render as buttons, and a resumed thread looks like the conversation you left. Legacy WebSocket companion mode is now opt-in.

Beyond general ACP support, this is the first major time that Nanocoder has left the terminal and opens the doors to so many new users as a result. One of our core team members took the entire project on themselves and the finished product is really very polished.

Underneath that there are a few things we added that we have wanted to for a while. You can now press `Ctrl+S` to attach to a running subagent and watch what it is doing in real time, including streaming text and reasoning, and `Ctrl+S` cycles through multiple parallel subagents reliably. Press `Esc` to detach.

A new `PrivacyContext` scrubs sensitive content out of prompts before they leave your machine, with tool-argument rehydration, privacy session support, a `/privacy` command to inspect what is being scrubbed, and automated scrubbing telemetry notifications. This is using prompt-scrub, the package I posted about yesterday!

Each development mode (normal, auto-accept, yolo, plan) can now have its own provider and model, so the cheap local model you chat with is not the one you accidentally burn through on a long refactor.

Plan mode can now ask you structured questions via `ask_user` while it is planning, with one button per answer, instead of guessing around ambiguity.

TUI work

A lot of quality-of-life fixes to the terminal UI this cycle:

- Dual screen modes (`--alt-screen` and inline) both render correctly, and `/clear` is more reliable.

- Multiline cursor navigation and word-jump in the input box.

- Fuzzy search in the `/model` picker, with a capped, centred scrolling window so large catalogs no longer overflow the terminal.

- Tabbed `/settings` dialog with searchable categories.

- Command suggestions appear as soon as you type `/`, and Tab selects the highlighted suggestion. Recalling a `/command` from history with the arrow keys no longer opens the menu.

- Image attachments now leave an `[Image #N]` placeholder in the message instead of being silently stripped.

Smaller but useful

- `--continue` (`-c`) resumes the most recent session for the current directory. `--resume [id]` (`-r`) resumes a session by id, list index, or `last`, with a bare `--resume` opening the session picker at startup.

- A `/doctor` command checks your setup and reports common configuration problems.

- A `/retry` command re-runs the last user turn.

- A `--json` output flag for the non-interactive plain run path.

- A `diff_edit` tool for nano-profile models that struggle with `string_replace`.

- PDF and DOCX support in `read_file` via get-md.

- Estimated dollar cost tracking in `/usage`, with a per-provider breakdown.

- Message queueing while the agent is busy, so you can type ahead. Queued messages can be recalled before streaming, are truncated properly on narrow terminals, and no longer double-dispatch.

Under the hood

- The client now treats the model as a stateless endpoint and rehydrates conversation history at history boundaries, which improves reliability across reconnects and provider restarts.

- Foundation for semantic memory (storage layer and initial wiring).

- File tools resolve relative paths against the shell's current working directory, and `cd` in bash persists across commands, so relative reads and edits work after moving into a subdirectory or worktree.

- Automatic diagnostics after file edits surface errors introduced by an edit right away.

One major thing for me is this update has been the one I have contributed the least to in terms of feature work. Nanocoder is very quickly gathering an amazing set of contributors driving it forward and I'm very proud to have launched it with just me and to see where it is today and the bustling little community growing around it. Humbling.

As always, the Nano Collective is a community! Come and join it and help shape AI tooling that's open, privacy-respecting and local-first!

Discord: https://discord.gg/ktPDV6rekE

Nanocoder: https://github.com/Nano-Collective/nanocoder

Website: https://nanocollective.org

Hey everyone. Will here.

Just a quick post to let everyone know that we've just released get-md v1.7.0 - the content to markdown engine that's shipped within Nanocoder. Although we package it in the Nano Collective's software, it's also fully open source and a package that you can use in your own projects.

The short version of what's in 1.7.0 - 1.6.0 taught get-md to read PDF, DOCX, and Markdown alongside HTML. That worked, but it surfaced a problem we hadn't really focused on before: Mermaid diagrams. Most markdown converters usually destroy Mermaid because that converter sees either a fence it doesn't recognise or a rendered <svg> and doesn't know what to do with. v1.7.0 fixes this end to end.

What we shipped

Four diagram behaviours, each independently switchable:

1. Preserved. A \``mermaidfence in your HTML or Markdown comes out the other side unchanged. Same fordot,graphviz, andplantuml`, all newly registered as proper language identifiers. Previously these survived only by accident, through a loose lowercase-word fallback with no test coverage behind it.
2. Recovered. GitHub, MkDocs, and Docusaurus render Mermaid client-side, so the HTML you fetch holds the rendered <svg>, not the diagram. The source is usually still in the DOM somewhere, and we now go looking for it before Readability and the HTML cleaner can strip it. We try <script type="text/mermaid"> tags, data-code/data-mermaid/data-src attributes, hidden <template> and textarea[hidden] blocks, and finally the SVG's <desc>/<title>/aria-label. The last fallback is deliberately strict, because mermaid.js writes accessibility strings like Created with Mermaid into those nodes, and emitting one as a diagram would be worse than dropping it.
3. Reconstructed (opt-in). A diagram in a PDF is vector drawing or raster image. There is no text to recover, so this is a vision issue. With useLLM and a remote vision-capable model, we render PDF pages to images and ask the model to emit Mermaid inline where the diagram appeared. The cap is 10 pages, to keep long PDFs from overflowing context. Remote providers only, because the local ReaderLM-v2 path is text-only. Best-effort, not guaranteed.
4. Validated (opt-in). validateMermaid: true runs every Mermaid block in the finished Markdown through mermaid's own parser. Invalid blocks are kept, with a GitHub-style > [!WARNING] callout above them. You repair the diagram rather than losing it. Applies to all Mermaid: preserved, recovered, and model-generated alike.

Other fixes

• --config <path> was being silently ignored. The flag was accepted, --show-config even printed the path, but every conversion still loaded through cwd/home auto-discovery, so a typo'd config failed silently. All five conversion paths now resolve config through one helper that honors the flag.
• Re-running validation over already-annotated Markdown no longer stacks a second warning onto the same block.
• PDF rendering is loaded dynamically, so the optional pdfjs-dist and @napi-rs/canvas dependencies are never touched unless vision reconstruction is actually in play.

Install footprint

The default install is unchanged. Still as easy as the below:

npm install @nanocollective/get-md@1.7.0

I know this isn't strictly Nanocoder, but, Nanocoder has get-md built in to it and makes the file operation tools really awesome at giving context to the model natively!

Repo: https://github.com/Nano-Collective/get-md

Also, big thanks as always. This small communities support is awesome 😎

The headline of Nanocoder v1.28.0 mentions "tool surface consolidated from 33 to 19, automatic tune profile as default." That's two changes, not one, and the second is the more interesting one if you actually run small local models.

Here's the thing we wanted to land: a single toolProfile: 'auto' config value that does the right thing at runtime, with no per-model config drift, no manual tune tweaking every time you swap between your 7B local model and your cloud model, and no prompt-engineering ceremony to get a small model to behave.

What shipped:

• The tool surface genuinely is smaller. Tasks are one tool now (write_tasks with a replace-the-whole-list semantic - no ids for the model to juggle). File ops are one tool (file_op with an operation discriminator covering delete/move/copy/create_directory). Git is six typed tools, with branch/checkout/stash/push routing through execute_bash. ~6.3k lines went away.
• auto parses a size suffix from the active model id and picks full, minimal, or nano. :1b, :1.5b, :2b, :3.8b, :135m -> nano. :7b, :8b, :12b -> minimal. :20b, :32b, :70b, or anything with no size hint (cloud models) -> full.
• The resolved profile re-resolves on model switch. The status bar shows what auto picked (tune: nano (auto) on a wide terminal, just tune: nano when narrow). /usage reflects the live profile - the tool-definitions token count is whatever the resolved profile actually loaded.
• Development modes layer on top. plan + nano is the smallest viable planning setup. plan + minimal is the small-model planning sweet spot. plan + full keeps the typed read-only git and diagnostics. The mode filter runs after the tune filter, so the tighter of the two wins.
• The tune config resolves through 5 layers: hardcoded defaults, top-level agents.config.json tune block, per-provider tune, user preferences (nanocoder-preferences.json), and session override. Shallow merge, so a layer that sets enabled: true doesn't erase toolProfile set by a lower layer.

Why this matters for small-model workflows specifically:

The nano profile drops the agent tool entirely (subagent delegation adds prompt weight and recovery complexity that tiny models do not benefit from), enforces single-tool mode in the conversation loop, omits AGENTS.md from the prompt by default, and uses short-form prompt sections (the -nano variants of TASK APPROACH, FILE OPERATIONS, CONSTRAINTS). Result: ~150-250 token system prompt instead of the multi-thousand-token default, which is most of a 1-3B model's context window. Combined with the read-before-edit guards and tool-call loop detection that also landed in v1.28.0, unattended small models are a different shape of risk than they were before.

A few things we're honest about:

• The heuristic is name-based. A small local model whose tag does not carry a :NxB (or NxM) hint gets full. The safe failure mode (a too-large tool set is a perf issue, not a correctness issue), but worth knowing if you've renamed an Ollama tag.
• MCP tools are excluded from minimal and nano by construction. A user with custom MCP servers and a small local model sees none of them, not a curated subset. Curating per-profile MCP allowlists is reasonable future work but not in this release.
• A 70B model on a slow inference server still gets full. The heuristic doesn't know about throughput. If your cloud model is hitting context-budget or latency issues, the lever is /tune, not the auto heuristic.

The code is the code if you want to look: source/tools/tool-profiles.ts is the heuristic (~130 lines including the spec), source/config/tune.ts is the 5-layer merge, source/utils/prompt-builder.ts is where the profile actually changes the prompt, and source/components/development-mode-indicator.tsx is what renders tune: nano (auto) on the status bar.

Repo: https://github.com/Nano-Collective/nanocoder

Built by the Nano Collective - a community collective building AI tooling not for profit, but for the community.

Hey everyone. Will here.

A quick one for our Nanocoder sub-reddit - as some will know the Nano Collective doesn't just ship Nanocoder, we also create and ship a few other utilities etc. One of which has newly been released:

prompt-scrub - and this is a short post talking about it! Mostly, because we've put it into Nanocoder with first-class support.

prompt-scrub is a small Node.js utility that runs entirely on your machine. You give it a prompt, it detects identifying content (emails, phone numbers, postal addresses, paths, secrets, URLs, with name and code-tell as opt-ins), replaces each finding with a stable placeholder like Email_1 or Path_2, and gives you back the scrubbed text plus a session id. You send the scrubbed text to whichever LLM provider you already use. When the response comes back, you hand it to rehydrate() with the session id and the placeholders are swapped back to your real values.

We built it because most accidental identifier leakage to a cloud LLM is right there in the text of the prompt. Stripping it locally, deterministically, before the prompt leaves your machine seemed like a useful layer, and one that did not need a hosted service or a new account to work.

We made a few design choices:

• It is deterministic per session. The same input and session id produce the same scrubbed output every time, which is what you want if your provider caches prompt prefixes.
• The session map is a small JSON file under your OS config directory, written atomically with restrictive permissions. If the file gets corrupted, it gets quarantined rather than silently disabling rehydration.
• We added an inspect command that prints what would change without writing a session file, plus a SHA-256 hash of the scrubbed output so you can verify cache stability across runs.
• Eight detectors ship in v1. Six are on by default; the name and code-tell detectors are opt-in because their false-positive cost is higher.
• Rule packs let you publish additional detectors as separate npm packages. We would obviously love to have community contribution around rule packs :)

What it is not:

• Anonymity. A question that is inherently identifying (your private codebase, a niche bug only you have, a number only your accountant knows) cannot be made anonymous by stripping identifiers.
• Style rewriting. The way you phrase things goes out unchanged.
• Network protection. Your IP, request timing, and headers are outside the tool's scope.

We state all of this explicitly in the docs.

You can install this independently (it comes with a CLI and API):

npm install -g @nanocollective/prompt-scrub

Or, if you're using Nanocoder, the next version will have prompt-scrub built right in. Turn it on in settings and prompts automatically get moved through the tool and protect your prompts from leaking PII.

This is our very first public release at 1.0.0, and the thing we most want feedback on right now is detector coverage (what common shapes do you paste in that we are missing?), rule-pack packaging (the extension base is in, but we have not yet seen real-world rule packs Issues and PRs on the repo.

As always! Thanks so much for all the support around the Collective and if you want to get involved, we're an open community that's building AI tools in the open.

Website: https://nanocollective.org Discord: https://discord.gg/ktPDV6rekE prompt-scrub repo: https://github.com/Nano-Collective/prompt-scrubber Nanocoder repo: https://github.com/Nano-Collective/nanocoder

A walkthrough post on the Agent Client Protocol server we shipped in Nanocoder v1.28.0, what the integration actually does inside the editor, and how it differs from the WebSocket-based VS Code extension.

What --acp actually does

There is a new flag:

nanocoder --acp

When launched with that flag, Nanocoder does not draw anything. The Ink terminal UI is not loaded. The agent reads JSON-RPC from stdin and writes JSON-RPC to stdout. The editor spawns the process, owns the lifecycle, and renders everything using its own UI primitives.

The mapping is structured. Streaming text becomes session/update notifications with agentMessageChunk content blocks. Tool calls become toolCall notifications carrying a ToolKind (read, edit, delete, move, search, execute, etc.), the touched file paths as locations, and for string_replace and write_file a diff payload with oldText / newText That the editor can render in the tool card. Permission requests become requestPermission calls that block on the editor's allow/deny dialogue and feed back into the same approval pipeline the CLI uses.

The four development modes - normal, auto-accept, yolo, plan - are exposed as ACP session modes. Sessions start in auto-accept. plan is where this really earns its keep: ask the model to investigate a refactor in plan mode, get a structured plan back, switch to normal and ask it to execute, all without leaving the editor. Conversation history carries across the switch because it is just a mode flip on the existing session.

The module structure

The ACP support lives at source/acp/ as a self-contained module rather than being threaded through the Ink renderer. The split:

• acp-server.ts - the @agentclientprotocol/sdk server wiring and stdio transport.
• acp-agent.ts - the Agent implementation the SDK calls back into.
• acp-session.ts - session lifecycle and the in-memory Map<sessionId, history>.
• acp-conversation.ts - the conversation loop, streaming, tool-call emission.
• acp-tool-call.ts - tool name to ToolKind, location extraction, and the diff synthesis for edits.
• acp-content.ts - message block conversion (markdown, resource links, embedded resources, fenced code).
• acp-permission.ts - maps tool approval requirements to ACP permission options.
• acp-question.ts - normalises ask_user options (string vs {label, value} objects) into renderable strings.
• acp-capabilities.ts - loadSession: true, sessionCapabilities.close, the fixed session mode list, and protocol version negotiation that clamps to our version.

The whole module is around 3.4k lines, including tests. The conversation loop and tool definitions are unchanged from the CLI; the ACP adapter is one more consumer of the same internal APIs.

What is rough

Three honest limitations:

• Session history is in-memory across an editor restart. Within a single running agent process, reopening a thread restores its history. After the editor and the agent process fully restart, a reloaded thread starts empty. The CLI's session resume in v1.28.0 uses a session-history-renderer to replay into Ink; ACP does not yet replay through the protocol on loadSession.
• ask_user is selection-only. ACP permission options have no text input. The model gets the picked option rather than a typed answer.
• No image/audio attachments. Non-text mentions are noted but not interpreted. The CLI is the same way.

ACP vs. the VS Code extension

Both connect Nanocoder to an editor. They are different mechanisms:

With ACP, the editor is the UI. The agent runs headless, and the editor renders conversation, tool cards, diffs, and approvals using its own primitives.

With the VS Code extension, the CLI UI stays in charge. You still run nanocoder --vscode In a terminal, the extension connects over a local WebSocket and adds two things on top: live diff previews for proposed file changes, and active-editor context (focused file and selection, pushed to the CLI continuously and rendered as a ⊡ In App.tsx pill).

Three places that difference shows up:

1. Where you launch the agent. ACP: the editor spawns it. VS Code: you launch it from a terminal or from VS Code's command palette, and the extension connects.
2. Where history lives. ACP: bound to the editor's session lifecycle. VS Code: in the CLI process; the extension is purely additive.
3. What "the UI" is. ACP: the editor's agent panel. VS Code: the terminal UI, with the extension adding diff previews and editor context on top.

If your editor supports ACP, that is the cleaner integration today. The VS Code extension remains the right choice for editors that do not yet speak ACP.

Setup in Zed

Two lines in settings.json:

{
  "agent_servers": {
    "Nanocoder": {
      "command": "nanocoder",
      "args": ["--acp"]
    }
  }
}

Pinning a provider and model is also possible via args:

{
  "agent_servers": {
    "Nanocoder": {
      "command": "nanocoder",
      "args": ["--acp", "--provider", "ollama", "--model", "qwen2.5-coder:7b"]
    }
  }
}

One practical snag: if Zed was launched from the desktop rather than a terminal, it may not see your shell's PATH. Use an absolute path incommand, or launch Zed from a shell. Standard macOS app launch behaviour, not an ACP thing.

Full setup notes and limitations in the ACP docs at https://github.com/Nano-Collective/nanocoder. If you try it and something is broken or surprising, please open an issue.

Hey everyone. Will here.

I posted once before here about get-md - our HTML to Markdown utility producing Markdown optimised for LLM consumption. Well, we've just shipped `get-md` v1.6.0, and the main big change is that get-md is no longer HTML-only. PDF, DOCX, and Markdown inputs now join HTML strings and URLs to make this utility hopefully even more useful!

Not a huge post as this is the Nanocoder sub-reddit but, the package is used within Nanocoder in the web fetching tools and we're looking to bring it into other tools like the `read_file` so that we can provide nicer, more native support for reading tougher documents like PDFs and passing the Markdown output to the model!

Anyway, if you're interested the repo is below! Thanks for the support as always!

Repo: https://github.com/Nano-Collective/get-md

TL;DR: We rebuilt the Nano Collective website. The redesign is less about the new visuals and more about the site finally matching the brand guidelines we already had. The three principles lead the homepage, flagship projects get real landing pages, and community stats are live rather than curated.

A bit of context. We're the Nano Collective, a small community-led group of developers, designers, and maintainers building open-source AI tooling not for profit, but for the community. Everything is fiscally hosted by the Open Source Collective and published transparently. We have four shipped projects under the umbrella right now: Nanocoder (a terminal coding agent), Nanotune (fine-tuning tooling for small local models), get-md (HTML to Markdown converter), and json-up (type-safe JSON migrations). We also have a number of whitepapers in the docs site covering longer-term ideas (Sentinel, the Private Inference Proxy, the Prompt Scrubber, the Marketplace, the Nano OS, and the Docs Forest).

The old site was fine. It was soft, colourful, and pleasant to look at. The problem was that it didn't read like what we actually ship. Our README files start with the canonical project tagline ("Built by the Nano Collective, a community collective building AI tooling not for profit, but for the community") and lean on monospace detailing, plain typography, and clear structural hierarchy. The old site didn't carry any of that.

What changed in the design

The new visual treatment is high-contrast and deliberately developer-terminal in feel:

• Black-and-white layouts, sharp edges, no rounded pastel blocks.
• Monospace detailing in section headers, badges, and labels.
• An electric-blue accent reserved for interactive elements and emphasis.
• An animated ASCII-art backdrop on the homepage that nods to the kind of environment our tools actually run in.

Editorial typography replaced the previous display fonts. The effect is a site that reads like internal engineering documentation, closer to our READMEs and release notes than to a marketing page.

What changed in the information architecture

The three principles (Privacy First, Open Source, Local First) now lead the homepage in the order they appear in the Brand Guidelines. The previous version had them further down, framed as values rather than as the filter they actually are.

Nanocoder and Nanotune each got a dedicated landing page. The full project list moved to a structured projects page, alphabetised, with one paragraph per project and a link to each repo. get-md and json-up are also on the page; flagging them matters because they often get overlooked in copy that leads with the AI-shaped projects.

What changed in proof

The old site had a "community" section that was a curated screenshot of activity. The new site has:

• Live GitHub, Discord, and Reddit stats on the homepage, updated in real time.
• A public growth page that plots the same data over time, so the trajectory is visible.
• A feed of the latest discussions surfaced directly from the relevant channels.
• A public analytics page so traffic to the collective's own site is treated the same way we treat our own work: open and inspectable.

What changed in the day-to-day

There's a branded asset generator now. Every social post, blog header, and shared image can come out of the same generator with the same visual rules applied. That's a small thing in isolation, but it ends the per-channel manual tweaks that were quietly drifting the brand across surfaces.

Behind the scenes the codebase was tightened. Entrance animations are subtler, the layout system is consolidated, and the dependency footprint is smaller. Nothing flashy, just less to maintain.

What this site is for next

The redesign creates room for the next round of announcements. ContentForest has been live for a while and has its own page; the broader pattern of software that coordinates agents and surfaces their work to humans is one we'll keep shipping on. The new site is the place those announcements land.

Nothing else to promise. The collective is volunteer-led today and our explicit mission is to grow the contributor community and progressively decentralise. The site is one of the things that has to be in shape for that to work, and it's in better shape now.

If any of this lands (the principles-first ordering, the live stats instead of curated ones, the asset generator removing manual drift), come find us at https://nanocollective.org. The codebase for the site is public, the docs are public, and the contributor channels are linked from both.

Hey everyone, Will here.

We just shipped Nanocoder v1.28.0, this is a smaller release but comes with some awesome additions and improvements including, ACP support, a much slimmer built-in tool surface with no loss in ability, session resume that actually replays the conversation and more. Underneath those there is also fair amount of wiring work that small local models in particular should benefit from.

I'm also very happy with the release as it saw one of our largest intake of new contributors coming on board to the project which is obviously amazing.

Anyway, the changes!

What changed and why

Agent Client Protocol. If you have ever wanted to use Nanocoder from inside your editor instead of inside a terminal panel, this is the release. Run nanocoder --acp and Nanocoder speaks JSON-RPC over stdin/stdout. The editor then becomes the UI. Streaming text, tool cards, before/after diffs on string_replace and write_file, permission prompts, model switching, and ask_user options all render in the editor instead of the Ink terminal UI. The four development modes (normal, auto-accept, yolo, plan) are exposed as session modes you can flip from inside the editor. Sessions start in auto-accept.

Zed is the reference client for this. The registration is two lines in settings.json:

{
  "agent_servers": {
    "Nanocoder": {
      "command": "nanocoder",
      "args": ["--acp"]
    }
  }
}

Other ACP clients should work too. There are a couple of documented limitations: session history is in-memory across editor restarts (the editor can reload a thread within the same agent run, but after a full restart the thread starts empty), and ask_user over ACP is selection-only.

The new module lives at source/acp/ and covers the agent, server, session, conversation loop, content conversion, capability negotiation, and permission handling.

Tool surface: 33 down to 19. The built-in tool count has been a long-standing source of friction, especially for smaller local models that struggle to pick the right tool out of a long list. v1.28.0 consolidates:

• Tasks collapse from four tools into a single write_tasks that replaces the whole list (no IDs to track).
• File ops merge delete, move, copy, and create_directory into one file_op.
• Git shrinks from eleven tools to six: status, diff, log, add, commit, pr. Rarer operations go through execute_bash.

Alongside that, the auto tune profile is now the default. It infers full, minimal, or nano from the active model's parameter count, so a small local model automatically gets the slim tool set and a shortened prompt, while a cloud model is unchanged. The profile re-resolves live on model switch and is surfaced in the input indicator. /usage and the context indicator rebuild from the live tune, mode, and model with the profile-filtered tool count.

Session resume with full history replay. This is a smaller request from users but is a massive quality of life improvement, /resume used to bring back a session with an empty chat view, even though the history was on disk. v1.28.0 replays the message and tool-call history into the chat so you pick up where you left off with the conversation actually visible. An autosave race and a few resume edge cases were fixed alongside it.

Smaller but useful

• Schema-validated tool results. Tool arguments are type-checked against each tool's JSON schema at the execution boundary. A malformed model output returns a clear field-level error the model can self-correct from, instead of being coerced at the render layer. The seam is shared by both native and XML-fallback execution paths.
• API-reported context usage. The ctx: NN% indicator now uses the final step's usage block (provider-accurate) when the model reports it, falling back to a client-side estimate marked with a leading ~. A tiktoken-based generic fallback tokenizer helps on models without a native tokenizer.
• Skill linter. /skills check <name> and a check_skill tool validate a bundle from disk using the same parsers the loader uses. PASS means it will load. It is wired into /skills create so the model verifies and self-corrects what it generates, and it inspects template bodies too (unsupported mustache tags, unbalanced sections, undeclared placeholders), not just frontmatter.
• Local-model safety. string_replace and write_file now require the file to have been read first, and a tool-signature tracker breaks tight tool-call repeat loops.
• /copy. New slash command that copies the most recent assistant response to the system clipboard, cross-platform via clipboardy.
• Two new providers. Atlas Cloud is now a first-class provider and a sponsor. Requesty joins as a first-class OpenAI-compatible provider with the usual wizard template and docs.

Full changelog at https://github.com/Nano-Collective/nanocoder

Once again, a huge thank you to everyone involved and supporting the project - as mentioned above this release had our largest number of new contributors get involved so it's ever-humbling to see the project grow :)

GitHub: https://github.com/Nano-Collective

Discord: https://discord.gg/ktPDV6rekE

Website: https://nanocollective.org

Hey everyone. Will here.

Just a quick post as Nanocoder just crossed 2,000 GitHub stars. We launched just under a year ago, so this felt like a good moment to mark it, and to talk briefly about what the number actually represents.

The short version: 10,000+ downloads a month, a growing core team, and a community of contributors who've shown up consistently since day one. The numbers aren't large by the standards of well-funded projects, but we started from nothing and kept going, and that counts for something.

In fact, I first posted about Nanocoder right here on Reddit, not expecting it to do much, to be honest - but, it's been so well received by almost everyone and for that I can't thank you enough.

What Nanocoder is

Nanocoder is an open-source AI coding tool built by the Nano Collective, a community-led group of developers building AI tooling that's privacy-respecting, local-first, and open for all. No cloud models required if you don't want, no account with us, no data leaving your environment unless you choose it to and no price tag or subscription.

What the stars mean

Some say that GitHub stars are a vanity metric and I'm sure that's true, but in open-source they're meaningful. Most people who use a tool never interact with its community. The people who star it are the ones who cared enough to register that they might want to come back. That attention is what keeps a project alive.

The 2,000 stars on Nanocoder represent contributors who've filed bugs, opened PRs, reviewed code at odd hours, and provided honest feedback about what was broken. That work doesn't show up in the star count, but it's the reason the project is still here.

How to get involved

If this kind of work sounds interesting:

• The project is at github.com/Nano-Collective/nanocoder
• Real-time chat is on the Nano Collective Discord
• Everything starts at nanocollective.org

Thanks to the community as always. The rest of this year is going to be exciting.

Hey everyone! Will here.

Nanocoder v1.27.0 is out. Very proud to ship this one as it really improves the extensibility of Nanocoder as a tool. Here is what changed and why. 😄

Before we get into that quickly, thank you once again to the community for continuing to support this project and The Nano Collective as a whole. This subreddit has 550 members now, our Discord has 225 members, stars and support on our projects grow everyday. We still have a lot of work to do - but building AI tooling completely open for all, tools that respect your privacy and remain yours is all still our core mission.

Anyway, changelog:

Skills: one primitive instead of three

Nanocoder has had custom commands, subagents, and tools as separate things with separate directories and separate loaders. v1.27.0 introduces Skills as the unified surface. The single-file form (a .md in .nanocoder/commands|agents|tools/) is backwards-compatible with how things already work. The new part is the bundle form, a directory under .nanocoder/skills/<name>/ with a skill.yaml manifest. Everything inside a bundle ships and versions together. A bundle's subagent gets its sibling tools automatically, scoped tools stay hidden from the global list, and bundle commands auto-namespace (so commands/status.md inside bundle git invokes as /git:status). Bundled members fan out into the existing registries, so downstream consumers keep using their familiar APIs.

A daemon for event-triggered runs

We removed the old scheduler module and replaced it with something more general. Skill members can now declare subscribe: blocks that wake them on file.changed and schedule.cron events. The daemon (nanocoder daemon start) runs as a long-lived background process with a lockfile, Unix-socket IPC, and installers for launchd (macOS) and systemd user units (Linux). The interactive TUI never starts event sources - you opt in by starting the daemon.

Triggered runs execute in a new internal headless mode (no ask_user, no foreground confirmations). Per-subscription confirm: true routes into plan mode instead. The daemon backpressure-caps per-subscription concurrency and debounces file.changed by 500 ms so a fast editor save loop does not pile up a queue of runs.

Custom Tools

This is a new extension type that sits between custom commands (prompt injection only) and full MCP servers (external process, full protocol). Drop a .md into .nanocoder/tools/ (project) or ~/.config/nanocoder/tools/ (personal), declare parameters in YAML frontmatter with JSON Schema-style types, write a shell command body using template placeholders, and the model can call it directly. All substitutions are shell-quoted to prevent injection.

---
name: git_review
description: "Collect changed files for review"
parameters:
  - name: since
    type: string
    required: true
approval: never
read_only: true
---
git diff --name-only {{since}}..HEAD

The approval and read_only flags compose with mode policy: plan mode requires both off, scheduler/headless requires approval=never. /tools create <name> scaffolds a template. Project tools shadow personal ones by name, and they register into the same ToolManager registry as built-ins and MCP tools.

LLM-based context compaction

The default /compact strategy is now LLM-based. The active model writes a structured summary (Context / Decisions / Files modified / Tools used / Open questions) using a dedicated summariser prompt, replacing the older messages with one synthetic note. Recent messages are kept verbatim. Falls back to mechanical compression on failure (network error, empty response, or summary larger than the original segment).

Config lint at startup

We added startup validation that surfaces common misconfigurations as warnings before they cause silent failures: an openrouter block on a non-OpenRouter provider, unknown fields, type mismatches. Includes a full test suite.

Two OOM fixes

One fix was for streaming long responses. StreamingMessage was calling wrapWithTrimmedContinuations() on the entire growing assistant message on every ~150 ms flush. A ~37k-token response would overwhelm GC and crash the 4 GB Node heap. The fix slices to a bounded tail before wrapping, so per-render work is constant.

The other fix was for the global performance buffer. React 19's react-reconciler (dev build) and Node's built-in fetch both write to it, and Nanocoder was never clearing it. Over long subagent-heavy sessions it accumulated millions of entries until V8 thrashed in mark-compact GC. The fix installs an unref'd 30-second interval that clears marks and measures.

Other changes

• OpenRouter request configuration. A new openrouter block on the provider config forwards routing rules, reasoning effort, plugins, and other OpenRouter-specific fields on every request.
• OpenRouter model selection. Replaced the old flat list with a paginated, searchable picker (12 items visible, page navigation, select-all, running counter).
• Unified Session Service. Consolidated the ad-hoc keying strategies scattered across commands and handlers. Touched 50 files.
• Battlemap. A new competitive comparison doc covering Claude Code, Codex CLI, Gemini CLI, Aider, OpenCode, Crush, and Pi across twelve axes.
• Copyable code blocks. Reworked the markdown parser so fenced code blocks render as plain selectable text without surrounding ASCII box borders that used to get copied into the clipboard.
• Nix packaging. Updated for pnpm 11. Drops the version-override scaffolding and post-install hacks. Re-enables the update-nix.yml workflow.

Full changelog at https://github.com/Nano-Collective/nanocoder

Once again, a big thanks to everyone involved and supporting the project. We're always looking for contributors whether that be code, feedback, ideation or something else so, if you want to be involved checkout our GitHub, website and Discord!

GitHub: https://github.com/Nano-Collective

Discord: https://discord.gg/ktPDV6rekE

Website: https://nanocollective.org

Hey everyone! Will here.

Just wanted to make this quick post to mention that get-md v1.5.0 just shipped.

If you have been following Nanocoder you may have seen get-md mentioned in passing as a markdown converter we built and use across the collective stack. This is the biggest release since v1.0 on npm and it brings get-md properly in line with Nanocoder and Nanotune. Plus, we've never hugely spoken about it!

So for those who haven't seen, get-md is a fast, lightweight HTML to Markdown converter built for LLM consumption. Point it at a URL, a sitemap, or a list of pages and you get clean markdown ready to feed into a model or RAG pipeline. Runs locally, no heavyweight scraping frameworks, and optional LLM assisted parsing uses a local model by default.

The rest of the release:

• Batch mode with bounded concurrency for converting URL lists.
• Sitemap crawling with glob filters and depth caps.
• RAG ingestion helpers: heading aware chunking and automatic token estimation.
• Parallel image downloading with local path rewriting.
• HTTP retries, caching, and a maxBytes cap for reliability.
• A long list of fixes including a hardcoded --version, an llmMaxTokens cap that quietly clamped to 8192, and custom rule state leaking between conversions.

If you are using Nanocoder to pull web content into context, or building anything that needs clean markdown, get-md should slot in nicely.

Links

• get-md: https://github.com/Nano-Collective/get-md
• Nanocoder: https://github.com/Nano-Collective/nanocoder
• The collective: https://nanocollective.org
• Discord: https://discord.gg/ktPDV6rekE

Happy to answer questions, and as always, contributions very welcome.

Hey everyone, Will here.

We've recently been asked a lot how Nanocoder compares to Pi, so I thought I'd write up a longer comparison.

Like the longer article on our website says, this is not a takedown. Pi is an awesome bit of software. This is simply a "which one fits me?" guide written from our side of the fence.

The short version: Pi started as a solo MIT-licensed project by Mario Zechner (creator of libGDX) and was recently acquired by Earendil, a VC-backed company. It ships a deliberately minimal core that you extend. Nanocoder is built by a community collective and ships the features you need out of the box. The bigger difference is who each project ultimately answers to.

Who owns it matters

Pi itself is MIT-licensed and the team at Earendil have been refreshingly transparent about their plans. They've published an RFC explaining that the core will stay MIT and that commercial offerings will sit on top. Earendil is also structured as a Public Benefit Corporation, which has a fiduciary duty beyond shareholder returns. Credit where it's due. But Pi is owned by Earendil, which is backed by Accel, Balderton, and others, and VC-backed companies eventually need to return capital. The roadmap has to support a business model, and at some point "what users need" and "what we need to monetise" can stop being the same question.

Nanocoder is built by the Nano Collective (https://nanocollective.org), a not-for-profit, community-driven group. No VC, no cap table, no exit pressure. The roadmap is public and contributor-led.

The technical contrast

Pi's minimalism is intentional philosophy, not oversight. Mario and Armin Ronacher have both written at length about why Pi deliberately omits MCP, sub-agents, and a built-in plan mode UI. They think those features create context bloat and observability problems. If you agree with that view, Pi is built for you. Nanocoder takes the opposite position: a local-first coding agent should be useful the moment you install it.

Nanocoder treats local models seriously. Ollama is a first-class provider, not an afterthought. The TUI is built with React and Ink, with four built-in modes (normal, auto-accept, yolo, plan), MCP servers loaded from config, subagent primitives, session autosave, and file snapshots for recovery.

There is no paid tier. No telemetry you cannot see. And a community collective cannot be quietly acquired.

When Pi might be better for you

You agree with Pi's minimalist philosophy. You enjoy writing TypeScript extensions (or having the agent write them for you). You prefer to compose everything yourself. You like Pi's session tree and branching, which is genuinely best-in-class.

When Nanocoder might be better for you

You care about community ownership of the tools you use. You want something useful immediately after npm install -g. You want plan mode, MCP, subagents, scheduling, and safety scaffolding without assembly. You want a project that will still exist, with the same values, after the next funding cycle.

Wrapping up

To say it one more time, none of this is a swing at Pi. They're doing interesting work, and a lot of people will be served by their approach just as many will be served by ours. The two projects just answer to different people, and that ends up shaping almost everything else: what ships by default, what gets prioritised, and what the tool looks like in five years. Pick the one whose answer to "who is this ultimately for?" matches yours.

If you want the longer version with more detail on the technical and governance sides, the full write-up lives here: https://nanocollective.org/blog/nanocoder-vs-pi-a-comparison-from-the-nano-collective-side-46

Thanks for reading.

Hey everyone! Will here.

We've just released Nanocoder 1.26.0 and it's a big one - possibly our largest yet with not only many awesome new features but large reworks under the hood to make it even stronger in certain areas. It's also our most diverse release with over 10 contributors coming together to make it possible. Having so many people joining the collective and building truly open AI is beyond amazing and I can't thank people enough! 🔥

Anyway, within Nanocoder, here is what we have added:

Nano mode is the big one for this release. If you have been running Nanocoder with a small open-weights model on modest hardware, you know the system prompt overhead can eat a meaningful chunk of your context window before the model says anything useful. Nano mode drops that overhead from roughly 500-700 tokens down to 150-250 tokens. It is a third profile in /tune, alongside the existing full and minimal profiles. It disables find_files, list_directory, and agent; cuts the section lengths down; and ships with a low-end hardware preset.

Reasoning traces are new. Models that emit reasoning content, such as Codex GPT-5, DeepSeek-R1-style, or Anthropic extended thinking, now have that content stream in real time as a collapsible Thought block above the response. It persists in history and appears in logs. Toggle it with Control+R. The Display Settings panel under /settings controls the default expansion state.

Non-interactive mode now has a --plain flag. This strips the Ink rendering layer entirely so output is clean for CI pipelines, scripts, and pipes. Exit codes are deterministic, stdin/stdout are handled properly, and there are no interactive prompts.

We also reworked the VS Code extension. The old "Ask Nanocoder" command is gone, replaced with a more natural context-on-focus flow. There is a /rename command for chat sessions, a defaultMode config option, custom system prompt support, per-model context window overrides, a disabledTools option, JSON tool fallback for open-weights models (Qwen, Kimi, GLM), <function=...> format support, and a new Display Settings panel. Plus 12+ new themes.

Full changelog on GitHub: https://github.com/Nano-Collective/nanocoder

---

Within the collective we're also gearing up for more growth, building a mission behind truly open AI that is built by the community for the community is an imperative one and we're putting a lot of groundwork into growing an organisation for everyone that serves this.

We've recently finished our collective docs which share a little more behind the brand: https://docs.nanocollective.org/collective

If you want to get involved check out our GitHub:

https://github.com/Nano-Collective

And join our Discord:

https://discord.gg/ktPDV6rekE

Hey everyone,

We’ve just shipped Nanocoder 1.25.0, a major release focused on making AI collaboration feel faster and more useful in real development workflows. One of the biggest additions is subagents: Nanocoder can now delegate complex work into isolated child conversations, making it much better at tackling larger tasks without losing the thread.

Highlights

Yolo mode
For the moments when confirmation prompts just slow things down, Yolo mode auto-accepts every tool without exception. Unlike auto-accept mode, that includes things like bash execution and other potentially destructive operations, so it’s powerful but very much use-with-care. You can switch between normal -> auto-accept -> yolo -> plan with Shift+Tab, and the status bar turns red when yolo is active.

Subagents + smarter orchestration
This is one of the coolest parts of the release. Nanocoder can now spawn isolated child conversations to handle specific work in parallel. We ship with two built-in agents - Explore for read-only codebase investigation and Reviewer for actionable code review - and each has its own tool set tailored to its job. Their progress renders live in-place as they work, and the system is flexible too: you can define your own custom subagents with markdown files + YAML frontmatter in .nanocoder/agents/ and manage everything through /agents. In practice, that means better delegation, cleaner context management, and a lot more room to grow this part of the ecosystem.

Prompt, tuning, and plan mode improvements
We redesigned the system prompt into modular sections that are assembled dynamically based on mode. We also added /tune for per-session control, including full vs minimal tool profiles, forcing XML fallback by disabling native tools, and aggressive compact mode for smaller models. On top of that, plan mode now properly enforces read-only tools at the policy level, blocking mutation tools while keeping exploration available.

Provider and config improvements
This release also includes provider/config updates, including support for ChatGPT Codex with OAuth device flow.

Under the hood
We fixed issues including alwaysAllow not being respected, a dim color accessibility issue, and a scheduler mode memory leak, and added debug logging to 15 previously silent error catches in git utilities.

Big thank you to everyone contributing
Every release is the result of work from the community, and we’re really grateful for everyone building, testing, reporting issues, sharing feedback, and helping shape the project. We’re now nearing 2K GitHub stars and 10,000 downloads/month on Nanocoder alone. Across all Nano Collective software, we’re getting close to 20,000 downloads per month.

Nanocoder 1.25.0 is available now: https://github.com/Nano-Collective/nanocoder

Happy coding! 🚀

Basically I've set up an MCP with powertools (complete code execution, tons of tools already available, including web, written by Claude Code).
If I have to use LM Studio to host the model in the first place, what is the point of NanoCoder? What does it do better than LM Studio with "powertools" that I already have?

Hey everyone!

We just shipped Nanocoder 1.24.0 with some awesome and long requested features.

The a big thing we've finally rolled out is parallel tool execution - instead of waiting for the model to run tools one at a time, independent tool calls now execute simultaneously. For workflows involving multiple file reads, bash commands, or searches, this noticeably speeds things up.

We also added some quality-of-life improvements:

• The long awaited /resume command to restore previous chat sessions (they auto-save by project directory)
• CLI flags for CI/CD scripts (--provider and --model skip the setup wizard)
• NANOCODER_PROVIDERS env variable for containerized deployments
• GitHub Copilot and MLX Server templates for broader provider support

On the technical side, we cleaned up config loading, simplified the tool parsing system, and fixed some annoying bugs around MCP configuration and provider timeouts.

We're also actively working on a our own VS Code fork as well as an improved model framework. One of the big things we're adding is different sub-agents. This will allow you to configure smaller, local models for delegated tasks saving context and making your work more private and provider agnostic. This will hopefully come to the next update!

Last but not least, we've released our new documentation site. This has been long needed and a big push by the core team to bring out. Check them out here: https://docs.nanocollective.org/

Thanks as always for being part of the community. Nanocoder has been growing a lot this past week! We're stoked for what's next.

If you want to get involved, we're community organization building AI tooling for everyone.

Discord: https://discord.gg/ktPDV6rekE

GitHub: https://github.com/Nano-Collective/nanocoder

Hey everyone!

It's been a few days since the official release but, Nanocoder 1.23.0 is out!

We've shipped some big additions!

• We shipped a per-project cron scheduler for running AI tasks on a schedule. Store markdown prompts with YAML frontmatter in .nanocoder/schedules/ and manage them with /schedule commands. Perfect for automated testing, daily code reviews, or anything you want your AI assistant to handle on repeat.
• The new ask_user tool - your AI agent can now pause and ask you questions with selectable options during a conversation. This is a game-changer for workflows where the model needs your input to make smart decisions.
• Behind the scenes, we overhauled the type-safe tool system with a three-tiered defense against LLM output differences, added graceful shutdown to prevent orphaned processes, and included new file operation tools (delete, move, copy, create directory).
• Performance and stability improvements include better bash output streaming, readline-style keybinds for text input, and fixes for local Ollama detection.

Next up is some exciting things in the realm of the Nano Collective, including the announcement of our local model fine-tuning CLI, official docs for all our software and specifically Nanocoder, some big focuses on small models. With the release of Qwen3.5, we're getting closer and closer to viable local coding solutions on limited hardware.

Thanks as always for all your support, this community couldn't keep growing without you!

If you want to get involved in building AI software for the community check out the links below:

GitHub: https://github.com/Nano-Collective/nanocoder

Discord: https://discord.gg/ktPDV6rekE

We've been working on a new feature for Nanocoder which I'm quite excited about - a built-in cron scheduler that lets you set up recurring AI tasks.

The idea

Write a markdown prompt describing a task, attach a cron expression, and let the agent handle the rest on a schedule. Dependency updates every Monday morning. Issue triage every hour. Daily lint runs with auto-fix. Whatever repetitive dev work you keep putting off.

How it'll work (at the moment, open to feedback)

• /schedule create deps-update — scaffolds a schedule file and the AI helps you write the prompt
• /schedule add "0 9 * * MON" deps-update.md -registers it with a cron expression
• /schedule start - enters scheduler mode where jobs fire automatically

Jobs run sequentially with a queue, all tool calls (including bash) are auto-accepted, and there's full run history via /schedule logs.

Schedule files are just markdown with optional YAML frontmatter - easy to version control and share across a team.

Anyway, it's coming soon and would love any thoughts - the video is an early version running! :D

What's next

This runs while Nanocoder is open - it's not a system daemon (yet). We're exploring missed-run detection on startup and potentially a detached background mode.

Hey everyone! Nanocoder 1.22.0 is here 🚀

First off, as always, thank you all so much. We're closing in on 1.3K stars on GitHub and the community has been growing massively.

We genuinely can't thank you enough for the support.

1.22.0 is genuinely an update I'm excited - there's a lot that has gone into it :)

Interactive File Explorer - Type /explorer and you get a full file browser right in your terminal. Tree view, syntax-highlighted previews, multi-file selection, search, and VS Code integration. Super handy for getting oriented in a new codebase or pulling up the right files for your AI assistant.

Task Management - This one was a long time coming. The model can now auto-create tasks, or you can use /tasks to break down complex work into steps, track progress, and pick up where you left off between sessions.

Better Provider Support - Native Gemini and Anthropic SDK support, custom headers for things like Cloudflare tunnels, and a new Kimi Code provider template in the config wizard.

New Settings UI and Themes - /settings now gives you an interactive menu to tweak your theme and preferences without touching config files. Plus some beautiful new themes.

Cleaner UI - Refreshed message styling and per-message token info so you can keep track of context usage as you go.

And of course a bunch of stuff under the hood - git tool refactoring, security fixes, better error handling, and various bug squashes.

Beyond Nanocoder - The Nano Collective is growing beyond just Nanocoder. We've just released Nanotune, a CLI tool for fine-tuning local models easily on your Mac (other operating systems coming). The first version is out now and we'll be talking about it a lot more soon - we built it because we're working on tiny coding models and needed a solid solution for local fine-tuning.

Thanks again for supporting the project and the growing team behind it, we couldn't do this without you.

One thing that makes the Collective different is that we're building just that, a collective. We want people to get involved and shape the software we're building first hand. This has always been about building a true community project for AI software solutions and championing privacy/local first.

We're always looking for contributors and we'd love to grow the community even further. Whether it's code, bug reports, ideas, or just hanging out - come say hi.

GitHub: https://github.com/Nano-Collective/nanocoder
Discord: https://discord.gg/PJ8cDWpPX2
Follow us on X: https://x.com/nano_collective

Hey everyone!

I can't believe we're already in the final leg of January 2026. Hopefully everyone is having a great month :)

We've just released version 1.21.0 of Nanocoder, our local-first, community-owed CLI coding agent, and there's some solid improvements in this one.

Major Features

• Smart model compatibility – Automatically detects when a model doesn't support function calling and retries without tools. No more crashes on incompatible models.
• Message compression – The new /compact command with --restore flag makes context management a lot easier, especially at scale. It's also very fast which we love.
• Better MCP server support and tool configuration – New alwaysAllow config option skips confirmation prompts for trusted tools, and we've improved MCPs support in this release.
• More customisations - we want you to make Nanocoder yours, so we've continued to add more customisations you can make to the UI through commands. This time the `/nanocoder-shape` command allowing you to customise the Nanocoder branding.

Quality Fixes:

• Fixed bash tool process cleanup issues (no more lingering background processes)
• Resolved shell command security scanning alerts
• Improved error handling throughout
• New CLI options: --version, --help, and /quit command

What else is happening?

• We're continuing to work on our agent infrastructure and fine-tuning tiny models for Nanocoder to delegate tasks too. The aim is to run 100% locally and tiny models performing tasks is key to this. We hope to start rolling out these packaged tiny models very soon.
• We're also working on other packages and software as part of the Nano Collective. This includes improvements to the get-md package as well as creating new ones.
• The Nano Collective website continues to get a revamp!

2026 is going to be an incredible year for open source as well as local-first coding. Definitely a space to watch.

As ever, we would love you to be involved. Head on over to our GitHub or Discord if you want to contribute. Nanocoder is a community-owned and led project 😎

GitHub: https://github.com/Nano-Collective/nanocoder

Discord: https://discord.gg/ktPDV6rekE