DEV Community: Javier Leandro Arancibia

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

machin: make([]T, n) and make([]T, len, cap) for slices

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

A new machin release shipped, headlined by proper support for make([]T, n) and make([]T, len, cap). The slice implementation, AST, and codegen all learned the two- and three-argument forms, so you can preallocate a slice with an explicit length and an optional capacity the way you would in Go.

Alongside that, the router got a semantics pass and the coverage tooling got some rough edges filed off. The Windows target also picked up two C libraries that had been missing.

What changed

make([]T, n) and make([]T, len, cap) now work end to end (#584, #617). Touched SPEC.md, alias.go, ast.go, codegen.go, and docs/LANGUAGE.md.
Router semantics: unknown paths are now distinguishable. navigate returns -1 for unknown paths and the route table resets on init (#606, shipped as v0.130.0).
The upper bound of navigate is now guarded as well, and the new semantics are documented (#609).
machin test --cover is now advertised in the usage output and header (#615).
--cover JSON emits empty uncovered arrays instead of null (#616), so consumers don't have to special-case missing keys.
v0.129.0: SQLite on the Windows target, verified by running it (#605).
v0.131.0: zlib on the Windows target, verified by running it (#613).

A concrete example of the new slice allocation:

buf := make([]byte, 0, 4096)
rows := make([]string, n)

The first form gives you a zero-length, 4096-capacity buffer for appending; the second gives you a length-n slice ready to index and assign. Both now go through the same codegen path as the rest of the slice machinery.

Nine files changed in this release (+292/-2), mostly in the language core and docs.

Repo: https://github.com/javimosch/machin

Your homelab behind CGNAT is now reachable for free

Javier Leandro Arancibia — Tue, 11 Aug 2026 20:31:02 +0000

I built rcmd — a relay-based remote execution tool. Your server connects out to a relay; you connect to the same relay from your laptop; the relay routes commands between you. No SSH keys, no open ports, no VPN. It works behind NAT, CGNAT, corporate firewalls — anywhere that allows outbound HTTPS, which is everywhere.

Until now it was self-hosted-only: you run the relay on your own VPS, you run the daemon on your targets, you connect from your laptop. That works, but it has a gap. If you're behind CGNAT — which most home ISPs do now — you can't host the relay at home either. You need a VPS for the relay. And now you're paying €4-6/month just to forward traffic.

As of today there's a free hosted relay. Three servers, no credit card, no VPS required.

The three plans

Free (hosted) — 3 servers on rcmd.intrane.fr, no credit card. New.
Pro (€5/mo) — unlimited servers, plus cron scheduling, port forwarding, team access, webhooks.
Self-hosted (free, OSS) — run your own relay, unlimited everything, MIT licensed.

The free tier is the one that matters if you're homelabbing. Three servers covers most home setups — a NAS, a Home Assistant, a build box.

Set it up in 60 seconds

On your home server (the one behind CGNAT):

curl -sSL https://rcmd.intrane.fr/install.sh | sh
rcmd signup --free --email you@example.com
rcmd set-relay --url wss://rcmd.intrane.fr --name homeserver
rcmd daemon start -daemon

On your laptop, anywhere in the world:

rcmd login <your-token>
rcmd exec --target homeserver --cmd "uptime"

That's it. Your home server is reachable from anywhere. The daemon connected out; your laptop connected to the same relay; the relay routed the command.

What you actually get

This isn't just "run a command remotely." The relay model gives you a few things SSH doesn't:

Fast file transfer

rcmd cp --target homeserver --src ./config.yaml --dst /etc/app/config.yaml

Files stream through the relay in 2 MiB chunks with adaptive gzip and parallel streams. I benchmarked it faster than scp over high-RTT links — the relay's async write queue forwards chunk N to the target while the client sends chunk N+1, so the pipeline stays full. Directories are auto-tarred. No base64, no buffering the whole file in memory.

Port forwarding (tunnels)

rcmd tunnel --target db --local 5432 --remote 127.0.0.1:5432

Replaces ssh -L. Forward a local port to a remote address through the relay. Reach that database behind NAT without a VPN or a bastion.

Multi-target fan-out

rcmd exec --targets nas,homeassistant,buildbox --cmd "df -h" --format json

One command across every server. Results back as JSON — one per target, with stdout, stderr, exit code, and duration. No parsing SSH output, no parallel-SSH wrapper.

AI-agent native

Every command returns structured JSON. Deterministic timeouts. No parsing, no guessing, no wasted tokens. If you're building agents with Claude Code, Cursor, or Devin, you give the agent a token instead of an SSH key. I wrote about the security argument separately — but the short version is: an SSH key is a permanent credential with no scoping. A token is a revocable credential with per-target permissions.

Why not just self-host?

You can. The self-hosted relay is free and MIT licensed, with unlimited targets and all features unlocked. But self-hosting means you need a machine with a public IP to run it on — which, if you're behind CGNAT, is exactly the problem you're solving. You'd need a VPS for the relay, and now you're back to paying for a VPS.

The free hosted tier breaks that loop. I run the relay. You use it for free. Your home servers connect out to it. You reach them from anywhere. No VPS for you, no CGNAT problem, no credit card.

If you outgrow 3 servers — you add a fourth machine, or you want cron scheduling for backups, or you want to share access with a teammate — Pro is €5/month and removes the limit.

What the relay can and can't see

Fair question: if all my traffic goes through a relay, what can the operator see?

Commands and output pass through the relay, but they're not stored — the relay routes frames in memory and drops them when delivered. The relay authenticates both sides with tokens; it doesn't have your SSH keys because there are no SSH keys. If that's still too much trust, self-host the relay and keep everything on your own infrastructure.

Who this is for

Homelabbers behind CGNAT who want to reach their machines without a VPN mesh or a VPS tunnel.
People with 2-3 VPSes tired of maintaining SSH config, key rotation, and bastion setup.
AI agent builders who need their agent to run commands on remote machines without SSH keys.

Try it

curl -sSL https://rcmd.intrane.fr/install.sh | sh
rcmd signup --free --email you@example.com

Three servers, no credit card, no VPS, no CGNAT workaround. Landing page: rcmd.intrane.fr. Source: github.com/javimosch/remotecmd-cli.

Previously: Stop Giving AI Agents Your SSH Keys — the security argument for the relay model. remotecmd parallel streams, faster than scp — the file transfer benchmark.

I benchmarked my language against Rust and Zig, and deleted my best number

Javier Leandro Arancibia — Fri, 07 Aug 2026 12:36:17 +0000

I benchmarked my language against Rust and Zig, and deleted my best number

I have been building machin for a while — a Go-flavored, type-inferred language that compiles through C to a single native binary. It has grown a lot recently, and I wanted to answer the obvious question honestly: does it beat Rust and Zig at anything?

It does, at two things, decisively. But the first thing I found was not a win. It was my own benchmark quietly lying to me, and the number it was lying about was the best one I had.

The benchmark was measuring the order I ran things in

machin's repo has had a bench/native-speed suite for months: four compute kernels — recursive fib, a mandelbrot, a sieve, a big integer loop — written in machin, Rust and Zig, producing byte-identical output, so the timing compares the same computation three ways. The published result claimed machin won the integer loop by 20-25%. That claim also shipped inside machin guide, which is what every coding agent reads to learn the language.

When I re-ran it, the margin was gone. Not shrunk — gone. So I read the harness instead of the output:

for kernel in kernels:
    for lang in [machin, rust, zig]:
        for _ in range(5):    # all 5 machin, THEN all 5 rust, THEN all 5 zig
            time(binary)

It ran every sample of one language before starting the next. On a laptop that heats up and down-clocks during a three-second kernel, that does not measure the languages. It measures who had the misfortune of running last. Zig always went last. Zig always looked slowest.

The fix is four lines — interleave the rounds, rotate who starts each one. Here is what my headline number did:

intsum 10^9      before (blocked)     after (interleaved)
machin              2832 ms                3079.7 ms
rust                3764 ms                3223.8 ms
zig                 3556 ms                3189.7 ms
                 "machin +20-25%"        machin +3% = a TIE

A 20-25% win became a tie. I deleted the claim from the README and from machin guide. The harness now also refuses to declare a winner inside a 3% band, because the worst run-to-run spread I measured was 41% of the min sample. Calling winners inside that is how benchmarks start lying in the first place.

So what does machin actually win?

Two things, and neither is raw speed. On the four kernels machin wins one clearly (recursion, 26% faster than both), ties two, loses one. Same tier as Rust and Zig — it compiles to C, so it runs about as fast as C, and so do they.

1. It tells you about the bug before you run it

A program that waits for a value that can never arrive. In machin it's a receive on a channel nothing sends to; in Rust rx.recv() with the sender alive; in Zig sem_wait on a semaphore nobody posts. Same program:

machin   DL001 at COMPILE time: "receive on channel `ch` that is never
         sent to or closed - a guaranteed deadlock"
         ...and at runtime, exit 2 with the wait-cycle:
           fatal: deadlock - all 1 goroutine(s) blocked
             goroutine 0   waiting to receive on channel #0

rust     compiles clean, no diagnostic -> HANGS FOREVER (killed at 5s)
zig      compiles clean, no diagnostic -> HANGS FOREVER (killed at 5s)

This deserves precision, because it's easy to overclaim. Rust's type system prevents data races. It has never claimed to prevent deadlocks, and that recv() is idiomatic, unsafe-free, well-typed Rust. Zig doesn't attempt either.

Same for an out-of-range index: machin falsify enumerates small concrete inputs and hands back one that breaks the function — before the program runs, on code whose only call site is in range. rustc and zig say nothing.

Neither analysis proves absence, and I don't want to imply otherwise. falsify is unsound-complete: every counterexample it reports is real, but a clean result means "no bug within the bounds", never "correct". DL001 is the opposite trade — sound and false-positive-free, so it only fires when it can prove a channel is never fed, which means a clean result isn't a proof of deadlock-freedom either. "machin found nothing" is a much weaker statement than "machin found this bug, here's the input".

2. Binary size

stripped, both dynamically linked against system libc:

  machin      14 kB
  rust       335 kB

No std runtime to link — machin's output is C, and C's runtime is already on the machine. Note the comparison I did not make: unstripped it's 17 kB vs 4291 kB, about 250x. That number is bigger and worse, because it mostly measures how much debug info each toolchain leaves in.

And here is the correction I owe that 24x, which I only caught by going back and asking what it actually measures. It compares each toolchain's fixed floor, not how they scale:

program            machin        rust
hello world       14,544 B    343,568 B
fib(40)           14,544 B    335,472 B
a JSON+HTTP app   26,840 B          -

machin's hello world and its fib are byte-identical in size; Rust's differ by 2%. Neither number measures the program — both measure the baseline each toolchain links in, and real code adds real bytes to both. So the honest form is "Rust starts about 320 kB ahead", not "machin binaries are 24x smaller". The ratio shrinks as programs grow; the offset persists.

And what it loses

A benchmark suite that only lists wins is marketing.

Build time: Rust wins. Bare rustc -C opt-level=3 builds these kernels in ~57 ms; machin takes ~95-116 ms, because its number includes the cc -O2 backend run. I deliberately did not use cargo, which would have charged Rust for lockfile resolution and made machin look good for a bad reason.
Default runtime safety: Rust wins. Given an out-of-range index, Rust traps (exit 101). machin's default build prints a silent wrong 0 and exits successfully — exactly like Zig's ReleaseFast, which read 281479271677952 out of adjacent memory. Both need an opt-in to trap.
Fully static, Zig wins — by far more than I first reported. I originally wrote "491 kB against machin's 940 kB", about 2x. That 491 kB came from Zig 0.16.0, which inflates it ~32x. On 0.15.2 the fully static stripped binary is 16 kB — about the size of machin's dynamic one, needing nothing on the target — and ~60x smaller than machin's own --static build. The size win in this post is over Rust, not over Zig.

That second one matters enough to repeat, because I got it wrong first. My initial version compared machin --safe against Zig ReleaseFast — machin's checked mode against Zig's unchecked one — and machin looked safe by default. It is not.

The sieve: three months of a wrong explanation

machin has always trailed on the sieve by ~1.4x, and the README explained it confidently: "its slice indexing/layout is less optimal than a Rust Vec or a Zig slice." That was wrong, and nobody checked because the conclusion sounded plausible.

Timing the phases took ten minutes:

phase                              machin      rust
build the 10M array by append     70-83 ms   27-29 ms
the sieve loop itself              110 ms     111 ms   <- dead tie
the count loop                     5-7 ms       3 ms

Slice indexing ties Rust exactly. The entire gap is append growing the array: machin's arenas free nothing mid-life, so growing a slice can only allocate a fresh block and memcpy into it, ~21 times, never releasing the old buffers. Vec::push hands the block to realloc, and glibc extends it in place via mremap.

So I wrote the obvious fix: when the block being grown is the arena's most recent allocation, hand it straight to realloc. Then I checked one thing before shipping — whether MFL slices share backing storage:

a := []int{1, 2, 3}
b := a          // b[0] changes when a[0] does -> they SHARE
mutate(c)       // params share too

They do. Today, when append abandons a block, every existing alias keeps pointing at it and keeps reading valid memory, because the arena never frees. With in-place growth those aliases become use-after-free the moment the block moves. I had written a 45 ms speedup that trades a benchmark number for silent dangling reads — in a language whose entire pitch is catching that class of bug.

I threw it away and filed issue #578 with the directions that could actually be sound. That fix has since landed — see the update at the end.

What the claim actually is

Not "machin is faster than Rust" — same tier, and it loses a kernel. Not "machin is safer than Rust" — Rust traps by default and machin does not.

The claim is machin tells you earlier. A deadlock that Rust and Zig discover as a hung process in production, machin reports at compile time with the wait-cycle. An out-of-range index neither mentions, machin hands you with a concrete failing input. That's a real difference, worth real debugging time, and it's a different claim from Rust's rather than a bigger one.

Every number is reproducible — sources for all three languages, the harnesses, and a run.sh per benchmark. Start at docs/BENCHMARKS.md, which indexes all seven benchmarks and states the losses next to the wins.

If you re-run them and get different numbers, I'd genuinely like to know. That's rather the point of shipping the harness.

Postscript: I ran it all on a second machine

Every number above came from one laptop with 41% worst-case run-to-run spread, and I'd told readers that "the ratios are the portable result" without ever testing that. So I wired the suite into CI and ran it on a GitHub runner — AMD EPYC, different compilers, much quieter (15% spread).

The verdicts are portable. machin still wins recursion (26% → 28%), mandelbrot and intsum are still ties, the sieve was still a loss at the time of writing (it has since been fixed — see the update below), and every compile-time result (DL001, FALS001, who hangs, who traps) reproduces exactly.

The precise ratios are not. The sieve gap moved from 1.46x to 1.32x — a ~10% swing, which fits its cause: it's append faulting in fresh pages, the most memory-sensitive thing in the suite, and the EPYC has a better memory subsystem.

And it caught the Zig size error above, which is the entire reason for running it.

Update: the sieve now ties Rust

Everything above described the sieve as machin's remaining loss, and explained it correctly as append rather than indexing. That gap is now closed, and it's worth saying how, because the interesting part isn't the speedup.

The unsound version — hand the arena's newest block to realloc — was the easy 45 ms. Making it safe meant answering one question per slice: does any other live reference observe this backing array?

The design decision that mattered was the failure direction. The tempting implementation is a dynamic shared bit on the slice header, set wherever the compiler copies one. Less code — but it fails open: a copy site nobody thought of leaves an alias unmarked, and an unmarked alias is silent memory corruption. So instead: a static whitelist where every operation on a candidate must be a form that provably cannot leak a reference, and anything unrecognised refuses the slice. The cost of a case nobody thought of becomes a missed optimization instead of a dangling pointer.

I shipped that analysis first as a report — machin alias — that changed no generated code at all. Which is how I found out my first version was useless:

module	flow-insensitive	flow-sensitive
bson.src	~0	2 of 2
xml.src	~0	5 of 10
reactive.src	~0	3 of 10

It was sound, and it fired on almost nothing real. "Build it, then use it" is the dominant shape — append in a loop, then hand the finished slice to a helper — and that aliasing use happens after the last append, where it cannot observe a moved array. Had I gone straight to codegen I'd have shipped something that optimized my own benchmark and essentially nothing else.

Then the net, before the thing it catches: seven programs that keep a live alias across an append, run under AddressSanitizer in CI. I verified it catches the bug by re-applying the unsound version and watching it go red — rather than assuming a green suite meant anything.

Only then the codegen. Two guards the static proof can't express: growth is attempted only on the arena's most recent block, and the substr length cache is invalidated on that path, because it keys on pointer identity and realloc hands an address back to the allocator. Missing that second one would have been a silent wrong-length bug in substr() — about as far from append as a bug can land.

Measured on a CI runner rather than my laptop (which was at 58-68% run-to-run noise by then), normalized against Rust because the runner itself drifted ~15% between sessions:

              machin      rust       zig    machin/rust
  before      96.7ms    87.7ms    73.0ms       1.10x
  after      101.9ms   100.6ms    86.0ms       1.01x

The sieve ties Rust. It does not tie Zig, which is still ~1.19x faster on this kernel — down from 1.32x, but a real remaining gap, and I'd rather report it than round it into the headline.

Shipped in v0.128.0.

My database claimed crash-safety. `kill -9` proved nothing.

Javier Leandro Arancibia — Wed, 29 Jul 2026 18:19:04 +0000

I have a small document database called grange. Its README said "crash-safe by construction", and there was a harness to back it up: kill the writer with kill -9 mid-flight, reopen, assert the database holds exactly a committed prefix. Five rounds, every build, green.

That harness proves less than it looks like it proves.

What `kill -9` actually tests

When you kill -9 a process, the kernel reclaims it — but everything the process wrote with write(2) is already in the page cache, and the kernel flushes it to disk afterwards on its own schedule. The data survives because the operating system survived.

A power cut is different. So is a kernel panic. There, the page cache goes with the machine, and anything not yet on the platter is gone.

My database called write_file and returned success. Nothing anywhere called fsync. So a commit that had been acknowledged — the client got its {"ok":true} — could vanish. The harness could never have caught it, because the failure mode it simulates is the one the page cache is immune to.

The README even said so, in a line I'd stopped reading:

Durability is process-crash-exact (proven by make crash), OS-crash best-effort.

That sentence is true and completely insufficient. "Best-effort" is doing a lot of work there.

Two fsyncs, not one

The fix is fsync, and the part that's easy to get wrong is that one call isn't enough.

write_file(path, data)
fsync(path)        // the file's CONTENTS are durable
fsync(dirname)     // the file's EXISTENCE is durable

Creating a file is a modification of its directory. You can fsync a file perfectly and still lose it after a crash, because the directory entry naming it never reached the disk. The second fsync is the one people skip.

A directory has to be opened O_RDONLY for this — opening it for writing fails with EISDIR.

Testing something invisible

Here's the awkward part: fsync is invisible to behavioural tests. A build that silently dropped every fsync call would pass my entire test suite. Same answers, same recovery, same everything — right up until the power goes out.

So the test doesn't check behaviour. It checks syscalls:

strace -f -e trace=openat,fsync ./db put ...

then asserts the ordering: the chunk is fsynced, then its directory. And on the disk-resident path, that every data page is fsynced before the manifest that references it — because "write the manifest last" is only meaningful if that ordering is real on the platter, and the kernel is free to reorder write() calls on the way there.

The third check is the one I'd encourage you to steal: the opt-out (FSYNC=0) must issue zero fsyncs. That doubles as the harness's own negative control. A test that can't fail is decoration, and a test asserting the presence of something invisible needs to prove it can detect the absence.

What it costs

Measured, on a commit:


single-document commits	~1.9 ms each — about 31% slower
a 10,000-document batch	21 ms vs 23 ms — noise

That shape is why it's on by default. A batch is one commit, so durability amortises to roughly nothing on the workload that actually moves volume. The per-commit case pays, and that's the honest price of the guarantee.

What I still can't claim

The device might be lying. Consumer drives with volatile write caches can acknowledge an fsync that's still in flight, and no test running on that machine can tell. So the docs now say: fsync is called, the ordering is asserted, and whether your hardware honours it is not something this project can prove.

That felt more useful than upgrading the marketing adjective.

The general lesson

The harness wasn't wrong. It tested a real failure mode, correctly, and it still passes. It just wasn't testing the failure mode the word "crash-safe" makes people imagine — and the gap between those two things sat in my README for months, written down, in a sentence I'd read so many times I stopped seeing it.

If you have a durability claim, go and check what your test kills. kill -9 and "pull the plug" are not the same experiment.

grange is MIT, a single static Linux binary, and usable either as a server or compiled into your own program: github.com/javimosch/grange. v0.11.0 also brings ordered queries, keyset pagination and field projection.

I built a 100 KB git-like VCS that beats git on `add && commit`

Javier Leandro Arancibia — Sun, 26 Jul 2026 05:42:26 +0000

I love git. I also spend a lot of time automating things, and every time a script needs to snapshot some files I end up wrapping git with brittle flags and parsing porcelain output. So I wrote lume: a tiny, content-addressed version control system in machin/MFL.

lume is git-like, not git-based. It uses blobs, trees, commits, refs, and HEAD, but the storage, object format, and HTTP protocol are built from scratch. The whole thing compiles to a single 100 KB native binary.

The benchmark that surprised me

I compared the one workflow every developer repeats all day:

lume add . && lume commit -m "x" → ~15 ms
git add . && git commit -m "x" → ~17 ms

On 110 small files, lume is faster. The lume binary is ~36× smaller than git (100 KB vs 3.7 MB), and the .lume metadata is within 2% of .git.

Where the speed comes from

The biggest win was replacing the SQLite staging index with a line-delimited file. lume add now builds a small tab-separated string and writes it once. Object subdirectories are created lazily, and blobs use a hand-rolled JSON fast path instead of generic serialization.

HTTP push / pull / clone out of the box

lume serve starts a tiny HTTP object server. push, pull, and clone speak plain JSON-over-HTTP. No SSH keys, no pack negotiation, no stateful transport.

What's next

Merge, rebase, and diff are still missing, and the tooling is Linux-oriented right now. But the core agent loop — init, add, commit, push, pull, clone — is fast enough to run behind automation without the automation ever knowing it is talking to a VCS.

I wrote a longer post with the architecture and numbers on the Intrane blog.

Source, benchmarks, and build instructions are on GitHub: github.com/javimosch/lume

rcmd now speaks MCP — your AI agent can manage your servers without SSH

Javier Leandro Arancibia — Sat, 18 Jul 2026 19:28:44 +0000

I've been building rcmd, a relay-based remote command tool. No SSH keys, no open ports — your servers connect out to a relay, and you send commands through it.

Today I shipped the thing I've wanted since day one: an MCP server.

What is MCP?

Model Context Protocol is the standard way AI agents (Claude Code, Cursor, Windsurf, Devin) call external tools. Instead of shelling out to ssh user@host "df -h" and parsing text, the agent calls a structured tool and gets JSON back.

What rcmd's MCP server exposes

Four tools:

rcmd_list_targets — list your configured servers
rcmd_exec — run a command on a remote server, get stdout/stderr/exit code/duration
rcmd_cp — copy a file to a remote server
rcmd_health — check if a server is reachable + latency

How to set it up

Install rcmd and configure a target:

rcmd add-target --name prod --token <token>

Add rcmd as an MCP server. For Claude Code (~/.claude/mcp.json):

{
  "mcpServers": {
    "rcmd": {
      "command": "rcmd",
      "args": ["mcp"]
    }
  }
}

Same config for Cursor (.cursor/mcp.json) and Windsurf (~/.codeium/windsurf/mcp_config.json).

That's it. Your AI agent can now run commands on your servers.

What this looks like in practice

You ask Claude: "Check disk space on prod"

Claude calls rcmd_exec with {"target": "prod", "command": "df -h"} and gets:

{
  "target": "prod",
  "command": "df -h",
  "stdout": "Filesystem      Size  Used Avail Use% Mounted on\n/dev/vda1       40G   28G   11G  73% /",
  "exit_code": 0,
  "duration": "142ms",
  "success": true
}

No SSH parsing. No "which server was that again?" No key management.

Why this matters

I built rcmd because SSH is friction for AI agents:

Keys need to be on the right machine
Firewalls block inbound ports
NAT makes connecting impossible without a VPN
Parsing terminal output wastes tokens

rcmd's daemon connects out to a relay. No inbound ports. No keys on the agent's machine. The MCP server reads your local rcmd config and handles the rest.

The agent never sees your tokens. It only sees target names. All traffic goes through the relay with token-based auth.

Self-host or use the hosted relay

The relay is open source (MIT). You can self-host it in 5 minutes — one binary, one port, done. Or use the hosted one at rcmd.intrane.fr for €5/mo.

Full self-hosting guide: https://github.com/javimosch/remotecmd-cli/blob/main/docs/self-hosting.md

MCP server docs: https://github.com/javimosch/remotecmd-cli/blob/main/docs/mcp-server.md

What's next

More MCP tools (cron management, tunnel setup, team operations)
Resources (expose server state as MCP resources, not just tools)
Streaming output for long-running commands

The binary is ~6MB, single file, no dependencies. Linux + macOS, amd64 + arm64.

# Download from GitHub releases
# Or: curl -sSL https://github.com/javimosch/remotecmd-cli/releases/latest | ...

GitHub: https://github.com/javimosch/remotecmd-cli

rcmd is agent-first infrastructure. Every command returns structured JSON. Every feature is designed to be called by an AI, not just a human. The MCP server is the natural endpoint of that design.

Web Analytics With No Dashboard (But There Is a 3D Globe)

Javier Leandro Arancibia — Sat, 18 Jul 2026 18:27:07 +0000

I built vigie — cookieless web analytics where the primary consumer is an AI agent, not a human staring at charts.

The premise

Every privacy-first analytics tool (Plausible, Fathom, Rybbit) assumes a human logs into a dashboard. My team is agents: they write the code, send the email, file the issues. They need analytics they can query and act on — JSON on stdout, semantic exit codes, a machine-readable API.

vigie stats overview --site example.com --since 7d
# {"ok":true,"data":{"pageviews":1234,"visitors":410,"bounce_rate_pct":38,...}}
vigie stats cities --site example.com     # geo down to city + coordinates
vigie stats journeys --site example.com   # the sankey, as JSON
vigie stats vitals --site example.com     # LCP/FCP/CLS/INP/TTFB p50/75/90

When a human needs to see it

The dashboard is an artifact: vigie snapshot --publish renders every metric (22 sections — journeys, channels, heatmap, vitals, errors, geo to city…) into one self-contained HTML page and publishes it to an artifact host. Regenerated on a timer, never stale, no frontend server to run. Fully-populated demo report here (synthetic data, labeled).

And one indulgence: your traffic as a living 3D globe — hand-rolled canvas math, city-level dots, repaints itself from the live feed. Zero JS frameworks.

The interesting constraints

Cookieless by construction: visitor = sha256(secret + day + site + ip + ua), daily salt rotation, raw IP never stored. Nothing to consent to.
Agents are users too: vigie track --name deploy --actor ci records server-side events — your cron job is a first-class analytics stream.
One ~300 KB binary (HTTP ingest + SQLite + stats engine + globe renderer + CLI), written in MFL, no Node/ClickHouse/Docker.
Geo without a SaaS: a MaxMind-DB (.mmdb) reader written from scratch in MFL, reading DB-IP City Lite (CC BY). ~300 lines for the binary tree walk + data-section decoder.

An agent built the whole thing in a day, and found three compiler bugs in the process — including string literals silently corrupted by C trigraph processing (?? became ^ in the globe JavaScript, surfacing as a browser SyntaxError three layers away).

Full story: https://blog.intrane.fr/analytics-with-no-dashboard
Repo (MIT): https://github.com/javimosch/vigie

I built a database my AI agent can pay for (and it beat SQLite)

Javier Leandro Arancibia — Sat, 18 Jul 2026 13:03:35 +0000

Every database assumes a human shows up eventually — to create the account, paste a card, click through a console. AI agents can't do any of that. So I built grange: a document database where a payment wallet is the signup.

curl -X POST https://grange.intrane.fr/tenants -H 'X-Peage-Wallet: pw_...' -d '{"name":"my agent"}'
# -> {"tenant":"t...","token":"gt_..."}   your isolated, metered namespace

Pricing is pay-as-you-go: €0.15/GB/month above 50 MB free, queries free, billed continuously through péage — no subscription, no card on file, no human in the loop.

The engine

grange is written in machin, my language for AI agents, and two properties fell out of the language rather than being engineered in:

Crash-safe by construction. The language has no file append or rename, so every commit is one immutable, sha256-trailered WAL chunk. kill -9 at any moment leaves exactly the committed prefix — the repo ships the harness that proves it.
Race-free by proof. The server is a single actor with zero goroutines, and machin's inferred data-race analysis verifies the whole engine on every build. No Send/Sync, no annotations.

The benchmark (100k docs, both engines indexed, same box)

workload	grange	SQLite
bulk insert, 2 indexes maintained	278k docs/s	25k rows/s
indexed count × 1000	<1 ms	1.5 s
group-by count/sum/avg × 1000	<1 ms (write-time registers)	49 s
range count × 1000	<1 ms	257 ms

The aggregate rows aren't typos: declare --sums on an index and grange maintains per-group count/sum/avg at write time — a group-by answer costs a map lookup. The one row SQLite wins (unindexed full scan, 8ms vs 61ms) is in the README too, because a benchmark you can't lose is marketing, not measurement. make bench reproduces everything.

Dogfooding found three compiler bugs in one day

This is why I build real things in my own language. The first bench ran 70× slow — stale compiler binary, maps were O(n). The billing math went negative — integer literals compiled to bare C constants and 30 * 86400000 overflowed in 32-bit before widening. A WAL tombstone turned to garbage — keys(map) aliased internal storage that delete() freed: a use-after-free handed to me by a failing test. All three fixes went back into the language.

For humans: client SDKs

Agents speak curl; humans expect drivers. So: Node.js (npm i grange-db), Go (go get github.com/javimosch/grange/sdk/go), and machin. Same surface: db("crm").coll("leads"), put/get/find/count/agg, bulk writes at 263k docs/s over HTTP.

The full story is on my blog: grange: A Database Your Agent Can Pay For. The contract, written for agents: grange.intrane.fr/llms.txt. MIT, one binary, no lock-in.

rcmd: I replaced SSH with a relay — now my AI agents manage my servers

Javier Leandro Arancibia — Sat, 18 Jul 2026 03:51:56 +0000

I run a small infrastructure. A few VPS, some Proxmox boxes, a Raspberry Pi. Every time I needed to run a command on a remote machine, it was the same ritual: SSH key, port, firewall, VPN if the box is behind NAT. And my AI agents? They couldn't do any of it without me handing them SSH keys or setting up tunnels.

So I built rcmd — a zero-config remote command execution tool. No SSH keys, no open ports, no VPN. A WebSocket relay brokers connections between your machine and remote targets. The daemon on the target connects outbound. You run the CLI. The relay routes the command.

You ──wss──► relay ──wss──► target daemon (runs your command, returns output)

What shipped this week

Scheduled commands (cron)

rcmd cron add --target prod --schedule "0 3 * * *" --cmd "docker restart app"
rcmd cron list
rcmd cron logs --id <job-id>

The relay runs a scheduler goroutine. When a job fires, it forwards the command to the target daemon. If the target is offline, the run is logged as "skipped" — no retry queue, the next tick tries again. History persists across relay restarts.

This replaces the crontab + SSH + monitoring script combo with one command.

Port forwarding (tunnel)

rcmd tunnel --target db --local 5432 --remote 127.0.0.1:5432

Forwards a local port to a remote address through the target daemon. Replaces ssh -L. Useful for reaching a database or service that's only listening on localhost on the remote machine.

Team access

This is the one I'm most excited about. The problem: one token = full access to all targets. If you want a teammate or an AI agent to run commands, you either share your master token (security nightmare) or set up a separate account (no shared targets).

Now you generate scoped sub-tokens:

# Give an operator access to prod + staging
rcmd team token --role operator --targets prod,staging --label "Bob" --expires 24h

# Bob runs:
rcmd login tok_operator_abc123...
# His access is scoped — he can only touch prod + staging, all audited

Three roles: admin (everything except billing), operator (exec, copy, tunnel, cron on assigned targets), viewer (read-only — list targets, check health, view cron logs).

Every command execution is recorded in the audit log:

rcmd team audit --target prod --since 24h

Email invites

rcmd team invite --email bob@company.com --role operator --targets prod,staging --label "Bob"

Sends an HTML email with a 7-day invite code. Bob clicks the link, sees a page with the accept command and a copy-to-clipboard button, runs:

rcmd team accept inv_5b97e6eeb72d

Gets a scoped sub-token. Done.

Agent-first discovery

This is the part that matters if you're building tools for AI agents. rcmd is designed to be operated by agents, not just humans. So I added three discovery surfaces:

/llms.txt — a short breadcrumb at rcmd.intrane.fr/llms.txt. An AI assistant that only knows the domain fetches this and gets oriented.
/guide — the full operator reference. Every command, every flag, cron scheduling, tunnels, team access, JSON output format, exit codes, gotchas.
rcmd guide — CLI subcommand that prints the same guide locally. An agent on a machine with rcmd installed runs this to learn the full feature surface.

The pattern: an agent finds itself on a machine with rcmd → runs rcmd guide → learns everything. An agent that only knows the domain → fetches /llms.txt → gets pointed to /guide.

Why no SSH?

SSH is designed for humans typing into terminals. It's not designed for:

Agents that need to run commands programmatically and parse output
NAT traversal — if the target is behind NAT, you need a VPN or a jump host
Scoped access — SSH keys grant full shell access; there's no easy way to say "this agent can only restart this one service on this one server"
Audit trails — SSH logs connections, not commands (unless you set up auditd or similar)

rcmd solves these by moving the routing to a relay. The daemon connects outbound (no firewall changes). Tokens are scoped (admin/operator/viewer, target-restricted). Every command is audited. And the CLI is designed for agents — JSON output, semantic exit codes, a guide command that teaches the agent everything it can do.

The stack

Go binary, single file, ~7MB stripped
WebSocket relay (runs on a VPS, behind Traefik + Let's Encrypt)
JSON file storage (no database — teams, cron jobs, audit logs, customers)
Resend for transactional email (team invites)
Stripe for billing (Pro tier)
21 unit tests, all passing

Try it

curl -fsSL https://rcmd.intrane.fr/install.sh | sh
rcmd signup --email you@example.com

The free tier gives you the relay. Pro adds scheduled commands, tunnels, and team access.

Full reference: rcmd guide or https://rcmd.intrane.fr/guide

GitHub: https://github.com/javimosch/remotecmd-cloud

Built by Javier Leandro Arancibia — making infrastructure agent-first, one tool at a time.

I replaced ssh -L with one CLI command. No SSH keys, no VPN, no open ports.

Javier Leandro Arancibia — Fri, 17 Jul 2026 11:56:31 +0000

If you manage servers, you've done this a thousand times:

ssh -L 5432:localhost:5432 user@prod-server

It works. But it requires SSH keys, an open port 22, a VPN if you're behind NAT, and a running SSH daemon on the target. Every one of those is a maintenance burden and an attack surface.

I just shipped rcmd tunnel — port forwarding through a WebSocket relay. No SSH, no VPN, no open ports.

How it works

Your laptop ──wss──► Relay ──wss──► Target daemon ──► localhost:5432

The target runs a tiny daemon (~6 MB Go binary) that connects outbound to a relay. Your client connects to the same relay. The relay routes TCP data between them. That's it.

Both sides connect outbound. No inbound ports. Works behind NAT, firewalls, corporate proxies.

The command

rcmd tunnel --target prod --local 5432 --remote localhost:5432

Now localhost:5432 on your machine tunnels to prod:5432. You can connect with psql, redis-cli, a browser dashboard — anything that speaks TCP.

What you can tunnel

PostgreSQL — --local 5432 --remote localhost:5432
Redis — --local 6379 --remote localhost:6379
Debug dashboards — --local 8080 --remote localhost:8080
Jupyter notebooks running on a remote GPU box
Internal admin panels behind a firewall
Any TCP service — if it speaks TCP, rcmd tunnels it

But wait, I already have SSH

So did I. Here's why I built this:

SSH requires port 22 open. Every server with an open SSH port is a brute-force target. rcmd's daemon connects outbound — zero inbound ports.
SSH key management is a tax. Rotate keys, distribute them, revoke them, deal with known_hosts pollution. rcmd uses per-target tokens, auto-generated, no files to manage.
SSH doesn't work behind NAT. If your server is behind a corporate firewall or NAT, you need a VPN just to reach it. rcmd works from anywhere — both sides connect outbound to the relay.
SSH isn't built for automation. Parsing SSH output in scripts is fragile. rcmd returns structured JSON for every command — stdout, stderr, exit code, duration. Built for AI agents and CI/CD pipelines.

It's also a remote execution tool

Tunneling is just one feature. rcmd also does:

# Execute a command on a remote machine
rcmd exec --target prod --cmd 'docker ps' --timeout 10

# Run the same command across 10 servers at once
rcmd exec --targets web1,web2,web3,db1 --cmd 'uptime' --format table

# Check fleet health
rcmd list-targets

# Copy files
rcmd cp --target prod --src ./app.tar.gz --dst /opt/app/

Every command returns JSON:

{
  "ok": true,
  "stdout": "CONTAINER ID   IMAGE   ...",
  "exit_code": 0,
  "duration_ms": 42
}

No parsing. No guessing. No wasted tokens when an AI agent uses it.

Self-hosted or hosted

Two ways to run it:

Free (OSS): Self-host the relay on any VPS. Unlimited targets, all features. MIT licensed.
Pro (€5/mo): We host the relay at rcmd.intrane.fr. Automatic TLS, no infrastructure to manage.

Same binary, same features. The hosted version just means you don't run the relay yourself.

Install

curl -sSL https://rcmd.intrane.fr/install.sh | sh

Then either self-host a relay or rcmd signup --email you@company.com for the hosted version.

What's next

Tunnel is the first of three SSH-killer features:

Port forwarding — shipped today
Scheduled commands — rcmd cron add --target prod --cmd 'docker restart app' --schedule '0 3 * * *'
Interactive shell — full PTY sessions, rcmd exec --target prod --pty

The goal is simple: make SSH optional for the 80% of server access that doesn't require a full interactive session.

Links: rcmd.intrane.fr · GitHub (OSS) · Install

Made in France. MIT licensed. Built for AI agents first, humans second.

I ran a 7B Mixture-of-Experts LLM in a language I built — token-identical to fp32

Javier Leandro Arancibia — Thu, 16 Jul 2026 19:01:45 +0000

I've been building machin (MFL), a machine-first language, and using it to write an LLM inference engine with zero dependencies — no PyTorch, no llama.cpp, no BLAS, no Python at runtime. Just a static binary.

The wall

A dense 1B model got me ~20 tok/s on a laptop CPU. That's the ceiling, and it's fundamental: decode speed is set by bytes moved per token, and on weak hardware you're pinned to the memory bus. I built and measured every trick — speculative decoding, int4, contextual sparsity, early-exit, continuous batching. Every one topped out at ~1.35×, because the box is balanced: save bandwidth and you go compute-bound, and vice-versa.

The disruption isn't in the engine. It's in the model.

Mixture-of-Experts

A dense model prices every token at its total params. An MoE decouples quality from speed: only a few experts fire per token. OLMoE-1B-7B is 6.9B total but 1.3B active (top-8 of 64 experts/layer). And since only a handful fire, you mmap the checkpoint and let the OS page cache stream cold experts from disk — total size bounded by disk, not RAM.

It works — and it's exact

I wrote an fp32 numpy reference reading the original weights, and checked my pure-MFL int8 engine against it token for token:

numpy fp32 : The capital of France is Paris. The capital of the United States is Washington
pure MFL   : The capital of France is Paris. The capital of the United States is Washington

12/12 tokens identical. Quantization didn't flip one.

experts	lm_head	size	tok/s
int8	int8	7.65 GB	14.5
int4	int8	4.43 GB	11.2

int8 lm_head buys speed (memory-bound); int4 experts buy footprint. Then I wrapped it in an OpenAI-compatible server — tokenizer and all in pure MFL — and pointed the official openai client at it. Works.

7B-class quality, ~1B speed, on hardware you own, no numeric libraries anywhere.

Full write-up: https://blog.intrane.fr/a-7b-moe-llm-at-1b-speed-in-pure-machin
Code (engine, converters, tokenizer, every dead end): https://github.com/javimosch/machin-colibri

DEV Community: Javier Leandro Arancibia

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

What changed

Why this matters

Code example

machin: make([]T, n) and make([]T, len, cap) for slices

What changed

Your homelab behind CGNAT is now reachable for free

The three plans

Set it up in 60 seconds

What you actually get

Fast file transfer

Port forwarding (tunnels)

Multi-target fan-out

AI-agent native

Why not just self-host?

What the relay can and can't see

Who this is for

Try it

I benchmarked my language against Rust and Zig, and deleted my best number

The benchmark was measuring the order I ran things in

So what does machin actually win?

1. It tells you about the bug before you run it

2. Binary size

And what it loses

The sieve: three months of a wrong explanation

What the claim actually is

Postscript: I ran it all on a second machine

Update: the sieve now ties Rust

My database claimed crash-safety. `kill -9` proved nothing.

What kill -9 actually tests

Two fsyncs, not one

Testing something invisible

What it costs

What I still can't claim

The general lesson

I built a 100 KB git-like VCS that beats git on `add && commit`

The benchmark that surprised me

Where the speed comes from

HTTP push / pull / clone out of the box

What's next

rcmd now speaks MCP — your AI agent can manage your servers without SSH

What is MCP?

What rcmd's MCP server exposes

How to set it up

What this looks like in practice

Why this matters

Self-host or use the hosted relay

What's next

Web Analytics With No Dashboard (But There Is a 3D Globe)

The premise

When a human needs to see it

The interesting constraints

I built a database my AI agent can pay for (and it beat SQLite)

The engine

The benchmark (100k docs, both engines indexed, same box)

Dogfooding found three compiler bugs in one day

For humans: client SDKs

rcmd: I replaced SSH with a relay — now my AI agents manage my servers

What shipped this week

Scheduled commands (cron)

Port forwarding (tunnel)

Team access

Email invites

Agent-first discovery

Why no SSH?

The stack

Try it

I replaced ssh -L with one CLI command. No SSH keys, no VPN, no open ports.

How it works

The command

What you can tunnel

But wait, I already have SSH

It's also a remote execution tool

Self-hosted or hosted

Install

What's next

I ran a 7B Mixture-of-Experts LLM in a language I built — token-identical to fp32

The wall

Mixture-of-Experts

What `kill -9` actually tests