
An empty fund that says so is worth more than a full one that lies. The Nano Collective's Economics Charter names the community fund a mechanism, not a balance, and publishes the real number alongside it. The honesty is the commitment.


A 30-day review held against a proposal you quietly rewrote is worthless. When a whitepaper pivot changes the problem, audience, or shape of the solution, flag it openly. The clock resets so the objections the community raises are about the project you're actually building.



No lawyer signed our Economics Charter. It is a Markdown file under version control, with git as the audit trail. Financial terms get 30 days notice and apply to new work only. Anyone can read what was promised when, and your terms stay in effect unless you agree otherwise.



A merged whitepaper used to function as a build endorsement. The Nano Collective treats that as a bug. Merge publishes the thinking. Stage 3 is the build call, after 30 days of public review, recorded on-page with rationale so the yes runs against what the project actually is.



A converter you reach for during LLM prep should not phone home by default. get-md's Turndown and Readability path stays local and finishes under 100ms, which is the only sane default when the input is also your prompt.



Mermaid in source, an SVG already rendered, and a vector drawing in a PDF are three different problems pretending to be one. Pretending one path handles all three is how your diagrams vanish in conversion. get-md ships four paths: preserve, recover, generate, validate.



Most converters render PDFs to images and route them through cloud vision by default, then bill you in API credits. get-md ships text-only. PDF vision is opt-in: useLLM, a remote model, and two peer deps you install yourself. Cost only exists if you asked for it.



Under 100ms for a typical HTML page, no service in the path, no rate limit to dodge. When your converter is faster than your LLM round-trip, prep stops being where the pipeline loses time. get-md makes that the default.


Most "JSON migrations" are scattered `if (old.field)` guards across the codebase, with no record of which shape shipped when. json-up keeps every step in one versioned file: one place to read the history, one place to bump it.



"Validation failed" with no field path is a grep you didn't budget for. json-up's `ValidationError` carries the `issues` array, so the offending field is named in the message you already have.



3 errors, one migrate() call. ValidationError and MigrationError point at your data. VersionError points at your config: sort order, duplicates, empty arrays.



A migration that runs cleanly can still hand back garbage. json-up checks the up() result against the schema, not just the input, so a broken step fails where you can see it instead of three migrations later.



A coding agent should answer to the developer, not to the foundation that funds a model lab.

Nanocoder treats Anthropic, OpenAI, Google, Ollama, and OpenRouter as interchangeable providers in one CLI, so the vendor never holds the user hostage.



A checked-in API key is a leak waiting for a bot. nanocoder reads NANOCODER_PROVIDERS (or NANOCODER_PROVIDERS_FILE) over anything in agents.config.json, so your keys stay in the shell and the repo stays clean.



Your first prompt shouldn't require memorising twenty-plus provider config blocks. Nanocoder's /setup-providers wizard exists because hand-writing agents.config.json was the thing blocking real adoption. Templates, model fetch, save.


Most coding agents put the cloud key in the first paragraph and the local providers in the fifth. Nanocoder puts Ollama, llama.cpp, LM Studio, MLX, vLLM, LocalAI, llama-swap, and Atomic Chat in the same provider schema as the cloud ones. Same fields, same wizard.



A local agent doesn't crash loudly. It stalls on a long token, then dies at the 2-minute default. nanocoder's agents.config.json: requestTimeout and socketTimeout both to -1 in your local-provider block. Agentic loops on a laptop routinely exceed the default.



Fine-tuning shouldn't depend on whoever wrote the last config. Nanotune encodes the loop as five verbs (init, data add, train, benchmark, export), so the next teammate runs the same commands instead of reverse-engineering a YAML blob.



Five commands. No YAML. No flags. By lunch you have fine-tuned a model and exported a GGUF running in Ollama or llama.cpp. That is the whole nanotune workflow: init, data, train, export, done.



The default for fine-tuning is a wall of YAML and flags you read for an hour before you see a number. Nanotune's init asks plain questions, then you run data, train, benchmark. Dataset in, a feedback signal out, before lunch.



The slow part of fine-tuning is never the training run. It's the convert-and-pray that comes after. Nanotune's export writes a GGUF the same day, so the trained model drops straight into Ollama or llama.cpp without a conversion script in between.


You run the benchmark and every failure lands on the same two prompts you forgot to train on. Nanotune's bench output is the next dataset: add the cases that broke, rerun train, rerun bench. The loop closes in an afternoon, not a release cycle.



You can scrub your message and still leak. `ls`, `cat`, `git log`, `grep` - whatever a tool prints is the next prompt, paths and all.

prompt-scrub scrubs every message regardless of origin, so identifiers in tool results never reach the next LLM turn.



Randomising placeholders per turn looks safer. It isn't. If "Email_1" becomes "Email_3" next turn, the change is the signal: the model pins you from what moved.

prompt-scrub pins one placeholder per identifier per session. Names stay still, so there's nothing left to correlate.


Your prompts travel through a network the LLM provider can read. Run prompt-scrub on the content, then put whatever you trust on the request path: VPN, Tor, a proxy. Scrub, send, rehydrate. Network choice stays yours.



A scrubber that reaches for the network ends up doing two jobs badly. prompt-scrub stops at the text: it strips identifiers in place, hands you back a session id, and gets out of the way. You pick the request path, the transport, the trust model. The seam stays where it should.



Hundreds of out-of-the-box rules, and most of them were written for someone else's stack. You scroll past them on every run. Sentinel ships zero rule packs on purpose. The audit only fires on what your team defines.


A suppression filter that learns from feedback will learn to swallow the next real bug. Sentinel (alpha) keeps dedup, false-positive labels, and sentinel.yaml as three independent levers. Each closes a different scope of false positive.


Close one false positive fast enough and your brain flags the next five as noise. That is how a real finding gets skipped. Sentinel (alpha) treats a false-positive label as permanent, so dismissing one never costs you the next five.



Your audit tool shouldn't need its own model config. Sentinel runs its scheduled audit through Nanocoder against the same providers you already set up for coding. Ollama, vLLM, llama-swap, all carry over. One provider stack, not two.
