State the intent and let the tool do the arithmetic.

Reladraw (Apache-2.0, TypeScript, zero runtime dependencies, 866 stars, 94 commits, one contributor, created September 7, v0.11.1 on npm today) sits between Mermaid and draw.io. Mermaid, Graphviz and D2 decide the layout for you. draw.io and Excalidraw let you place everything, which means clicking and dragging, or an agent editing coordinates in verbose XML. In Reladraw you write node store "Database" right of app level with app and edge app.api -> store from: right to: left, and the layout engine turns those relations into absolute positions and renders SVG. npm install -g reladraw gives you the CLI, there is a browser playground, and npx skills add reladraw/reladraw -g installs a skill for Claude Code, Codex, Cursor and others.

The Show HN reached 397 points and 115 comments on Saturday, and the author answered the questions a tool like this has to answer. Conflicting statements: anything that can hold together applies, and if the statements can't all hold, you get an error that names the clashing ones. "Nothing silently wins." Routing: there is no obstacle avoidance, but edges that share a side of a box space themselves out, and you can say which nodes an edge passes between. Asked whether the positions could be exported for other renderers, the author said the logic exists but the CLI can't emit positions-only JSON yet. One commenter found an edge that failed to curve; it was fixed in the playground within the thread. Commenters compared it to TikZ's positioning library without LaTeX, and to Pikchr, which the author distinguished as cursor-walking "turtle" graphics.

Reach for it if you keep asking an agent for an architecture diagram and then fixing Mermaid's layout by hand in draw.io; it replaces the render-look-fiddle loop, for you and for the agent. Delete the draw.io XML files nobody can diff. Tradeoffs: the README says the syntax will change, so pin the version; one maintainer, three weeks old; one dark default theme for now; and relative placement covers boxes, groups and arrows, not the full range of TikZ.

Imp (MIT, Elixir, 199 stars, 2,140 commits, two contributors, created July 10, v0.5.0 released Sunday, its first release on Hex) is a full port of DSPy to the BEAM. You write a signature such as "issue -> kind: enum[bug,feature,question], summary", and Imp builds the prompt, checks the reply against the signature and returns typed fields: kind is one of the three values or the call returns an error. You never write a prompt or a parser. Imp.chain_of_thought/2 and Imp.react/3 change how it thinks without changing the signature. Give it labeled train, validation and test sets and a metric, and optimizers do the rest: GEPA reads failures and rewrites the instructions, and there are ports of BootstrapFewShot, MIPROv2 and SIMBA, plus fine-tuning and GRPO. The optimized program is instructions and examples you can save as JSON and review as a diff.

The BEAM part is the reason to pick it over DSPy itself. Imp.start_run/3 runs an agent as its own supervised process with an authorize callback on every tool call, an event log, and model requests cut off at a deadline you set. A tool call that may already have taken effect is reported as unknown and never silently retried. It also imports tools from MCP servers you approve and serves programs to Zed over ACP. The HN thread (81 points, Sunday) raised the obvious objection: structured decoding mattered when models could not hold syntax, and people have moved on to tool calls. Another commenter replied with the case for it: their tool call returned hackernews where the schema said hn, because tool calls don't constrain enums, and only a validation step caught it.

Reach for it if you already run Elixir services and your LLM calls live in hand-built prompt strings with regex parsing; it replaces that pair with a signature you can score. Delete the prompt you tuned by feel and never measured. Tradeoffs: the README calls 0.5 experimental, says the API may change and says the optimizers still need large-scale benchmarking; it needs Elixir 1.19 and a C/C++ compiler, and the first compile needs network access; and optimizing means labeling three sets of examples first.

TensorFold (MIT, Python, 533 stars, 52 forks, ten contributors, created June 19) serves text models behind an OpenAI-compatible endpoint on Apple Silicon through MLX and on NVIDIA GPUs through CUDA. pip install from the repo, tensorfold serve a checkpoint, and point clients at 127.0.0.1:8080/v1. Supported families today are Qwen3.8-27B, Qwen3.8 Flash Next, Nemotron 3.5 Lightning, GLM-5.3-Flash and Gemma 4 26B-A4B, each with its own kernels and drafting: a bundled MTP head, a DFlash2 draft model, or copies from the context.

The rule that makes it a pick is in the README: a draft token is accepted only when it equals the token the same engine would produce serially, and concurrent streams must match their solo output. You can check it yourself, because any request can be repeated with "draft": false and the two replies compared. The README is also specific about where the guarantee stops: the same engine, weights, runtime and settings, not across MLX and CUDA, different quantizations or rank counts. The 0.3.6 notes add a known gap: prompts longer than one prompt chunk can differ between machines with different memory, because chunk size follows the memory budget. The speed claims are the project's own. The changelog reports Qwen3.8-27B on M1 to M4 decoding at 1.9 to 4x serial, and experimental EXL3 checkpoints on CUDA at 1.6 to 3.6x vLLM with MTP, and the recipe book publishes the prompts and command behind them. There was no HN thread to check them against.

Reach for it if you run a 27B-class model on a Mac for an agent and want drafting speed without wondering whether drafting changed the answers; it replaces mlx_lm's server for the families it supports. Delete the "turn off speculative decoding before running evals" step. Tradeoffs: three releases shipped today and the serial engine was removed Saturday, so expect churn; five model families, each tied to specific weight layouts (for Gemma 4, serve refuses other layouts before downloading); GLM's optional drafter carries non-commercial license terms; and the server checks for updates at startup unless you pass --no-update-check.

Gat (Apache-2.0, Rust, 7 stars, 29 commits, one contributor, created September 7, v0.0.14 released Saturday) is, in its own words, what git-lfs would be without a special server and what DVC would be if it did one thing. gat add models/encoder.safetensors hashes the file with BLAKE3, caches the bytes and writes the path and content ID into gat.lock. You commit gat.lock with Git. gat push uploads the bytes to S3, Azure Blob, GCS or a plain directory. On another clone, gat init and gat pull fetch whatever the lock names. There are no clean/smudge filters: hooks installed by gat init run gat sync after checkout, merge, pull and rebase, so checking out an old commit restores the weights or datasets that belonged to it.

The design splits a file's version from its bytes, and the lock is the check: it is a small text file in the diff, and each content ID can be recomputed from the bytes. The docs are clear about the sequence you are now responsible for. Git and Gat remotes are separate, so you gat push before git push, or readers get a commit whose lock names content they cannot download. The Show HN on Sunday got 7 points and no comments, so everything here comes from the README and the docs.

Reach for it if your model weights or datasets live in a bucket already and git-lfs's server, quotas or GitHub's LFS billing are the part you resent; it replaces the LFS server with the bucket you have. Delete the weights-v3-final-FINAL.safetensors naming scheme. Tradeoffs: version 0.0.14 with one maintainer and three weeks of history; every clone needs gat init; forgetting gat push gives you a commit other people cannot restore; the quick install is curl | sh, though the script verifies a checksum and there is a Cargo route; and it needs Rust 1.91 to build from source.

OpenRig (Apache-2.0, TypeScript, 1,344 stars, 120 forks, 3,039 commits, six contributors, created April 1, v0.5.17 released Sunday, 114 stars on GitHub trending today) runs Claude Code and Codex seats together as one team. A RigSpec in YAML declares pods, members, the edges between them and continuity policies. rig up boots each seat in its own tmux session you can attach to, and rig tui shows the team as a graph or a table with each seat's model, context and state. The starter rig is two Codex seats, an owner and a checker: you rig send the owner one bounded change, it records the task in a queue, asks the checker to review the exact candidate and reports back. rig down --snapshot saves the team, and rig up <name> restores it and reports each seat as resumed, fresh or failed. Shipped specs include implementation-pair, adversarial-review and research-team.

The check here is the plan. rig setup --dry-run and rig up --plan show what will happen before it does, and the README has a table titled "What OpenRig changes on your machine" that is worth reading before installing. It writes a block into ~/.tmux.conf, writes workspace trust into ~/.claude.json, adds hooks and a status line to .claude/settings.local.json, and enables Codex hooks in ~/.codex/config.toml at daemon startup, before any rig launches. Its shared settings resource sets Claude Code's permissions.defaultMode to acceptEdits and turns on the Exa and Context7 MCP servers. The README tells you to back up those files first. Two earlier Show HNs, in April and May, got 8 and 6 points, so outside reports are thin.

Reach for it if you already run several Claude Code and Codex terminals by hand and lose track of which one owns which task; it replaces that pile of tmux panes with a spec you can restore. Delete the notes file where you track which session was doing what. Tradeoffs: macOS and Linux with tmux only, no native Windows, and Node 22 specifically on Apple silicon; it rewrites trust, hook and permission settings for both harnesses; three releases in three days; and one owner-and-checker pair is the documented starting point, with the larger topologies left for you to evaluate.

Also on the desk. Fireworks' Ember-1 is Kimi K3 trained to reason with about 40% fewer tokens, and it reached 492 points on HN on Sunday. The post says quality held on public benchmarks, in live customer A/B tests and on Fireworks' own workloads; one commenter asked which specific capabilities the shorter reasoning gives up, which a benchmark average would not show. Worth an A/B on your own agent traffic.

Verification notes: star, fork, commit, contributor and release data are from the GitHub API on 2026-09-28. Commit totals use the per_page=1 Link-header last-page trick, and contributor counts exclude bot accounts. Reladraw's syntax, install and stability warning are from its README; the conflict, routing and JSON-export answers are the author's replies in HN item 49858513; the npm version is from the registry. Imp's signatures, optimizers and run supervision are from its README, and the Hex first-release date is from the Hex API. TensorFold's exactness rule and its limits are from the README's "Exact decoding" section, and the speed figures, release dates and known issues are from CHANGELOG.md. Gat's lock, cache and remote model is from docs/concepts/how-gat-works.mdx. OpenRig's machine changes are from the README's "What OpenRig changes on your machine" table. HN points and thread quotes are from the Algolia API (items 49858513, 49869995, 49868710, 49868830, and 47772935 and 48241066 for OpenRig's earlier posts). Pipeline health: today's pool held 82 rows, down from 111 on Friday, against the ~280 the compose prompt assumes. Reddit returned zero rows again, 142 days since the last nonzero day on May 9. github:trending returned 12 rows across all five feeds (all 3, go 3, python 4, rust 1, typescript 1).