DEV Community: Javier Leandro Arancibia

machin v0.140.0: scoping X-Forwarded-For trust to the proxy

Javier Leandro Arancibia — Fri, 25 Sep 2026 06:40:08 +0000

v0.140.0 is a small release — one file, 37 lines added — but one of the two changes is the kind of thing that bites you only when it matters, so it's worth a few words.

What changed

serve_on, and trust X-Forwarded-For only from the proxy (#671) — the machweb framework now scopes trust of the X-Forwarded-For header to requests that arrive through the configured proxy. serve_on is the new entry point that wires this up.
map_free: reclaim a transient map on the main goroutine's arena (#667 / #669) — a transient map allocated on the main goroutine's arena is now explicitly freed instead of lingering until the arena is torn down.
v0.140.0 — the version bump that carries the above.

Why it matters

The X-Forwarded-For change is the interesting one. The header exists so a reverse proxy can tell your app the real client IP when it terminates the connection. The problem is that the header is just text — any client can send it. If your app trusts X-Forwarded-For unconditionally, a request that never went through your proxy can still claim to be from any IP it likes. That defeats IP-based rate limiting, geo checks, allow/deny lists, and audit logs.

The fix is to trust the header only on requests you know came from your proxy — typically by checking the peer address against the proxy's address. That's what this change does. It's a small, unglamorous guard, but it's the difference between "the proxy tells me the client IP" and "anyone tells me the client IP."

The map_free change is a memory hygiene fix in the same vein: an arena allocator is a great fit for a request's lifetime, but a transient map that outlives its usefulness still holds a slot until the arena resets. Reclaiming it explicitly keeps peak memory from ratcheting up on long-lived arenas.

Neither change is flashy. Both are the kind of thing you only notice when you're debugging a spoofed-IP incident or a slow memory climb — at which point you wish you'd done them earlier.

https://github.com/javimosch/machin

A 7M-parameter model that knows when to say no

Javier Leandro Arancibia — Thu, 24 Sep 2026 05:16:56 +0000

Most requests sent to an LLM are boring. "What's the weather in Osaka", "remind me to call mom", "what's 47 times 23". A frontier model answers them beautifully — and every call costs real money and a network round-trip.

I built the opposite end of that trade-off: a 7.2M-parameter dispatcher that only does triage. It reads a request, picks a typed route, reports calibrated confidence — and when it isn't sure, it says so and hands off instead of guessing.

One call, one typed decision

POST /v1/route {"state": "remind me to call mom tomorrow at 6pm"}

→ {"action": "tool_call", "route": "set_reminder",
   "call": {"name": "set_reminder", "arguments": {...}},
   "confidence": 0.9999, "latency_ms": 6}

POST /v1/route {"state": "write me a 2000-word essay on the roman empire"}

→ {"action": "delegate", "reason": "route_escalate", "confidence": 0.96}

The gates are explicit: low confidence → delegate. Escalation head fires → delegate. Decision head and generative trunk disagree → delegate. A dispatcher that guesses wrong confidently is worse than no dispatcher.

The unusual part: zero ML framework

Tokenizer training, pretraining (AdamW/RoPE/RMSNorm/SwiGLU), fine-tuning, int8 export, and the OpenAI-compatible CPU server are all written in machin/MFL — a language designed to be written by machines. No PyTorch, no ONNX, no llama.cpp.

The shipped artifact is a static binary + an 8MB int8 model. The whole appliance tarball is 7.5MB — untar, ./start.sh, and you have typed decisions on :8097 in ~15ms per call on a laptop CPU.

Per-customer routing without fine-tunes

Decisions come from tiny linear heads (~7KB artifacts) trained on the frozen trunk's hidden state. A customer's routes are a config file of example phrases:

{"routes": {"reset_password": ["reset my password", "locked out"],
            "escalate": ["migrate our infrastructure"]}}

head_studio.py validates it, synthesizes train/eval data, trains the head, reports accuracy + ECE + confusion. Multi-tenant serving swaps heads per API key — same trunk, different router per customer.

There's a runnable proof that's a little silly and completely real: a dungeon crawler where every typed intent — light the torch, go north, equip the sword — is routed by a tenant head. The game is just another customer.

Calibration: measured, including the failure

The honest part: a head's out-of-box confidence is fit on synthetic validation data, and on off-distribution real traffic softmax saturates — in one shadow deployment, 65/72 decisions sat at conf ≥0.99 while only 61.5% were right.

So refit_temp.py ships in the repo: it refits the head's temperature on ~50+ labeled rows of your traffic, after which mean confidence tracks measured accuracy — and a head that hasn't earned trust degrades to honest abstention. "p=0.9 means right 90% of the time" is achievable on your data, not just ours.

Honest limits

7M params — it routes, it does not reason. Delegation is built in.
noul/score answer fixed trained questions; arbitrary criteria text is the roadmap.
Ambiguous human-judgment tasks need label volume, not a bigger model — a 0.6B web-pretrained backbone scored worse than this 7M trunk on one fuzzy 3-way task.
Chat replies are TinyStories-grade. It's a dispatcher, not a chatbot.

Get it

Code + appliance: github.com/javimosch/mtlm-router
Weights: Hugging Face · ModelScope
Runtime: machin-anvil

tar xzf mtlm-router-*.tar.gz && cd mtlm-router-* && ./start.sh
curl localhost:8097/v1/route -d '{"state":"remind me to stretch every hour"}'

Technical debt is a maintenance problem, not a coding problem — here's how AI agents help

Javier Leandro Arancibia — Thu, 17 Sep 2026 10:15:08 +0000

We've all been in that repo. The one where npm install prints 47 warnings, the README still references a v1 API that was renamed two years ago, three tests are skipped "for now," and the last meaningful commit on master was a merge from a branch nobody remembers. You clone it, run it, and it kind of works — until it doesn't.

We call this technical debt, but that framing is wrong. Debt implies you borrowed something on purpose and have a plan to pay it back. What most repos actually have is drift — the slow, invisible accumulation of small mismatches between what the code does, what the docs say, what the dependencies expect, and what the tests assert. Nobody chose it. Nobody owns it. It just happens, because maintenance is unpaid labor and shipping features is paid labor.

Here's the thing I've come to believe after maintaining enough projects: technical debt is not a coding problem. It's a maintenance problem. And that distinction matters, because it changes what tooling can do about it.

Why "just write better code" doesn't fix it

If tech debt were a coding problem, better engineers and better reviews would solve it. And sure, those help at the margins. But drift doesn't come from bad code — it comes from the gap between when a change is made and when the surrounding context catches up.

Consider a few examples I bet you recognize:

Stale dependencies. A patch release of a transitive dep fixes a CVE. Nobody bumps it because nothing is broken yet. Six months later you're on a version three majors behind and the upgrade is now a project.
Docs out of sync. You rename a function, update the call sites, and forget the README example. Or the architecture doc references a service that was deleted. The docs don't fail CI, so they rot silently.
Tests that lie. A test gets skipped during a refactor "to fix later." Later never comes. Now your green build is hiding a real regression.
Repo drift across services. Service A expects payload shape v2. Service B still sends v1. It works in dev because dev uses mocked data. Prod finds out at 2am.

None of these are bugs in the code. They're failures of synchronization — the ongoing work of keeping a repo coherent with itself and its environment. It's maintenance. And it's exactly the kind of work humans are bad at scheduling, because it never feels urgent.

The shape of a real solution

If the problem is maintenance, the fix isn't a smarter linter or a one-off cleanup sprint. It's a continuous maintenance loop — something that runs on a schedule, looks at the repo as a whole, and makes small, reviewable changes to keep it healthy.

A practical loop looks like this:

Observe — read the repo state: dependency manifests, test output, docs, recent commits, open issues.
Decide — figure out what's drifted and what's worth fixing right now (prioritize security > tests > deps > docs).
Act — make the change: bump a version, update a doc example, un-skip and fix a test, open a PR.
Verify — run the tests, the linter, the build. If it's red, fix it or revert.
Repeat — on a schedule, not when someone remembers.

The key insight is that steps 1, 2, and 4 are mostly mechanical, and step 3 is increasingly within reach of AI coding agents. You don't need a human to notice that package-lock.json has a CVE advisory, or that the README's install command references a flag you removed. You need something that does something about it without waiting for a sprint planning meeting.

A pattern that actually works: agents as peers, not orchestrators

Most "AI for maintenance" setups I've seen fall into the same trap: a single big prompt that says "fix my repo." That works once, badly, and then you forget it exists. The repos that stay healthy use a different pattern — multiple focused agents that each own a slice of the maintenance surface, coordinating as peers.

Instead of one agent trying to understand everything, you have:

A deps agent that watches for outdated/CVE'd packages and bumps them one at a time.
A docs agent that diffs code against docs and rewrites the stale parts.
A tests agent that finds skipped/failing tests and tries to fix them.
A hygiene agent that looks for dead code, broken links, and config drift.

They don't report to a central brain. They share a message bus, see each other's work, and avoid stepping on the same files. If the deps agent is mid-PR on package.json, the docs agent waits before touching the install instructions. This is closer to how a real on-call rotation works than how a "AI orchestrator" works.

A concrete example

Here's what this looks like in practice with AutoMaintainer, a daemon that runs this exact loop using AI agents over a peer-to-peer message bus. You register a repo with a plain-English focus and start the daemon:

# Register a repo and tell the agents what "healthy" means for it
am repo add https://github.com/you/myproject \
  --focus "keep docs in sync with code, fix failing tests, bump outdated deps"

# Enable it; runs happen on a schedule and open PRs for review
am repo enable <repo-id>

That's the whole setup. The daemon spawns an agent team per repo, each agent picks up its slice of the focus, and they start opening PRs. You review the PRs like you would any other. The agents handle the observe-decide-act-verify loop on a schedule; you stay in control of what merges.

The focus string is doing real work here. "Keep docs in sync" means something different for a library than for a microservice, and you want to be able to say "don't touch the public API" or "prioritize the test suite over dep bumps this week" without rewriting tooling. Plain English as config is underrated.

What this gets you, and what it doesn't

Let's be honest about the tradeoffs.

What it gets you: the boring 80% of maintenance happens without a human thinking about it. Deps stay current. Docs stop lying. Skipped tests get fixed or honestly deleted. You stop opening a repo after three months and finding it's a stranger. The PRs are small and reviewable, which means review is fast — you're not approving a 2,000-line "cleanup" bomb, you're glancing at a one-line version bump.

What it doesn't get you: it won't make architectural decisions for you. If your monolith needs to become services, no agent team is going to figure that out from a focus string. It also won't replace good judgment about when to take a breaking change. What it does is keep the floor clean so that when you do need to make a big move, you're not wading through six months of drift to get there.

The mental shift is this: stop treating maintenance as the thing you do when everything else is done (it never is), and start treating it as a background process that runs whether or not anyone's watching. That's literally what daemons are for.

Try it

If you have a repo that's been quietly rotting — and we all do — point a maintenance loop at it for a week and see what comes back. You'll either get a pile of small, useful PRs, or you'll learn something about what "healthy" actually means for that project. Both are wins.

# Install and register your first repo
am repo add https://github.com/you/myproject \
  --focus "keep docs in sync with code, fix failing tests, bump outdated deps"
am repo enable <repo-id>

Hosted: https://automaintainer.intrane.fr

Maintenance isn't going to stop being unpaid labor. But it can stop being invisible labor — and that's most of the battle.

100 AI Image Tools: The Complete List (2026)

Javier Leandro Arancibia — Mon, 14 Sep 2026 07:27:18 +0000

This is the complete list of all 100 AI image tools available on Crevisto. Each tool is pre-tuned for a specific use case — no prompting, no rerolling. Pick a tool, upload a photo, get the result.

Photo & Portrait Tools

LinkedIn Avatar — Professional headshot from a selfie
Profile Picture — AI-enhanced profile pictures
Age Progression — See yourself at any age
Gender Swap — Swap gender in any photo
Face Swap — Swap faces in photos
Photo Restoration — Fix old and damaged photos
Image Upscaler — Upscale images with AI
Background Remover — Remove backgrounds with AI

Art & Style Tools

Ghibli Style — Studio Ghibli art style
Oil Painting — Turn photos into oil paintings
Watercolor — Watercolor painting effect
Sketch Maker — Convert photos to pencil sketches
Pixel Art — Retro game pixel art
Cartoonify — Turn photos into cartoons

Social Media Tools

Instagram Filter — Instagram-style filters
TikTok Style — TikTok aesthetic
YouTube Thumbnail — Generate YouTube thumbnails
Social Banner — Create social media banners

Business & Design Tools

Logo Maker — Design a logo in 60 seconds
Product Photo — Enhanced product photography
Blog Header — Generate blog header images

Fun & Viral Tools

Action Figure Generator — Turn photos into collectible toys
Pet Pixar — Turn pets into Pixar characters
AI Baby Generator — See your future baby

How to use them

Every tool works the same way:

Visit crevisto.com/tools
Pick a tool
Upload a photo (or enter text for text-based tools)
Click "Generate"
Download the result

5 free credits, no credit card required. Credits never expire.

Using the CLI

curl -fsSL https://crevisto.com/install.sh | sh
crevisto trial
crevisto tools
crevisto generate action-figure --input photo=./selfie.jpg --output ./result.webp

Links: Web app · All 100 tools · CLI docs · GitHub

Crevisto CLI: A Developer's Guide to Terminal-Based AI Image Generation

Javier Leandro Arancibia — Mon, 14 Sep 2026 07:21:29 +0000

Most AI image tools live in the browser. That's fine for casual use, but developers need something different: scriptable, pipeable, automatable. The Crevisto CLI brings 100 AI image tools to the terminal.

Installation

curl -fsSL https://crevisto.com/install.sh | sh

Single binary, no runtime, no dependencies. Works on Linux, macOS, and Windows.

Quick start

# Start a free trial (5 credits, no credit card)
crevisto trial

# List all 100 tools
crevisto tools

# Generate an action figure from a photo
crevisto generate action-figure --input photo=./selfie.jpg --output ./result.webp

# Generate a Ghibli-style image
crevisto generate ghibli-style --input photo=./landscape.jpg --output ./ghibli.webp

# Generate a LinkedIn headshot
crevisto generate linkedin-avatar --input photo=./selfie.jpg --output ./headshot.webp

BYOK: Unlimited generations at cost

Plug in your OpenRouter API key and generate unlimited images at the model's actual cost. Zero credit consumption from Crevisto.

# Set your OpenRouter API key
crevisto config set openrouter_key sk-or-v1-...

# Generate with BYOK (no credits consumed)
crevisto generate action-figure --input photo=./selfie.jpg --byok

Scripting and automation

The CLI outputs JSON, making it easy to script:

# Generate and parse the result
RESULT=$(crevisto generate logo-maker --input text="MyBrand" --output ./logo.webp --json)
echo $RESULT | jq '.output_url'

# Batch process a directory
for photo in ./photos/*.jpg; do
  crevisto generate ghibli-style --input photo="$photo" --output "./output/$(basename "$photo" .jpg).webp"
done

Available tools

100 niche tools, each pre-tuned for a specific use case:

Action Figure Generator
Ghibli Style
LinkedIn Avatar
Logo Maker
Photo Restoration
Pet Pixar Style
AI Baby Generator
Gender Swap
Age Progression
Face Swap
Pixel Art
Oil Painting
Watercolor
Sketch Maker
Cartoonify
...and 85 more. See crevisto tools or the full list.

Documentation

Full CLI docs at crevisto.com/docs. Source on GitHub.

Get started

curl -fsSL https://crevisto.com/install.sh | sh
crevisto trial

5 free credits, no credit card, no subscription. Credits never expire.

I built Crevisto — 100 curated AI image tools in one platform

Javier Leandro Arancibia — Sun, 13 Sep 2026 19:22:44 +0000

Most AI image platforms give you a generic "generate image" box and leave you to craft the perfect prompt. Crevisto takes a different approach: 100 specific tools, each tuned for a particular use case.

What's in the catalog

Viral tools: Action Figure Generator (890K+ TikTok videos), AI Baby Generator, Ghibli Style, Gender Swap, Age Progression
Photo editing: Background Remover, Image Upscaler, Object Remover, Photo Restoration
Professional: LinkedIn Avatar, Resume Photo, Product Studio, Passport Photo
Creative: Photo to Painting, Renaissance Portrait, Comic Book Style, Magazine Cover, Movie Poster
Design: Logo Maker, Book Cover, Wedding Invitation, Tattoo Design, Sneaker Design

How it works

Pick a tool
Upload a photo or describe what you want
Generate — results in 30-90 seconds
Download or share

Pricing model

No subscription. You get 5 free credits on signup, then pay as you go. Credits never expire. There's also BYOK (bring your own OpenRouter key) for unlimited generations.

CLI-first

Crevisto is also a CLI tool — generate images from your terminal:

\bash curl -s https://crevisto.com/install.sh | bash crevisto login crevisto generate action-figure --photo selfie.jpg \\

The CLI is open source and works on macOS, Linux, and Windows.

Try it

5 free credits, no credit card: https://crevisto.com/register

Full catalog: https://crevisto.com/tools

Building an agent-first document database in 75KB

Javier Leandro Arancibia — Fri, 11 Sep 2026 10:26:37 +0000

Most databases are built for humans. They have consoles, dashboards, connection pools, GUI clients. They expect you to know what a tablespace is. They bill you through a web form with a credit card.

Agents don't need any of that. An agent needs JSON in, JSON out, and a bill it can settle itself.

This is the story of grange — a document database written in machin, a stack-based language that compiles to a single static binary. It has crash-safe WAL, indexes with O(1) aggregate registers, cold storage for datasets bigger than your RAM, and a hosted instance where signup is one curl with a prepaid wallet. No card on file, no subscription, no console.

The problem

I build AI agents. Agents produce structured data — leads, transcripts, tool outputs, search results — and they need somewhere to put it. The options are:

SQLite: excellent, but it's a relational database. Agents think in JSON, not in CREATE TABLE migrations.
Postgres/Mongo: production-grade, but they need a server, a connection string, a password, and a human to provision them.
Firebase/Supabase: hosted and easy, but they expect a human with a credit card and a dashboard.

What I wanted was a database that an agent could provision itself, query with plain JSON, and pay for per-call — and that I could also self-host as a single binary when the hosted rail didn't fit.

The language: machin (MFL)

grange is written in machin (MFL — Machin Forth-like Language), a stack-based language that compiles to native code via a C backend. The choice was deliberate:

Single binary: machin compiles to one static binary (musl, ~7.5 MB). No runtime, no cgo, no glibc floor. It runs on Alpine and FROM scratch.
Zero goroutines: the server is a single actor — a sequential accept loop. There is nothing to race on, and machin's inferred data-race analysis verifies that on every build with no annotations.
Maps are reference types: parking and restoring a collection's whole state is a handful of map assignments, so collection switching is O(1).

The trade-off is honest: a single-actor server means one slow query blocks everyone. That's the concurrency ceiling, and it's documented in docs/CONCURRENCY.md. For agent workloads — short, indexed, bursty — it's fine. For a thousand concurrent human users running ad-hoc analytics, it's not.

Crash-safe by construction

Every commit is one immutable, checksummed WAL chunk. The on-disk layout is:

<db>/<coll>/seg-<gen>.grg       immutable compacted snapshot
<db>/<coll>/wal-<gen>-<n>.grg   immutable WAL chunk, one per commit

Every .grg file ends with a #|<nrecs>|<sha256:12> trailer. MFL has no file append or rename, so grange never mutates a file: a commit writes a fresh chunk, compaction writes a fresh segment (verified by re-read before anything is deleted).

Recovery is simple: load the newest valid segment, replay its valid chunks in order, drop anything torn. kill -9 at any moment leaves exactly the committed prefix.

This is proven, not claimed. make crash runs 5 rounds of mid-flight SIGKILL, and recovered counts must be exact commit-batch multiples. The repo ships the harness.

O(1) aggregates: the trick that makes group-by free

This is the feature I'm most proud of. When you declare an index, you can also declare aggregate registers:

grange index --db ./data --coll leads --field status --sums score

This maintains per-group count, sum, and avg incrementally at write time. A group-by query is a map lookup:

grange agg --db ./data --group-by status --sum score

The result: group-by count/sum/avg × 1000 takes <1 ms. Not because the query is fast — because the query doesn't scan. The answer was computed at write time and stored in the index.

SQLite, doing the same group-by × 1000, takes 49 seconds.

workload	grange	SQLite
bulk insert, 2 indexes maintained	278k docs/s	25k rows/s
point get (avg of 1000)	5 µs	17 µs
indexed count × 1000	<1 ms (O(1) register)	1,937 ms
group-by count/sum/avg × 1000	<1 ms (O(1) registers)	49,114 ms
range count × 1000	<1 ms (after one-time 79 ms sort)	257 ms (indexed)
full scan, no index (worst case)	61 ms	8 ms

The one row SQLite wins is the unindexed scan — typed columns beat per-doc JSON extraction. The answer is grange index: one command, and that query class becomes O(1) or O(bucket) forever.

Cold storage: 200k docs in 4.4 MB of RAM

Hot collections hold everything in memory. That's fast but doesn't scale beyond your RAM. Cold collections are disk-resident:

grange cold --db ./data --coll archive

Cold mode uses hash-partitioned page files (the same checksummed write-once format), a bounded memtable, and streaming scans. Measured at 200k docs: 4.4 MB RSS vs 89.9 MB hot in a fresh process.

Cold collections take secondary indexes too. The index is written as value-partitioned page files, so an equality lookup reads ONE index page plus only the data pages holding its candidates. A selective lookup on 100k cold docs goes from 112 ms to 7 ms (15×).

Cold collections also take ordered (range) indexes — grange index --coll events --field ts --range — which store values sorted across pages with min/max boundary files. A range query reads only the pages whose interval overlaps it. This came from a real workload: mirroring a live analytics database showed every dashboard question is a time range, and those were full scans.

The hosted model: your agent pays its own bill

The hosted instance at grange.intrane.fr has a signup flow designed for agents, not humans:

# Get an isolated, metered namespace — the wallet IS the signup
curl -s -X POST https://grange.intrane.fr/tenants \
  -H 'X-Peage-Wallet: pw_...' \
  -d '{"name":"my agent"}'
# -> {"tenant":"t...","token":"gt_...", "pricing":{...}}

# Put a document
curl -s -X POST https://grange.intrane.fr/put \
  -H 'Authorization: Bearer gt_...' \
  -d '{"coll":"leads","doc":{"co":"acme","score":9}}'

# Query it
curl -s 'https://grange.intrane.fr/agg?coll=leads&group-by=co&sum=score' \
  -H 'Authorization: Bearer gt_...'

Each tenant gets a separate database directory on disk — separate WAL, separate collections, separate indexes. The token is the only scope key. Storage is metered at €0.15/GB/month, first 50 MB free, accrued continuously and charged to the wallet via peage. No subscription, no card on file.

The agent contract is published at grange.intrane.fr/llms.txt — the full API surface, written for machines, not for browsers.

Dogfooding: this page runs on grange

The landing page's own subscribe form is a paying tenant of the hosted instance. The flow:

User enters email on the landing form
Form POSTs to subscribe.grange.intrane.fr/subscribe (a 130-line machin app)
The subscribe service uses the machin client SDK to PUT the email into hosted grange
Every subscriber email is a document in the subscribers collection

The count is live and public:

curl -s https://subscribe.grange.intrane.fr/count
# -> {"ok":true,"data":{"subscribers":4}}

This is not a demo. It's a real workload — small, but real. The subscribe service is a separate process (a grange actor calling its own HTTP API would deadlock), which is also the honest shape of a customer.

How it's verified

The repo ships 21 test harnesses and 388 unit assertions. The interesting ones:

Differential fuzz (make fuzz): the same pseudo-random op stream is applied to a hot collection (oracle) and a cold collection, comparing entire visible state after every op. 12,000 ops across 10 seeds, zero divergence.
Mutation-tested harness: the fuzzer was validated by injecting four deliberate bugs. The first version caught only three; the state comparison was strengthened until all four fail loudly. A test that never fails proves nothing.
Crash injection (make crash): kill -9 mid-flight on cold collections, where a commit spans many files. Recovery must open cleanly, agree with filtered queries, accept writes, and survive a compaction of the recovered state.
Integrity check (grange verify): walks every file's checksum and record stream, cross-checks cold manifests against pages, confirms indexes agree with data. Detects a flipped byte, a truncated page, a missing index page.

The honest trade-offs

Single-actor server: one slow query blocks everyone. Fine for agent workloads, not fine for concurrent human analytics. Concurrent readers are future work.
Unindexed scans are slower than SQLite: typed columns beat per-doc JSON extraction. The answer is indexes — but you have to declare them.
Nobody but the author has run it: the repo has 0 GitHub stars. The operations verdict in docs/OPERATIONS.md says it's suitable for a service whose failure you can tolerate.
Linux x86-64 only: a database server needs POSIX, and machin cross-compiles to wasm and Windows, but those targets aren't useful for a server.

Try it

# Self-hosted
curl -sSL -o grange https://github.com/javimosch/grange/releases/latest/download/grange-linux-x86_64
chmod +x grange
./grange guide          # the version-exact feature catalog

# Or hosted — skip the install
curl -s https://grange.intrane.fr/llms.txt   # the full contract, written for agents

SDKs: Python, Node.js, Go, machin. All MIT.

A Stranger Filed a Bug. My AI Fixed It While I Slept.

Javier Leandro Arancibia — Fri, 04 Sep 2026 08:46:20 +0000

On July 25, 2026, a developer I'd never met opened issue #362 on my open-source project, SuperCLI. They ran the install script. It failed:

sc-machin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found

Their Linux distro shipped an older glibc. My release binaries were dynamically linked against a newer one. Classic portability bug — trivial to fix once you know the cause, but invisible until someone on a different distro tries your tool.

On August 8, the issue was closed. The fix was merged. Tested. Verified. Shipped.

I didn't touch it.

What happened between July 25 and August 8

My AutoMaintainer fleet was watching the SuperCLI repo. When issue #362 came in, the scheduler picked it up on its next maintenance cycle — the same way it picks up any open issue on a repo it maintains.

Here's what the agent did, step by step:

Read the issue — parsed the error, identified GLIBC_2.38 not found as the root cause
Oriented in the codebase — found the GitHub Actions release workflow that builds Linux binaries
Diagnosed the fix — binaries were dynamically linked; fix was to build statically with musl-gcc
Implemented the change — updated the workflow to install musl-tools, build with CC=musl-gcc --static, and verify the binary is statically linked
Bumped the version — updated install scripts and README URLs to v0.2.1-machin
Opened a PR — PR #364, with Fixes #362 so GitHub auto-closes on merge
The merger reviewed it — my ratchet merger evaluated the diff: 4 files, 13 insertions, 4 deletions. Small, safe type (fix:), CI-config-only. It passed the strict gate.
Merged — issue auto-closed

No human wrote a line of the fix. No human reviewed the diff. No human clicked merge.

Why this matters

This wasn't a toy bug on a toy project. SuperCLI is a real tool with real users — 54 stars, forks, and at least one person on a machine called ukhan-ai who needed it to work.

The traditional open-source maintainer loop:

Someone files an issue
You see it (maybe days later — you have a job, other repos)
You reproduce it (switch to their distro? spin up a container?)
You diagnose it
You fix it
You test it
You open a PR
You review it
You merge it
You release

Steps 1 through 9 took zero human hours. The agent compressed the entire maintainer loop into a single autonomous cycle. I found out when I checked my GitHub notifications the next morning and saw a closed issue with a merged PR.

The diff

The fix itself is unremarkable. That's the point.

.github/workflows/sc-machin-release.yml | 11 ++++++++++-
README.md                               |  2 +-
supercli-machin-cli/README.md           |  2 +-
supercli-machin-cli/install.sh          |  2 +-
4 files changed, 13 insertions(+), 4 deletions(-)

Install musl-tools. Build with CC=musl-gcc --static. Verify the binary is statically linked. Bump the version. That's it.

The agent didn't over-engineer it. It didn't add a Docker-based cross-distro test matrix. It didn't refactor the release workflow. It made the smallest safe diff that fixed the issue — which is exactly what I would have done.

What the agent didn't do

It didn't reply to the issue. It didn't comment on the PR with a human persona. It didn't pretend to be a person. The PR description is transparent: "Automated maintenance run by automaintainer."

It also didn't scope-creep. The instructions are explicit: "One focused fix is a complete win. Do not scope-creep." It could have noticed three other open issues and tried to fix them all in one PR. It fixed #362 and stopped.

The part I actually did

I configured AutoMaintainer to watch the repo. I set the safety rules the merger uses to decide what's safe to auto-merge. I wrote the focus prompt that tells the agent what the project is about.

That's the job now. Not writing fixes — writing the rules that let an AI write fixes safely. Not reviewing every PR — defining the boundary between "the agent can handle this" and "this needs a human."

The maintainer's role is moving upstream. From fixing bugs to designing the system that fixes bugs.

Where this goes next

One issue, one fix, one merge. It's a small thing. But it's a small thing that happened without me — while I was asleep, on a repo with real users, for a bug filed by someone I've never met.

The open-source maintainer burnout problem is real. The bottleneck has never been writing the fix — it's been the cognitive load of context-switching, reproducing, diagnosing, and following up across dozens of issues. If an AI agent can compress that loop into minutes and leave the human to handle only the judgment calls that actually need judgment...

That's the future I'm building toward. And as of August 8, it's not theoretical anymore. It shipped.

Full trail: issue #362 → PR #364 → SuperCLI repo

If you want to point AutoMaintainer at your own repos: automaintainer.intrane.fr

This post was originally published on blog.intrane.fr.

listen() returns -1 on bind failure in machin

Javier Leandro Arancibia — Fri, 04 Sep 2026 07:25:38 +0000

listen() returns -1 on bind failure in machin

A small release just landed in machin. The headline is one line, but it closes a real gap: listen() now returns -1 when the port can't be bound, so the guard you write around the return value is actually meaningful instead of silently misleading.

Before this, code that looked defensive wasn't really defending anything — the failure path never triggered, so a bind error could flow forward as if the socket were live. Now the failure is surfaced as -1, and existing if (port < 0) style checks do what they read like they do.

What changed

The diff is 12 files changed, +126/-8, and it's deliberately consistent across the spec, the implementation, the docs, and the examples:

SPEC.md — documents that listen() returns -1 when the port can't be bound.
codegen.go — the generated binding code now propagates bind failure as -1 instead of a value that hides the error.
docs/LANGUAGE.md — language reference updated to match the spec.
examples/complex/http_server.mfl — example updated so the guard around listen() is real.
examples/complex/json_api.mfl — same fix applied to the JSON API example.

The point of touching the spec, the codegen, the docs, and both examples in one commit is that the behavior, the contract, and the teaching material all agree after this. There's no window where the docs promise one thing and the compiler emits another.

Why it matters

This is the kind of fix that's easy to dismiss as cosmetic because it doesn't add a feature. It isn't cosmetic. A guard that never fires is worse than no guard at all: it makes the code look handled, so nobody looks closer, and the real failure mode shows up later as a mystery — a server that "started" but isn't listening, a port collision that silently produces a dead socket, a test that passes against the wrong process.

Returning -1 on bind failure is the smallest change that makes the existing error-handling pattern honest. If you were already writing:

port := listen(addr)
if port < 0 {
    // handle bind failure
}

…then this release is the one that makes that branch reachable. If you weren't guarding the return value, now is a good time to start.

Closing

Repo and full diff: https://github.com/javimosch/machin

Felipe — The AI CEO That Reviews My Pull Requests

Javier Leandro Arancibia — Thu, 03 Sep 2026 03:33:53 +0000

I have an AI fleet that opens pull requests on my repos every day. It builds, tests, and verifies each one before pushing. But someone still has to review and merge them. That someone was me — and I was the bottleneck.

My AutoMaintainer fleet runs 24/7. It opens PRs, rebases them, and tries to merge them automatically. About 80% get merged without human help. The remaining 20% escalate to a human-in-the-loop queue — merge conflicts the rebaser can't resolve, PRs that need a judgment call, duplicates that need triage.

Last week I checked the queue. 20 PRs waiting for my decision. The oldest had been stuck for 703 hours — 29 days. Some were duplicates of each other. Some were trivial doc fixes blocked by context drift. All needed me to type one of:

CEO: approve — merge as-is
CEO: approve rebase — try to resolve conflicts
CEO: deny — close the PR
CEO: split into <description> — break into smaller PRs

I was the bottleneck. Not because the decisions are hard — most are obvious — but because I don't check the queue every day, and 20 PRs pile up fast.

The fix: an AI persona that replaces me

I already had the infrastructure. My fleet-cli engine runs scheduled loops on a Proxmox container. The am-fleet HITL system already watches for replies on GitHub issues and applies decisions automatically. The only missing piece was someone to actually make the decisions.

So I built Felipe — a fleet persona that runs once a day, reads every stuck PR, and posts a CEO decision as a comment on the GitHub issue. The existing am-hitl-resume script picks up the reply within 5 minutes and applies it.

The whole loop is ~200 lines of bash.

How Felipe works

Once a day at 09:00 UTC, a systemd timer fires fleet-felipe-decide.service on rbm21. The script does five things:

1. Fetch the queue. gh issue list --repo javimosch/am-fleet --label mago:hitl --state open — same command I'd run manually.

2. Read each PR. For every issue, Felipe extracts the repo and PR number, fetches the diff (first 500 lines), CI status, and merge state via gh pr view and gh pr diff.

3. Ask the LLM. A structured prompt goes to devin --model glm-5-2 --print — GLM-5.2 High, which is free on Devin. The prompt includes the PR size, file list, CI status, the full diff, and the HITL issue body. The rules are explicit:

1. CEO: approve       — if PR <200 lines, CI passes, changes look safe
2. CEO: deny           — if stale >7 days, duplicate, or broken
3. CEO: approve rebase — if conflicts but valuable and <100 lines
4. CEO: split into     — if >500 lines mixing unrelated changes
5. CEO: <custom>       — anything else

4. Post the decision. Felipe parses the LLM response for a line starting with CEO: and posts it as a comment on the GitHub issue, signed "Felipe (AI CEO)".

5. The existing machinery takes over. am-hitl-resume.sh runs every 5 minutes, detects the reply, parses the decision, and applies it — approving the PR, closing it, or requesting a rebase. The HITL issue is closed. The loop is complete.

The first run: 20 PRs in 5 minutes

I deployed Felipe and triggered a manual run. It processed all 20 HITL issues in about 5 minutes:

14 × approve rebase — small PRs with trivial conflicts worth retrying
4 × deny — stale conflicts older than 7 days, too large to rebase
2 × split — 350+ line PRs mixing unrelated concerns

The decisions were good. Felipe caught that supercli#370 was a small doc-only change (24 lines, install instructions) and approved a rebase. It caught that scan-and-fill#7 was 352 lines mixing three unrelated features (amount parsing, AI caching, async refactor) and asked for a split. It denied superinsights#29 because it had been conflicting for 8 days and the conflicts spanned multiple files.

Within 10 minutes, am-hitl-resume had processed the first reply — approved PR #568, labeled it human-approved, and closed the HITL issue. The rebaser picked it up on the next cycle.

The cost: $0

Felipe uses GLM-5.2 High, which is free on Devin. Each PR review sends an ~8K token prompt (diff + metadata + rules). For 20 PRs, that's ~160K tokens in, ~5K tokens out. On a paid model like Claude Sonnet 5 Low, that would cost ~$0.40. On GLM-5.2, it costs nothing.

The quality is good enough for this task. PR review decisions are bounded — there are only 5 possible actions, the rules are explicit, and the LLM just needs to read a diff and pick one. GLM-5.2 handles this without trouble. I wouldn't trust it with open-ended architecture decisions, but for "should I rebase this 24-line doc fix?" it's more than sufficient.

The bug that almost killed it

The first version processed 1 PR and stopped. The cause was a classic bash gotcha: commands inside a while read loop consume stdin from the loop's file redirect.

The loop was while IFS= read -r issue; do ... done < issues.jsonl. Inside the loop, gh pr diff and gh issue comment were reading from stdin — which was the JSONL file. They ate the remaining lines, so read got EOF on the next iteration.

The fix: </dev/null on every command inside the loop. One redirect, three commands, 20 PRs processed.

# Before (broken — gh eats the loop's stdin)
gh pr diff "$pr_num" --repo "$repo" 2>/dev/null
gh issue comment "$issue_num" --repo "$FLEET_REPO" --body "$body"

# After (fixed — /dev/null on every subcommand)
gh pr diff "$pr_num" --repo "$repo" </dev/null 2>/dev/null
gh issue comment "$issue_num" --repo "$FLEET_REPO" --body "$body" </dev/null

Why this matters

The pattern here is bigger than PR review. It's delegation to an AI persona. Felipe has a name, a role (CEO), a decision framework, and a schedule. It doesn't replace me — I can override any decision by replying on the GitHub issue. But it handles the 90% of decisions that are obvious, so I only see the 10% that actually need human judgment.

The architecture is composable:

fleet-cli provides the scheduling and execution framework
am-fleet provides the HITL queue and decision-application machinery
Devin + GLM-5.2 provides the LLM inference, free
GitHub Issues provides the communication channel — Felipe posts a comment, the resume script reads it, no custom API needed

No new infrastructure. No new database. No new API. Just a 200-line bash script that bridges three existing systems.

Try it

Felipe is part of my private fleets repository. The fleet-cli engine is open source. The am-fleet HITL scripts are on GitHub.

If you have a fleet-cli setup and want to add Felipe, the loop is straightforward: fetch your HITL queue, read each PR, ask an LLM for a decision, post it back. The hardest part is the bash stdin bug. Now you know about it.

Next in this series: The Ratchet — how the AI merger self-unblocks 80% of PRs before escalating to Felipe.

memgraph v1.9.1: a 4-question gate before every AI memory

Javier Leandro Arancibia — Wed, 02 Sep 2026 23:14:09 +0000

memgraph v1.9.1 ships a small but consequential change: a content discipline section now lives inside the guide, and a 4-question gate runs before every memgraph remember. The headline is "memorize what code cannot tell you" — if the answer to a question is already in the source, the repo, or the commit log, it doesn't belong in memory.

The motivation is straightforward. Memory stores that duplicate what the codebase already says get noisy fast, and noisy memory is worse than no memory because agents trust it. This release pushes the filter upstream: don't write it down if you could just read it from the repo.

What changed

Content discipline section in the guide. Both the JSON and human-readable guide output now include a content discipline section, so any agent reading the guide picks up the rule set without an extra fetch.
4-question gate before every remember. Before memgraph remember commits anything, four questions check whether the content is something code itself can tell you. If it is, the memory is rejected. This keeps the memory store focused on non-obvious knowledge — decisions, caveats, deployment quirks — rather than duplicating what's already in the repo.
In-repo skill. The full skill lives at the path below, versioned with the repo and discoverable by other agents working in the same codebase:

.agents/skills/memgraph-content-discipline/SKILL.md

GitHub link in guide output. The guide now links to the full skill on GitHub, so a human reading the guide output can jump straight to the source.
.gitignore fix. A previous .gitignore rule was matching the skill directory as binary, which would have excluded it from the repo. Fixed.

The diff is 4 files changed, +152/-1. Small release, but it changes the default behavior of every remember call going forward — the gate runs unless you explicitly bypass it.

https://github.com/javimosch/memgraph

machin v0.133.0: select on Windows, concurrency CI runs there

Javier Leandro Arancibia — Fri, 14 Aug 2026 00:06:13 +0000

machin v0.133.0 is out. The headline change is small in diff size but fixes a real gap: select now works on the windows target, and the concurrency test suite actually runs in CI on Windows instead of being quietly skipped.

What changed

Two user-visible changes shipped in this release:

select works on the windows target. Previously select was not supported when building for Windows. That meant a core concurrency primitive was effectively off-limits for anyone targeting that platform, and any code relying on it would fail to build or behave incorrectly there. With v0.133.0, select is available on the windows target like it is elsewhere.
CI now runs the concurrency suite on Windows. Closing #517 and #619, the concurrency tests are no longer excluded from the Windows CI leg. This is the natural complement to the first change: now that select works there, the existing concurrency tests can actually execute and guard against regressions on that target.

The diff itself is deliberately small: 4 files changed, +37/-3, touching CHANGELOG.md, README.md, SPEC.md, and guide.go. No new dependencies, no API surface added beyond making select available where it already existed on other targets.

Why this matters

A language or runtime that supports a concurrency primitive on some targets but not others creates a subtle trap: code that works fine on the developer's machine can fail on a different target, and if CI doesn't run the relevant tests on that target, the failure only surfaces downstream. This release closes both halves of that trap for select on Windows — the primitive is implemented, and the tests that exercise it (and the broader concurrency model) now run on every CI leg where the target is built.

If you've been avoiding select in machin because you needed Windows support, that constraint is gone as of v0.133.0.

Code example

A minimal select over two channels, now valid on the windows target:

select {
case v := <-ch1:
    handle(v)
case v := <-ch2:
    handle(v)
}

Nothing new about the syntax — the change is that this now compiles and runs correctly when the target is Windows, and the concurrency tests that cover patterns like this execute in CI on that target.

Release commit: 510ff9f8608c952984f0144a8ebd75cdf99bc40e

Full changelog and source: https://github.com/javimosch/machin