
The Nano Collective's Economics Charter was published before there was anything in the fund. No investors, no equity, no pitch. The terms are on record so contributors decide on facts.


30 days is the floor. Every whitepaper at the Nano Collective sits in public review for at least that long - status badge shows the close date, anyone can file issues. The build decision waits for the window to close.



Donations should have nowhere to hide. At the Nano Collective the charter names the only two destinations for every dollar before you give it: the cost of running the collective, or the community fund that pays OSS contributors. That is the whole model.


Sponsor money at the Nano Collective pays for infra and a ring-fenced community fund for OSS bounties. That is the whole list. No roadmap say, no contributor targeting, no exclusivity, no slot caps. Same words in the charter and on the sponsor page.



Closing a PR at 1am and wondering if any of it will ever be paid for is a quiet kind of resentment.

The Nano Collective has a defined answer: scoped bounties, designated donations agreed before money moves, bespoke partnerships. All transparent on the Open Collective ledger.


Your HTML-to-MD converter just mangled a nested code block inside a table cell, and your LLM is hallucinating around the wreckage. get-md's Turndown path is tuned for LLM input, with an optional local ReaderLM-v2 pass for the structures a regex can't reach.


"AI conversion" usually means someone else's machine. In `get-md`, `useLLM: true` with no `llm` block runs ReaderLM-v2 on-device via node-llama-cpp. One ~1.12GB download, then the page never leaves your laptop.


100ms or 5-10 seconds. get-md does both: Turndown for batch, CI, and real-time; the local ReaderLM-v2 path when the page's structure matters more than the speed. You pick, per call.



Display-rendering a page and feeding it to an LLM are not the same job. Same source, different output. Pretending they are is why so much crawled content enters prompts broken.

`get-md` ships them as two artifacts.



Point get-md at a sitemap.xml and walk away. It fans out across every URL with bounded concurrency, reports per-page failures inline, and lands a folder of clean markdown before your coffee gets cold. One command, in place of the bash for-loop no one wants to maintain.



The worst kind of migration is the one that runs clean and leaves your data wrong. json-up checks the output of every up() against a Zod schema, so the failure you wanted is the failure you get, and it's loud.



Most migration libs throw a generic Error and leave you parsing the message. json-up throws three named types: VersionError, MigrationError, ValidationError. You know what actually went wrong without guessing.


A schema change without a migration is a follow-up no one gets to. json-up puts version, schema, and up() in the same PR, so the change ships complete or it doesn't ship.



Your JSON already has a version field and the convention is wrong. Rename it and every reader breaks. json-up lets you pass `key: 'version'` (or anything else) to migrate over it as-is, so the schema catches up without a breaking rename.


Most of your JSON lives between versions, not at them. Migration tools don't validate, validators don't migrate. json-up treats them as one thing: each migration step carries its own Zod schema, so the shape that comes out is the shape you asked for, not the shape you hoped for.


Your terminal agent shouldn't phone home by default. Nanocoder ships Ollama, llama.cpp, MLX, llama-swap, vLLM, LM Studio, and LocalAI as first-class providers, so the local loop is the one you reach for, not the one you bolt on.


Your tool's parameter values get shell-quoted before they hit the body, so even '; rm -rf /; #' lands in echo as one literal string. nanocoder custom tools block injection at the template layer, not by trusting the model to behave.


20+ named adapters, plus anything OpenAI-compatible. The Nanocoder provider list (Ollama, llama.cpp, MLX, Claude, Copilot, OpenRouter) is less a checklist and more a switching surface. The agent you write today runs against whichever backend you point it at tomorrow.



A risky refactor with an agent feels like a hostage negotiation: commit nothing, hope for the best. /checkpoint create first, let the AI try it twice, /checkpoint load the better one. Files and history roll back together.


Extensions that don't know each other aren't much of a system. Commands, subagents, tools, and event subscriptions all sat in separate folders, no shared manifest. Nanocoder's Skills bundle folds them into one .nanocoder/skills/ folder, so siblings see each other.



The worst part of fine-tuning is rarely the training run. It's assembling examples that match a schema, deduping them, catching broken turn alternations before you waste an hour. nanotune's data commands handle the lot against one known schema, so the time goes into what to teach



Your training data shouldn't leave the machine it's written on.

Nanotune assumes local is the default. LoRA on Apple Silicon, MLX under the hood, no upload anywhere in the pipeline.



A regex can't tell you if a haiku scans. Nanotune's LLM judge scores open-ended answers against criteria you pick - helpful, accurate, concise, or your own - and shows reasoning per criterion, not just a yes/no. Cloud or local Ollama. Vibe-based evals stop passing.


A 0.5B to 1.5B fine-tune is useless if it can't leave your laptop. nanotune export fuses your LoRA into the base and writes GGUF down to q4_k_s, so you drop the same file into llama.cpp, Ollama, or LM Studio without rebuilding anything.


You can't string-match your way to knowing if a fine-tune is any good. We ran an LLM-as-judge in nanotune, on the same local models the rest of the tool uses, so eval stops being an act of faith.



You've pasted an env block into ChatGPT to "ask a quick question." It left your machine. prompt-scrub rewrites those tokens to stable placeholders before the message does, and keeps the real values on disk.


Your agent's tool outputs become its next prompt. `ls`, `git log`, `cat`, `grep` all flow back into the model, full of usernames, paths, and URLs - and most scrubbers only watch the user side. prompt-scrub scrubs every message regardless of origin.


A VPN doesn't redact the email in your prompt. Privacy at the wire and privacy at the content are different products. prompt-scrub is the second one. It scrubs what the model actually reads, not the route it travels.



A VPN hides your IP. The model still sees your prompt. prompt-scrub edits the text before it leaves your machine, so the model sees a placeholder where your email was. Different layers. They stack.


One tip for sending prompts to a cloud LLM today: scrub the message locally first, send the scrubbed copy to whatever model you use, then rehydrate the reply from the on-disk session map. Same client, same model, same network path. Three commands and your context stays local.
