Skip to content

[collective]: Why we updated how we describe nanocoder #85

Description

@will-lamerton

Slug

why-we-updated-how-we-describe-nanocoder

Scope

Whole pack

File path

No response

Request

Nanocoder Positioning Shift — Brief for Marketing Copy

A short conceptual brief explaining a subtle but deliberate change to how we describe Nanocoder. Use this to write marketing/announcement content about why the framing changed. This is about positioning, not a changelog.

The thesis (lead with this)

The community collective approach is the point. Nanocoder is not "another coding agent that also happens to be open source." It is fundamentally different in principle because of who builds it and why: a community collective, building not for profit but for the people who use the tool. That single fact is what shapes every other decision — no paid tiers, no telemetry, no vendor lock-in, no roadmap steered by what monetises best. Everything else in this brief is downstream of it.

Marketing should treat this as the headline, not the footnote. The software is different because the structure that produces it is different. Most AI tooling is built by companies whose incentives diverge from their users'; Nanocoder is built by the people who rely on it, in the open, under permissive licenses, with the direction shaped by contributors rather than investors. That is the durable differentiator — features can be copied, the ownership model cannot.

The one-line summary

We stopped leading with "local-first" as Nanocoder's headline identity, and started leading with "a coding agent that runs on the model of your choice, built by a community collective rather than a company." The principles didn't change — the emphasis did, so the description matches both how the tool is actually used and why it exists at all.

Critical nuance — do not get this wrong

This is not a retreat from local models. We support them, we prioritise them, and we are actively investing in making them better. The shift is about honesty, not de-prioritisation. Three things must all be true in any copy written from this brief:

  1. Local models are a first-class priority, not a fallback. Nanocoder runs local models (Ollama, LM Studio, llama.cpp, MLX) as a core path, and the collective is doing real work — including separate projects like Nanotune — to make small, local models genuinely good at coding. This is a thing we are pushing the frontier on, not paying lip service to.
  2. We recognise the place for the cloud. Today, for many tasks, the strongest models are cloud-hosted. Pretending otherwise would be dishonest, and forcing users into a worse experience for ideological purity is not who we are. Giving people the choice — and keeping them in control of where their data goes — is the principle, not "local at any cost".
  3. Local model work has a long way to go — and we say so plainly. The honest position is that local coding models aren't yet at parity with the best cloud models for every task. We're optimistic and actively working to close that gap, but we don't oversell where it stands today. The trajectory is the story; the current state is acknowledged, not hidden.

The synthesis: local-first is a direction we are committed to and investing in, not a limitation we impose on users today. Cloud support is how we stay useful while the local ecosystem catches up — and helping it catch up is part of the mission.

What changed

  • Before: "A local-first CLI coding agent..." — local-first was the first thing you read, the noun that defined the product.
  • After: "A coding agent in your terminal, running on any model you choose — local models via Ollama, or any OpenAI-compatible API such as OpenRouter, Anthropic, and Google." Local-first is still named, but as one of three collective principles, not the headline.

Why we changed it

  1. Accuracy. Leading with "local-first" reads as local-only. In reality the harness is used heavily against cloud models (OpenRouter, Anthropic, Google, and more). The old framing undersold what Nanocoder actually is: a provider-agnostic agent where the user chooses where the model runs and where their data goes.
  2. It was never local-only by principle. The Nano Collective defines local-first as a spectrum: on-device by default, with privacy-preserving bridges to external capability when a task genuinely requires it. Supporting cloud providers doesn't violate local-first — but the old copy implied a purity the tool never claimed.
  3. Brand consistency. The collective ships three principles together, in a fixed order: privacy-respecting, local-first, open for all. The old copy elevated one of the three and dropped the other two. The new copy keeps all three, in order, as a description of the collective — and lets the product copy describe what the product does.
  4. The real differentiator was being buried. The strongest thing about Nanocoder isn't that it's local — it's that it's built by a community collective, not a company. No paid tiers, no telemetry shipping your prompts, no roadmap steered by what monetises best, and no lock-in to a single vendor's model. "Multi-provider on principle" is a consequence of being community-built, and that story was getting crowded out by the local-first headline.

The new emphasis, in order of weight

  1. Built by a collective, not a company — the defining difference, in principle. No paid tiers, no telemetry, no vendor capture, no investor-driven roadmap. The people building it are the people using it, and the direction is shaped by contributors. This is the lead, not a closing line.
  2. Your choice of model / no lock-in — local or any cloud provider, you decide. Frame this as a consequence of Release pack: nanocoder v1.25.2 #1: a community-built tool has no incentive to lock you to one vendor's model, so it doesn't.
  3. Privacy-respecting, local-first, open for all — the three collective principles, present but not over-rotated on any single one. These are the filter the collective applies to what it builds — say them in this exact order.

Tone guardrails (from the collective brand voice)

  • Operational, understated, honest. Closer to engineering docs than marketing.
  • Avoid: "transformative", "revolutionary", "cutting-edge", "next-generation", "sovereign AI", "trustless AI".
  • Pair every aspirational claim with something concrete a reader can see in the product.
  • Never imply we are moving away from local models. The emphasis changed; the commitment did not. If a sentence could be read as "Nanocoder is going cloud", rewrite it.
  • Be honest about where local models stand today (not yet at cloud parity for every task) while being clear we are actively working to close that gap. Optimism, not overselling.
  • Adversarial framing (naming what's broken about closed, VC-owned, single-vendor tools) is allowed sparingly, and only when followed by what we build instead.

The core narrative to build marketing around

We changed one word's worth of emphasis, and it tells the whole story. The thing that makes Nanocoder different isn't a feature — it's who builds it. It's made by a community collective, not a company: built in the open, for the people who use it, with no paid tiers, no telemetry, and no incentive to lock you to one vendor's model. That principle is why it runs on any model you choose, and why "local-first" was only ever one part of the picture. Features can be copied. The ownership model is the moat.

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    collective-requestIssue requesting collective-level content

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions