
Most sponsorship buys influence. The Nano Collective's doesn't. The sponsor page and contributor resources page publish the rule upfront: funding cannot direct what gets built or who gets paid. Logo on the page, nothing at the table. The constraint is the point.



Every hour contributors spend arguing whether a new project is in scope is stolen from something already shipping. Stage 0 at the Nano Collective is a short fit conversation before any whitepaper. The friction that deters serial proposers is what protects the volunteers.



Two streams, one ledger. Every payment in and every payment out of the Nano Collective lands on a public ledger the moment it is processed. Not-for-profit, no investors. The floor, not a feature. Open the ledger before you donate.


Sponsorship gets placement, not say. Most projects can't promise that, because investors and paid tiers come with asks. MIT licence, no paid tier, no investor return are written into the Nano Collective's brand and economics charter, not a pricing call.


Pipe a file with no useful extension into get-md and it reads the bytes, not the name. `%PDF` on stdin lands it on the PDF branch, anything else falls through to HTML, so a chained shell command becomes Markdown without renaming anything. The filename is the fallback.


A rendered Mermaid diagram is gone unless the source lives in the DOM. get-md reads it back from the SVG with a strict heuristic, refusing strings like "Created with Mermaid" that mermaid.js writes into a11y nodes. Loose labels are worse than no diagram.


Under 100ms per page, no API key, no rate limit. get-md runs Turndown plus Mozilla Readability locally, so convertToMarkdown() on a URL is a single sync-feeling call. Wire it into a small loop for a long URL list, not a script that round-trips an LLM for every page.



Default 5 parallel converters sounds fast until your LLM provider starts throttling. `get-md` lets you pull it down with --concurrency 3 and keeps the same JSONL stream and manifest either way.



The migration runs, the next schema rejects the output, and the stored JSON is silently trust-me-broken. json-up runs Zod against every up() and throws ValidationError with issues pointing at the exact path, so the failing field is the message - not a generic migration failed.



Every migration library we've shipped wanted a one-time import script for pre-migration data. json-up skips the script: input without _version is treated as 0, and the first migrate() runs every step in order. The codebase picks up where it left off, by default.


A chain of sync migrations doesn't need Promise overhead. Mark up() async only when it actually awaits - a fetch, a key call. The createMigrations / createAsyncMigrations split keeps a 100-example benchmark from silently doubling its runtime on an unused async keyword.


Your catch knows the migration broke, not which step. json-up tags ValidationError, MigrationError, VersionError with a version, so the log points at the step. MigrationError adds a typed cause, ValidationError the Zod issues array.


File watchers that only run while your terminal is open aren't file watchers. nanocoder's daemon exists because subscriptions need to outlive the TUI: file.changed and schedule.cron tick on their own clock, install as a user service, run triggered work headless.


20+ model providers and you still switch tools every time the API key changes. nanocoder treats them all as one CLI - Anthropic, OpenAI, Mistral, Ollama, vLLM, whatever you have - so you swap vendors without swapping muscle memory.



Most CLI agents phone home the moment you run them. Nanocoder's default is the opposite: zero install ping, zero usage metrics, zero outbound calls you didn't ask for. Run it against a local model and your network audit shows nothing.


Most coding agents ship a separate extension per editor. Nanocoder exposes one ACP socket, so any editor that speaks the protocol drives it directly. Zed today, more later. Nothing on the Nanocoder side to keep up.


A cheap local model that cannot reliably call tools is a dead end. Turn fails, retry, fail again.

Nanocoder tries three paths (native, XML, JSON) and repairs broken output instead of failing the turn.

MCP, subagents, scheduling, Skills still work. No cloud API in the middle.


Open-ended tests usually hand you a number and trust you on the why. Nanotune's llm-judge tests put per-criterion scores and the judge's reasoning in the same markdown report a string-match test shows up in. Auditable in one place, no separate log to chase.


A fine-tune used to mean renting a box, compiling llama.cpp, and a weekend of YAML. Nanotune targets 0.5B to 1.5B models on a few hundred examples, runs LoRA on Apple Silicon via MLX, and writes GGUF without touching llama.cpp. The laptop you have open is enough.


Adding data on instinct burns evenings. nanotune benchmark writes a markdown report with a failed-tests table - read it, then data add examples aimed at those exact failures. Retrain lands on a smaller surface, not the one you guessed at.


Most failed training runs are not hyperparameter bugs. They are data bugs caught in seconds. Run nanotune data validate before you queue a training run: bad JSON, missing fields, duplicate examples, broken role alternation, minimum count flag. Cheap to run, expensive to skip.


A model performance question should never be answered on a feeling. Nanotune's loop is train, benchmark, read the markdown report (pass rate, per-test table, failed tests, timing), then data add aimed at the failures the report names, then train again.


Collision resolution is policy, not a tie-breaker. prompt-scrub states the hierarchy upfront: secrets first, PII second, identifiers third. Asymmetric on purpose. A missed token is a 3am incident. A missed email is a bug.


A path leaks the moment you run `ls`. prompt-scrub takes the whole messages array, so every tool result and outgoing turn is scrubbed, not just the prompt you typed. One hook in the message handler, no rewiring around the LLM call.


0 tokens shipped for an unscrubbed prompt that mentions an `Email_1` placeholder. prompt-scrub runs at the content layer on your machine - local CPU, no API call, no quota - and the session map is just a JSON file on disk. Detection cost is yours, not the network's.



Most privacy tools want to own your whole stack. prompt-scrub only scrubs text. Pair it with the VPN, Tor, or proxy you already trust, and call rehydrate() at the boundary you control. One primitive, composed on purpose.


Security scanners either ship rules for someone else's stack or hand you an empty editor and leave. Sentinel ships zero rule packs. You write them for the code you actually ship, so the audit is shaped by your team, not a vendor's idea of what matters.


An LLM auditor will be wrong. Build for the misses. Sentinel dedups by content hash, takes false-positive labels, and reads a per-repo sentinel.yaml, so dismissing noise is cheaper than living with it.



An audit that calls a cloud model is not a private audit. Sentinel's first-class local path (Ollama, LM Studio, llama.cpp, MLX) keeps every byte of audited code on hardware you own. Same workflow, same findings, different threat model.



An LLM might flag the same issue at lines 4–6 today and 5–5 tomorrow. Sentinel's dedup hash is rule + file + category, not range. The span still shows in the body, but it isn't the finding's identity, so re-audits update, not refile.
