scriptable.com

Hermes Agent installs from a shell script in a couple of minutes. Installing it the same way twice, a year apart, on a machine you have since forgotten the details of, is the harder problem — and it is the one Ansible solves. This article builds one role that installs Hermes on two Macs that differ in the ways that actually matter: devbot5 — the Mac you are typing on minime — a headless Mac mini Connection local, no SSH at all ssh Runs as your login account a dedicated service account launchd job LaunchAgent in your home LaunchDaemon in /Library API bound to 127.0.0.1 0.0.0.0 Those last two rows are what this article is about. A headless Mac has no one logged in, so there is no GUI session for a LaunchAgent to live in and the job has to be a LaunchDaemon that starts at boot and drops privileges. A laptop joins hotel and coffee-shop networks, so binding an agent’s API to every interface there would publish a shell to whoever else is on that LAN. ...

Nostr and IPFS get compared constantly, usually as rivals. They are not. They answer two different questions, and an application that needs both answers needs both protocols — or something that plays each part. Nostr answers “who said what, and when.” Its unit is a signed event. IPFS answers “what are these bytes.” Its unit is content-addressed data. That difference is worth getting straight, but it is not the interesting part. The interesting part is that both protocols are decentralized by design and neither is automatically decentralized by deployment, and the ways each one collapses back toward a single point of failure are mirror images of each other. IPFS falls over on the gateway and the pin; Nostr falls over on the relay. Both are deployment choices that inherit the protocol’s good name without inheriting the property that earned it. ...

Three systems name data three different ways, and the names get compared far more often than they get computed. This article builds a small Python tool that emits all three identifiers for one twelve-byte input, so you can see exactly where they agree and where they do not: a Nostr event id — the SHA-256 of a canonical serialization of a signed event an IPFS CIDv1 — a SHA-256 digest wrapped in a version, a codec, and base32 a Blossom hash — the same SHA-256, bare Two of those three turn out to be the same 32 bytes wearing different amounts of clothing, which is hard to believe from a table and obvious from a terminal. ...

Buzz is a workspace where people and AI agents share the same channels. Block released it on 21 July 2026 under Apache 2.0, and the announcement frames the bet plainly: the useful work happens when humans and agents are in the same room with shared context, not when someone alt-tabs to a chat window and pastes context back and forth. Structurally it is a Nostr relay. Every message, reaction, workflow step, review approval, and git event is a cryptographically signed entry in one log, and it makes no distinction between an entry signed by a person and one signed by a process. That is what “agents are members, not bots” means in practice: an agent gets its own keypair, its own channel memberships, and its own line in the audit log. ...

OpenRouter puts one API key and one base URL in front of models from dozens of vendors. On the day this was written its catalogue held 417 models, 17 of them free to call. Because the wire format is OpenAI’s, the openai Python package talks to it unchanged: point base_url at OpenRouter and switching from a Google model to a Chinese one is a change to a string. A plain proxy would give you one endpoint and nothing else. Four things here are worth building around, and the last two are the ones that bite: ...

Hermes Agent is Nous Research’s open-source (MIT) agent runtime: one agent with persistent memory that you can reach from a terminal or from a chat platform, backed by whichever model provider you point it at. Unlike an agent library, it ships as an installed program with its own config directory, a messaging gateway, and a command approval layer, so most of the work in getting started is deciding what it is allowed to do rather than writing code. ...

Qwen3.8-27B is a 27-billion-parameter dense model from the Qwen team, released August 2026 under Apache 2.0. It reads images and video as well as text, ships a multi-token-prediction head for faster decoding, and claims 262,144 tokens of native context. Quantized to Q4_K_M it is 17.7 GiB on disk. The context number is the interesting one. A conventional 27B model with 64 attention layers would need roughly 64 GiB of KV cache to hold 262,144 tokens, which is more memory than most machines have for the cache alone. Qwen3.8 gives only every fourth layer a real attention cache and runs the other 48 layers on a fixed-size recurrent state, so the same context costs 16 GiB. Step 6 reads those numbers straight out of the loader. ...

Add Per-Plan Rate Limiting to a FastMCP Server on macOS closes its troubleshooting with “back it with Redis (shared, atomic counters) if you run several instances behind a load balancer”, and Add Observability to a FastMCP Server on macOS adds a /health endpoint “for load balancers”. Neither article puts a load balancer in front of anything. This one does, and the first thing that happens is that the server stops working. ...

Muse Glimmer is a 30-billion-parameter agentic model from Meta Superintelligence Lab, released in August 2026 with a perception encoder for image input and a speculative-decoding drafter. Quantized to roughly 4 bits it fits in about 17 GB, which puts a capable agentic model inside the memory budget of a single consumer machine. This article installs a llama.cpp new enough to load it, pulls the three GGUF files, and runs the model four ways: a one-shot CLI answer, an OpenAI-compatible server, an image description, and a speculative-decoding run. It ends with a small Python project that measures decode throughput, because the numbers published for Apple Silicon were measured with a different runtime and do not transfer to this one. ...

One command turns a downloaded GGUF file into an HTTP server that speaks the OpenAI API. Code written against openai.OpenAI runs against it with one line changed — the base_url — and nothing leaves your machine. This article starts that server, reads what its startup log is telling you, drives it with curl, and then builds a small Python client on the official OpenAI SDK. The interesting part is not the happy path, which takes about ninety seconds. It is the two places where “OpenAI-compatible” stops being the whole story: a reasoning model can hand your SDK an empty content field, and the -c you pass is not the context each request gets. ...