Posts

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. ...

llama.cpp runs large language models directly on your machine, with no Python runtime, no server process you did not start, and no account. On Apple Silicon it uses Metal for GPU work and the unified memory architecture means a model does not have to be copied to a separate card before it can run. This article installs llama.cpp with Homebrew, pulls a model from Hugging Face, runs it two ways, and shows exactly where the weights land on disk. It closes with a small Python project that reads a GGUF file’s header with nothing but the standard library, so the model file stops being an opaque blob you downloaded and becomes something you can inspect and assert against. ...

Generate Synthetic JSON Requests to Test an API on macOS built two generators and a CLI that fires batches at an order-intake API. This article puts the same generators behind an MCP server, so an agent can preview a payload, check the target, and trigger a batch by asking for one. Wrapping a generator in tools is the easy half. The half worth attention is the control surface: which decisions the caller gets to make and which ones the server keeps. A model that can pick the destination of a traffic generator is a server-side request forgery primitive with a friendly name, and a model that can pick the batch size can turn one sentence into fifty thousand POSTs. Here the target comes from the environment and the batch size is capped, so the tools stay useful without handing over either decision. ...

Hand-written JSON fixtures cover the two or three cases you thought of while writing them. A generator covers hundreds, and it keeps covering them after the schema changes. This article builds two generators for the same order-intake API: a naive one that invents every field from random primitives, and a second one that samples a JSON seed database so every request refers to a product and a customer the API actually knows about. ...

uvx ruff check . works without installing anything. That is the whole appeal: one command, a throwaway environment, nothing left behind. It is also the problem. Every invocation re-resolves the package, the version you get today is not necessarily the version you got last week, and which ruff comes back empty because there is nothing on PATH. uv tool install is the other half of the story. It builds a persistent, isolated environment for a Python CLI and links its executables into a directory on your PATH, so ruff becomes a real command with a version you chose and control. Homebrew’s pipx niche, in other words, handled by the tool you already have. ...

Most teams have a procedure that only lives in someone’s head. Cutting release notes, triaging a breaking change, prepping an on-call handoff: five steps, done slightly differently every time, and badly the week the person who knows them is on vacation. MCP gives you three primitives to fix that, and the interesting one is the least used. Tools are called by the model. Resources are read for context. Prompts are chosen by a person: named, parameterized templates a client surfaces as a slash command. That makes a prompt the natural home for a procedure — the user picks it, fills in one argument, and the model runs the same five steps in the same order every time. ...

A resource that returns a picture is the most demanding shape an MCP resource takes. It has to survive base64 encoding, arrive with a MIME type the client will accept, stay small enough to attach, and — if the picture is meant to reflect something live — return different bytes the next time the same URI is read. Serve Resources Well from an MCP Server on macOS covered the shapes of resources with an eight-byte PNG magic number standing in for a binary body. This article replaces that stub with a real image: a bar chart rendered on every read from state that anything can change, packaged so uvx runs it from a local directory, and wired into opencode so a model can read it, watch it change, and read it again. ...

opencode attaches an MCP server in a single command, with no config file to hand-edit and no JSON to get wrong. Everything after the -- separator is the command that launches the server, and because uvx resolves the package on first launch, there is nothing to install beforehand either: opencode mcp add hello -- uvx mcp-hello-server This tutorial uses that command to attach mcp-hello-server — a small FastMCP server on PyPI exposing two tools, server_info and greet — then drives it from a free model. You will confirm the server connects, prove the launch command works without involving a model at all, pin the same server to a single project instead of your whole machine, and finally ask North Mini Code Free to say hello to Alice in Japanese. ...

A JavaScript module is a file that exports values other files import by name. ES modules (import/export) are the standard form and run unchanged in modern browsers and Node.js. This tutorial builds a small module with a default export and a named factory function, imports it from another file, tests it with Node’s built-in runner, and loads it in the browser — the same module code in both environments, no bundler. ...