DEV Community: ArshTechPro

Humanizer: The 40k-Star Agent Skill That Strips AI Tells From Your Writing

ArshTechPro — Thu, 03 Sep 2026 10:43:45 +0000

Wikipedia editors have a problem. People keep dumping LLM output into articles, and it reads badly in a specific, recognizable way. So WikiProject AI Cleanup wrote up a page cataloguing the tells: the inflated importance, the forced triads, the "not just X, it's Y" construction, the paragraph that ends by assuring you the future looks bright.

Siqi Chen looked at that page and had an idea that is obvious in retrospect. If someone has already collated a detailed list of how AI writing gives itself away, you can hand that list to an LLM and tell it not to do any of it. He asked Claude Code to read the article and build a skill from it.

The result is blader/humanizer, now sitting at roughly 40k stars.

It is a Markdown file

This is the part that surprises people. Humanizer is a SKILL.md file. There is no package, no model, no API, no dependency tree. It is instructions.

That sounds like a limitation and is actually the reason it spread. Because it is plain Markdown following the Agent Skills format, it runs on anything that supports skills. And if your tool does not support skills, you can open the file and paste it into a system prompt. Distribution problem solved by not having one.

How it works

Humanizer encodes 35 patterns drawn from Wikipedia's "Signs of AI writing" page. Each one is a named failure mode with a before and after example, which matters more than it sounds: the model is not being told "write naturally," which is useless advice. It is being told "you wrote 'serves as a testament to' and here is the specific replacement."

The run is two passes. It rewrites first, without treating the original paragraph structure as fixed. Then it checks that draft against the 35 patterns and against the original claims, and rewrites whatever is still wrong. When you paste text in, it shows you both stages plus a short critique of what still sounds artificial, which is genuinely useful for learning your own tells.

The patterns fall into five groups:

Content. Inflated importance, name-dropping, vague attribution ("experts believe"), the formulaic "despite challenges, it continues to thrive" arc.

Language and grammar. Overused AI vocabulary (testament, landscape, showcasing, delve-adjacent stuff), avoiding plain "is" and "has" in favor of "serves as" and "boasts," the not-X-but-Y construction, forced groups of three, fake "from X to Y" ranges.

Style. Em dashes, excessive bold, lists where prose would do, title case headings, emojis, curly quotes, hyphen pileups like "cross-functional, data-driven, client-facing," manufactured profundity ("at its core, what matters is"), and fake-candid openings ("Honestly? It depends").

Chatbot residue. "I hope this helps," knowledge-cutoff disclaimers, "Great question!"

Filler. "In order to" instead of "to." Stacked hedges like "could potentially possibly." Endings that gesture vaguely at a bright future.

A quick illustration of the shape of the fix:

Before: The migration serves as a testament to our team's commitment to scalability, reliability, and performance — proving that with the right architecture, the future looks bright.

After: The migration cut p99 latency from 1.2s to 340ms. We still have two services on the old queue.

Same topic. One sentence says nothing and one says something.

Two design decisions deserve credit. First, there is a hard no-fabrication rule, added in v2.9.0. Names, numbers, dates, quotes, and citations have to come from the source or from you. If a detail is missing, it is supposed to ask rather than invent one, which is exactly the failure mode you would expect from a tool whose job is to make text sound more lived-in and specific. Second, if you paste in two or three paragraphs of your own writing as a sample, it follows your rhythm and quirks instead of its default style rules. That is the difference between "sounds human" and "sounds like you."

Pointed at a file, it only touches prose. Code blocks, data, frontmatter, and link targets stay put.

Does it work with Claude?

Yes, three different ways, and the repo has clearly been maintained with Claude in mind.

Claude Code, via the skills CLI:

npx skills add blader/humanizer --global

Drop --global to install into the current project only.

Claude Code as a plugin (2.1.142 or newer):

/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer

Invoke it with /humanizer:humanizer.

Claude Desktop: download the repo as a ZIP and upload it as a skill. This one was broken for a while. The repo used a symlink for the plugin path, and Claude Desktop could not handle it in the source archive. It was fixed twice, first with a dedicated release asset in v2.11.1, then properly in v2.11.2 by dropping the symlink entirely once Claude Code began loading the root SKILL.md directly. If you tried this months ago and it failed, try again.

Once installed, either invocation style works:

/humanizer

[paste your text here]

Or just ask for it in plain language, including pointing at a path: "Humanize the prose in docs/launch-post.md."

Does it work with other agents?

Also yes, and this is where the "it's just Markdown" decision pays off. The npx skills CLI targets 40-plus agents, and Humanizer is a normal skill package, so it installs to any of them:

npx skills add blader/humanizer --global --agent codex
npx skills add blader/humanizer --global --agent cursor --agent opencode
npx skills add blader/humanizer --global --agent '*'

Common targets and where the files land:

Agent	`--agent` flag	Global path
Claude Code	`claude-code`	`~/.claude/skills/`
Codex	`codex`	`~/.codex/skills/`
Cursor	`cursor`	`~/.cursor/skills/`
Gemini CLI	`gemini-cli`	`~/.gemini/skills/`
GitHub Copilot	`github-copilot`	`~/.copilot/skills/`
OpenCode	`opencode`	`~/.opencode/skills/`
Amp	`amp`	`~/.config/agents/skills/`
Cline	`cline`	`~/.cline/skills/`
Windsurf	`windsurf`	`~/.windsurf/skills/`

Kiro, Qwen Code, Roo, Trae, Goose, Continue, and others are supported too. Remember to reload skills in the target agent afterward.

For anything not on that list, the manual path always works: copy SKILL.md into the agent's skill folder. And for a plain chat interface with no skill support at all, open SKILL.md, copy the contents, and paste it as your system prompt or as the preamble to your request. You lose the slash command and the file-editing mode. The 35 patterns still apply.

The honest caveat on cross-agent use: the skill is a prompt, so results depend on how well the underlying model follows a long instruction set. A frontier model with good instruction-following will apply all 35 patterns and self-critique properly. A smaller local model may catch the obvious vocabulary swaps and quietly skip the harder judgment calls. Same file, different mileage.

What it does not do

It is not an AI-detector defeat button. People reach for it that way and the framing is wrong in both directions. Detectors are unreliable enough that they flag human writing regularly, so "passing" one proves little. And Humanizer's actual job is removing bad writing habits, not adversarially targeting a classifier. If you are trying to sneak past an academic integrity check, this is the wrong tool and a bad plan. If you are trying to make a launch post not read like a launch post, it is the right tool.

Some patterns are opinions, not rules.

It cannot add substance.

Overcorrection is real.

Worth using?

For a Markdown file with an MIT license, the cost of trying it is close to zero, and it is the rare tool where reading the source teaches you something even if you never install it. The 35 patterns are a decent editing checklist on their own.

The realistic workflow is not "generate with AI, run Humanizer, ship." It is: write the draft, make sure it contains real specifics only you have, then run Humanizer to strip the stylistic residue, then read the output yourself. It is a de-slopping pass, not a ghostwriter.

Repo: github.com/blader/humanizer

TimesFM: Google's Foundation Model for Time Series, Explained for Developers

ArshTechPro — Thu, 03 Sep 2026 10:21:07 +0000

TimesFM proposes a different deal: skip the training step entirely.

It is a pretrained model from Google Research that forecasts time series it has never seen before. Same idea as an LLM, except instead of predicting the next word, it predicts the next value. You hand it a NumPy array of history, tell it how far ahead to look, and get a forecast back. No training loop, no hyperparameter search.

This post covers what it actually does, how the API feels, what landed in the brand-new 3.0 release.

The mental model: patches are tokens

An LLM chops text into tokens and learns to predict the next one. TimesFM chops a time series into patches (contiguous windows of 32 time steps) and learns to predict the next patch.

That is basically the whole idea. A decoder-only transformer, the same family as GPT, pointed at numbers instead of text.

Patching matters for two practical reasons. Attention cost grows with sequence length, so grouping 32 points into one token keeps long histories affordable. And a patch captures a local shape (a weekly cycle, a spike, a slow drift) as a single unit, which is closer to how time series actually behave than treating each individual point as a token.

The training data is the other half of the story. TimesFM was pretrained on a corpus of over a trillion time points spanning retail, finance, web traffic, energy, and synthetic data. It has seen enough patterns of "sales-shaped thing" and "traffic-shaped thing" that when you hand it yours, it recognizes the family. That is what makes zero-shot forecasting work.

You also get uncertainty for free. The model outputs 9 quantiles (10th through 90th percentile) at every step, not just a single line. If you have ever had to bolt confidence intervals onto a forecast after the fact, this is a real convenience.

Getting started

Installation is a one-liner:

pip install timesfm[torch]

Or from source with uv:

git clone https://github.com/google-research/timesfm.git
cd timesfm
uv venv && source .venv/bin/activate
uv pip install -e .[torch]

The 2.5 API

This is the API most tutorials and existing code use. You load a checkpoint, compile it once with a config, then call forecast():

import torch
import numpy as np
import timesfm

torch.set_float32_matmul_precision("high")

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)

model.compile(
    timesfm.ForecastConfig(
        max_context=1024,
        max_horizon=256,
        normalize_inputs=True,
        use_continuous_quantile_head=True,
        force_flip_invariance=True,
        infer_is_positive=True,
        fix_quantile_crossing=True,
    )
)

point_forecast, quantile_forecast = model.forecast(
    horizon=12,
    inputs=[
        np.linspace(0, 1, 100),
        np.sin(np.linspace(0, 20, 67)),
    ],
)

point_forecast.shape     # (2, 12)
quantile_forecast.shape  # (2, 12, 10)

Two things worth noticing. The inputs are plain 1D arrays and they do not have to be the same length, which is genuinely nice when you are forecasting a batch of products with different histories. And a few config flags do real work: infer_is_positive stops the model predicting negative sales, fix_quantile_crossing prevents the 60th percentile landing below the 40th.

Swapping in your own data is the boring part, which is the point:

import pandas as pd

df = pd.read_csv("weekly_demand.csv", parse_dates=["week"])
values = df["demand"].values.astype(np.float32)

point, quantiles = model.forecast(horizon=52, inputs=[values])

That is a 52-week forecast with prediction intervals, from a CSV, with no training.

What changed in 3.0

TimesFM 3.0 landed in late August 2026, and it is a bigger jump than the version number suggests.

Every checkpoint through 2.5 was strictly univariate. One series, its own history, nothing else. That is a real limitation, because most forecasting problems in the wild are not like that. If you are forecasting ice cream sales, past sales alone miss the picture: related product sales matter, foot traffic matters, and crucially, the promotion you already scheduled for next Tuesday matters.

3.0 is natively multivariate. It brings three things that were previously awkward or impossible:

Multiple targets. Forecast several related series jointly and let the model use the correlations between them.
Past covariates. Features you only know historically, like last month's foot traffic.
Past-future covariates. Features you know in advance, like scheduled promotions, holidays, or a weather forecast.

That last one is the interesting capability. The model learns the promotion-to-sales relationship from your historical context, then applies it to future days where you have a promotion planned. A univariate model just projects the weekly pattern forward and misses the bump entirely.

Architecturally, 3.0 does this with alternating attention. Tokens attend horizontally across time (strictly causal, so no leakage from the future), then vertically across series at each time step, so the model can learn how a spike in one series relates to another. Those two layers alternate through the stack.

It also stopped decoding autoregressively. Earlier versions generated one patch at a time, which meant latency and compounding errors over long horizons. 3.0 appends masked placeholder tokens for the whole future window and fills them all in a single forward pass.

The 3.0 API is different from 2.5, so this is not a drop-in upgrade:

import numpy as np
from timesfm3 import TimesFM3Evaluator, ModelConfig

config = ModelConfig(
    checkpoint_path="google/timesfm-3.0-pytorch",
    per_core_batch_size=16,
    device="cuda",
)
forecaster = TimesFM3Evaluator(config)

context_len, horizon = 128, 24

target = np.random.randn(3, context_len).astype(np.float32)
past_only_cov = np.random.randn(1, context_len).astype(np.float32)
past_future_cov = np.random.randn(2, context_len + horizon).astype(np.float32)

outputs = list(
    forecaster.predict_batch(
        contexts=[target],
        horizon=horizon,
        past_only_covariates=[past_only_cov],
        past_future_covariates=[past_future_cov],
        return_quantiles=True,
    )
)

outputs[0].forecast.shape    # (3, 24)
outputs[0].quantiles.shape   # (3, 24, 9)

Note the shape of past_future_cov: it spans context plus horizon, because you are telling the model about events that have not happened yet.

On benchmarks, Google reports 3.0 taking the top average rank among pretrained foundation models on GIFT-Eval, fev-bench, and the TIME leaderboard, on both point and probabilistic metrics, against competitors including Chronos-2 and the Toto 2.0 family. Notably, it wins even in univariate mode, before you give it any covariates at all.

The catch nobody mentions in the benchmark charts

Read this part before you plan a sprint around it.

The 3.0 weights are not open for commercial use.

The source code in the repo is Apache-2.0, and model weights up to 2.5 are Apache-2.0. But the 3.0 pretrained weights ship under a separate timesfm-non-commercial-license-v1.0, restricted to non-commercial, non-production use. Commercial or production use of the default 3.0 weights is not permitted.

So the practical situation right now is:

	TimesFM 2.5	TimesFM 3.0
Parameters	200M	330M
Context length	up to 16k	patch-based, 32-step patches
Multivariate	No (XReg covariates bolted on)	Yes, native
Future-known covariates	Limited	Yes
Decoding	Autoregressive per patch	Single forward pass
Weights license	Apache-2.0	Non-commercial only

The best model is the one you probably cannot ship. The one you can ship is a version behind. That may change, and Google has said BigQuery integration for 3.0 is coming, but plan against what is true today.

Is it worth a try?

Yes, if any of these describe you:

You have a lot of series and no time to model each one. This is the killer use case. Tuning ARIMA for one series is fine; doing it for 5,000 SKUs is not a job anyone wants. Zero-shot inference across a batch is a single call.

You need a baseline yesterday. Even if you eventually build something bespoke, having a credible forecast in twenty minutes tells you whether the problem is hard and what score you need to beat.

You want uncertainty without extra work. Quantiles come out of the box.

You are already on Google Cloud. TimesFM is wired into BigQuery ML behind an AI.FORECAST SQL call, into Connected Sheets, and into Vertex Model Garden. If your data already lives in BigQuery, forecasting becomes a query rather than a project.

Be skeptical if:

You have one series and years of clean history. A well-tuned domain model with your actual business logic baked in will often beat a general-purpose one. Foundation models win on breadth, not on any single well-understood problem.

Your data is genuinely weird. Sparse intermittent demand, hard structural breaks, series driven mostly by exogenous shocks the model cannot see. Zero-shot means the model brings priors from other people's data, and sometimes those priors are simply wrong for you.

You need commercial deployment of the newest model. See the license section above.

You need CPU-cheap inference at scale. It is a 200M to 330M parameter transformer. That is small next to an LLM but not free, and the examples assume a GPU.

Where to go next

Repo and examples: github.com/google-research/timesfm

One note: this is a research release, not an officially supported Google product. Treat it accordingly in anything load-bearing.

Omarchy: an opinionated Arch install that ships someone else's taste

ArshTechPro — Fri, 28 Aug 2026 11:14:53 +0000

Most Linux distributions hand you a foundation and a shrug. Omarchy hands you a finished desk.

It is an omakase Linux distribution based on Arch, the tiling window manager Hyprland, and the desktop construction-kit Quickshell. "Omakase" is the sushi term: you don't order, the chef decides. In this case the chef is DHH, and the distribution is the answer to a specific question — what if someone spent a year making all the tiling-WM decisions for you, and you just used the result?

The project is MIT licensed, incubated at 37signals, and is now on version 4.x.

What it actually is

Strip the branding and Omarchy is three things stacked:

An installer. An ISO that provisions Arch with full-disk encryption, sane partitioning, and a working graphical session in a few minutes.
A configuration layer. Hyprland, Quickshell, a top bar, a theming system, a unified keybinding scheme, and dotfiles for tmux, Neovim, and your shell.
A curated software set. Neovim, Chromium, Obsidian, LibreOffice, Kdenlive, OBS Studio, and more.

The repo itself is 82% shell, 8% Lua, sitting at around 4,300 commits. That composition tells you the honest truth about the project: it is a very well-maintained pile of install scripts and config files, not a novel operating system. That is not a criticism. It's the reason you can read it, fork it, and steal from it.

The framing in the manual is explicit about what it's optimizing for: a beautiful system is a motivating system, and productivity has always been downstream from motivation. Whether you buy that argument will largely determine whether this distribution is for you.

Installation

You download the ISO, write it to a USB stick, boot off it, and answer a few configuration questions. It can be done in under a minute on the fastest modern machines, but it shouldn't take more than 5 minutes even on an older computer.

Three things to know before you start:

Secure Boot has to go. You must turn off Secure Boot and/or TPM in the BIOS to be able to install Omarchy. If your machine is corporate-managed or you dual-boot Windows with BitLocker on, plan for that.

Encryption is the default and it changes your keyboard requirements. The installation defaults to full encryption, and the full-disk encryption won't allow you to enter the password from a Bluetooth keyboard at startup. You need a wired or 2.4GHz keyboard for the boot prompt. You can hit Ctrl + C on the disk formatting confirmation to switch to an encryption-less installation if you're building a throwaway box.

You can dual boot. You can choose between a full-disk install, which takes over the entire drive, or a free-space install, which puts Omarchy in the unallocated space on a drive. The full-disk option will wipe the selected drive, so back up first.

Two installer details I didn't expect and think are genuinely well designed:

If you're setting up a machine for someone else, hit Ctrl + C on the very first screen and Omarchy will prepare the machine for another owner instead. The system installs right away, but keyboard layout, username, and password are deferred until first boot, and the password the new owner picks becomes the encryption password.

The ISO can also install completely on its own — no keyboard, no wizard — when it's handed its configuration on a second drive, which is how you treat Omarchy as a base image for VMs and fleet machines.

That second one is the part most reviews skip, and it's the one that makes this interesting beyond a personal laptop.

The keyboard-first part

Omarchy is a tiling window manager setup, so almost everything is a binding. Super + K shows you all of them, which is the only hotkey you actually need to memorize on day one.

A representative slice:

Hotkey	Function
`Super + Space`	Omarchy menu (apps and everything else)
`Super + Return`	Terminal
`Super + Shift + Return`	Browser
`Super + Shift + N`	Neovim
`Super + Arrow`	Move focus in that direction
`Super + Shift + Arrow`	Swap window in that direction
`Super + 1/2/3/4`	Jump to workspace
`Super + F`	Full screen
`Super + T`	Toggle tiling/floating
`Super + Ctrl + Shift + Space`	Pick a new theme

The one I want to call out separately is the clipboard. On most Linux desktops you need Ctrl + Shift + C/V in the terminal and Ctrl + C/V everywhere else. Omarchy binds Super + C, Super + X, and Super + V and they work in both places. It is a small thing that removes a daily papercut, and it is a good example of what "opinionated" buys you: someone noticed the inconsistency and just fixed it globally.

Bindings live in ~/.config/hypr/bindings.lua. Lua config rather than a bespoke DSL, which means real conditionals and loops if you want them.

There is also a tmux layer with its own binding set (Super + Alt + K to view), including layout helpers like tdl <ai> to spin up an editor + AI + terminal pane arrangement in one command.

The AI-workstation angle

This is where Omarchy 4 diverges from being "a nice Hyprland config." A few of the defaults are built around agentic coding:

Super + Ctrl + Return opens Herdr, an agent manager, with its own binding set under Super + Ctrl + K
Super + Shift + Ctrl + A opens an agent picker
The tmux layout functions take an AI argument as a first-class parameter
Dictation is a first-class install option, with push-to-talk on F9 and toggle on Super + Ctrl + X
Super + Ctrl + Print Screen does OCR text extraction from anything on screen straight to the clipboard

If you run coding agents in terminals all day, the shape of this system was designed by someone doing the same thing.

The maintenance question

The usual worry with a one-person opinionated distribution is what happens when that person moves on. Omarchy just answered it with money: the Omacom Foundation was incorporated as a nonprofit to hold the trademarks, fund the infrastructure, promote the work, and support the open-source projects and developers Omarchy depends on. Eight founding patrons contributed $1 million each, including Tobi Lütke, Patrick Collison, Michael Dell, Jack Dorsey, Matthew Prince, Brendan Iribe, and Jason Fried, with a further $2 million added from Drew Houston and Peter Steinberger.

Ten million dollars does not guarantee good software. What it does buy is runway, infrastructure, and a reason to believe the ISO will still be built in three years. For a distribution you'd put on a work machine, that matters more than any feature.

Where I'd push back

It is Arch underneath, with everything that implies. Rolling release, no LTS, and when something breaks mid-week you are debugging Arch. Omarchy ships system snapshots to soften this, but the failure modes are Arch's failure modes.

Secure Boot off is a real cost for some people. If your employer requires it, or you want measured boot as part of your threat model, this is a non-starter and no amount of theming fixes it.

Is it worth a try?

It depends almost entirely on which of these you are.

Try it if you already want to live in a terminal and a tiling WM, and the thing stopping you is the two weekends of config work. That is precisely the cost Omarchy eliminates. You get someone's finished, coherent, actively maintained setup instead of your own half-finished one, and you can read the shell scripts to understand every decision it made.

Try it if you want a reproducible dev machine image. The unattended install path is the most underrated feature here. A pinned ISO plus a config drive gets you identical, encrypted, fully-provisioned workstations across a team.

Skip it if you need Secure Boot, need an LTS release cadence, or do work that is fundamentally mouse-driven and GUI-heavy. Skip it if you enjoy building your own environment, because Omarchy's entire value proposition is taking that job away from you.

Repo: github.com/basecamp/omarchy

Ponytail: the AI coding skill that makes your agent write less code

ArshTechPro — Fri, 28 Aug 2026 11:12:26 +0000

You ask your AI agent for a date picker.

It installs flatpickr, writes a wrapper component, adds a stylesheet, sets up a theme override, and then starts explaining timezone handling to you. Four hundred lines later you have a date picker.

The senior dev sitting two desks over would have written this:

<input type="date">

Ponytail is an open-source skill/plugin that tries to put that person inside your coding agent. It works with Claude Code, Codex, Cursor, Gemini CLI, Copilot, OpenCode, Windsurf, Cline, and a long list of others. MIT licensed.

The idea in one screen

Ponytail is not a tool, a library, or a model. It is a ruleset that gets injected into your agent's context every turn. The core of it is a ladder. Before writing any code, the agent stops at the first rung that holds:

1. Does this need to exist?   -> no: skip it (YAGNI)
2. Already in this codebase?  -> reuse it, don't rewrite
3. Stdlib does it?            -> use it
4. Native platform feature?   -> use it
5. Installed dependency?      -> use it
6. One line?                  -> one line
7. Only then: the minimum that works

That's basically it. Everything else in the repo is packaging: adapters for twenty-odd agents, a few slash commands, and a benchmark harness.

Two things about the ladder that matter more than they look:

It runs after understanding, not instead of it. The rules tell the agent to read the code the change touches and trace the actual flow before picking a rung. Lazy about the solution, not about reading the codebase.

Validation is off the table. The rules explicitly protect trust-boundary validation, error handling, security, and accessibility. The stated goal is not "fewest tokens." It is "write only what the task needs." The code comes out small because the extra was never needed, not because it was golfed down.

Installing it

Pick your agent. For Claude Code, two prompts (they have to be sent separately):

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

Codex:

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

Copilot CLI:

copilot plugin marketplace add DietrichGebert/ponytail
copilot plugin install ponytail@ponytail

Gemini CLI:

gemini extensions install https://github.com/DietrichGebert/ponytail

For Cursor, Windsurf, Cline, Kiro, Aider, and Copilot Chat there is no plugin layer, so you copy the matching rules file out of the repo (.cursor/rules/, .windsurf/rules/, .clinerules/, and so on). Several agents also auto-load AGENTS.md from the project root, and the repo ships one, so those work with zero setup from a checkout.

The Claude Code and Codex plugins run two small Node lifecycle hooks, so node needs to be on your PATH. If it isn't, the skills still work; you just lose the always-on activation.

The commands

Command	What it does
`/ponytail [lite\	full\
{% raw %}`/ponytail-review`	Reviews your current diff for over-engineering, hands back a delete-list.
`/ponytail-audit`	Same, but across the whole repo instead of the diff.
`/ponytail-debt`	Collects the `ponytail:` shortcuts you deferred into a ledger.
`/ponytail-gain`	Shows the measured impact scoreboard.
`/ponytail-help`	Quick reference.

/ponytail-review is the one I'd reach for first even if you never turn on always-on mode. Pointing it at a diff you already wrote is a low-commitment way to see whether the discipline finds anything real in your codebase.

Commands need a skill-capable host. The instruction-only adapters (Cursor, Windsurf, Cline, Copilot Chat, Kiro) get the always-on ruleset but not the commands.

What the numbers actually say

This is where the project gets more interesting than most GitHub trending entries, and it's worth walking through because the story has a plot twist.

The original benchmark claimed 80-94% less code. Someone opened issue #126 and made four fair criticisms:

A single prompt-completion pair is not how agents are used.
The baseline was a bare chatty model that padded answers with prose and options, so "lines of the answer" was counting commentary, not code.
"Prefer one-liners" might trade away safety.
A seven-word prompt might do the same job as a whole skill.

Against that fairer baseline:

vs no-skill baseline	LOC	tokens	cost	time	safe
ponytail	-54%	-22%	-20%	-27%	100%
caveman (terse prose)	-20%	+7%	+3%	+2%	100%
"YAGNI + one-liners" prompt	-33%	-14%	-21%	-30%	95%

The per-task numbers are more useful than the average:

task	baseline	ponytail
date picker	404	23
color picker	287	23
file dropzone	251	95
multi-step wizard	571	312
search items by title	44	44
export items as CSV	36	33
count user's items	21	17

The shape is clear. Where there is an over-build trap, the cut is enormous, because the agent reaches for <input type="date"> instead of building a component. Where the code is already minimal (backend CRUD), every arm converges and ponytail does nothing. The -54% headline is an average across both kinds of task, so treat it as "huge sometimes, zero other times," not "half your code everywhere."

The safety tier is the part I found most convincing. Six tasks seed a starter file, ask for one function, and leave the safety requirement implicit the way a real ticket does. The scorer then executes the produced function against adversarial input: path traversal, SQL injection, a forged token, a malformed CSV row.

On the path-joining task, the bare one-liner prompt wrote the fewest lines (6) and let a ../../ filename escape the directory one run in four. Ponytail wrote about 9.5 lines and held 4/4. The extra three lines were the traversal check. That is the whole argument for using a structured ruleset instead of telling your agent "be brief."

Two more things I'll credit them for. The benchmark writeup has a limitations section that names its own weak points (one model only, n=4, safety is a floor and not a proof). And it documents a contamination bug they found in their own earlier run, where the plugin's SessionStart hook was firing on the baseline arm too, secretly running ponytail against itself. Finding and publishing that is a better trust signal than any number in the table.

Where I'd push back

It's a prompt, not a guarantee. Everything here is instructions in a context window. Models drift, ignore rules under load, and behave differently across vendors. Nothing enforces the ladder.

The gains depend on your agent being bad in a specific way. The wins come from an agent that over-builds. If you're on a stronger model, or you already write tight tickets that say "use a native input," a lot of that headroom is already gone. The README itself notes the effect can invert on some reasoning models that spend extra thinking tokens deliberating the rungs.

Is it worth a try?

Yes, with a caveat about which "yes" this is.

The cost of trying is two commands and a slash command to turn it off. There's no runtime, no dependency in your project, no lock-in, and the uninstall is documented (including a cleanup script for the state it writes outside the plugin folder). At that price, the question is barely worth deliberating.

Repo: github.com/DietrichGebert/ponytail

Benchmark writeup and reproduction steps: benchmarks/results/2026-06-18-agentic.md

The M5 Ultra Mac Studio: I Did the Math So You Don't Have To

ArshTechPro — Tue, 25 Aug 2026 14:40:11 +0000

Apple announced the new Mac Studio this morning — M5 Max and the first-ever M5 Ultra. Pre-orders are open, units ship September 22, and the headline for our corner of the world is this: up to 512GB of unified memory at 1.2TB/s, with Neural Accelerators in every GPU core.

Base M5 Ultra: $5,499. The config you actually want: closer to $10,000.

I've spent the morning reading the spec sheet and the pricing page instead of working, so let me save you the trouble. This is not a review — nobody has benchmarked one yet. This is a "should you open your wallet" analysis, aimed squarely at developers who run models locally.

What actually changed (and what's marketing)

Skip the 8K ProRes stream counts. Three things matter if you run models:

1. Neural Accelerators came to Ultra for the first time. The M5 generation puts dedicated matrix-multiply hardware inside each GPU core. The M5 Max shipped with this in the MacBook Pro; this is the first Ultra chip to get it. Apple claims up to 4.3x the peak AI compute of M3 Ultra, and up to 4x faster LLM prompt processing in LM Studio.

That prompt-processing number is the one to care about. Time-to-first-token on long contexts has been Apple silicon's most embarrassing weakness. You paste 60k tokens of codebase into a local model on an M3 Ultra and go make coffee. A 4x improvement there changes whether local agentic coding is usable versus a demo.

2. Memory bandwidth went to 1.2TB/s — 50% up from M3 Ultra's ~819GB/s. For token generation, bandwidth is the speed limit. More on this below.

3. It's a quad-die chip. M5 Ultra is two dual-die M5 Max chips fused with next-gen UltraFusion — over 4.4TB/s of inter-die bandwidth, four dies presenting as one processor. Up to 36 CPU cores (12 "super cores" + 24 performance cores) and an 80-core GPU.

Also new and genuinely relevant: Thunderbolt 5 clustering with RDMA. You can pool memory across multiple machines; Apple claims a four-Studio cluster hits 3x the inference throughput of a single box. And macOS 27 brings Core AI, a new framework for deploying full-scale LLMs locally, alongside MLX.

The pricing trap nobody will put in the headline

Here's the part that matters, from the configurator:

Config	Price
M5 Max — 32-core GPU, 36GB, 512GB SSD	$2,499
M5 Max — 40-core GPU, 48GB	$3,099
M5 Ultra — 30-core CPU, 64-core GPU, 96GB, 1TB	$5,499
M5 Ultra — 36-core CPU, 80-core GPU, 96GB	$6,799
+ 256GB unified memory	+$4,000
512GB unified memory	Late October

The $5,499 machine is not the M5 Ultra you read about in the headlines. It's a binned 30-core/64-core part. The full 36-core CPU / 80-core GPU chip starts at $6,799.

And if you want the memory — the entire reason to buy this machine for AI — 256GB is a $4,000 upgrade. That's a real config at $10,799 before you touch storage. Storage tops out at 16TB for another $4,000.

Some context on why: we're in the middle of a brutal DRAM shortage driven by AI datacenter demand. Apple removed the 512GB option from the M3 Ultra back in March and raised the 256GB upgrade from $1,600 to $2,000. Against that backdrop, the M5 Ultra Mac Studio starting at $5,499 (up from $3,999 for the M3 Ultra at launch, though that model was repriced to $5,299 in June) is less outrageous than it looks. Doesn't make it cheap.

Also note: 512GB configs don't ship until late October.

The only formula you need

Token generation speed on a memory-bound machine is roughly:

tokens/sec ≈ (memory bandwidth × efficiency) / bytes read per token

For a dense model, "bytes read per token" is basically the whole model. So on a 1.2TB/s machine, back-of-envelope ceilings:

Model	Size on disk (Q4)	Theoretical ceiling	Realistic guess
70B dense	~40GB	~30 tok/s	~20–25 tok/s
235B dense	~130GB	~9 tok/s	~6–7 tok/s
671B MoE (~37B active)	~380GB	high, but routing-bound	~15–25 tok/s

Treat these as estimates, not benchmarks. Real numbers depend on quantization, framework, and whether the model is dense or MoE. Wait for independent testing before you buy on the strength of a table — including mine.

The strategic takeaway: MoE models are the killer app for this machine. A big sparse model needs enormous memory to hold it but only reads its active parameters per token. The Mac Studio's weird superpower — huge memory pool, moderate bandwidth relative to a datacenter GPU — maps onto MoE architectures almost perfectly. And the open-weight frontier has been trending sharply toward MoE.

Versus the alternatives

Option	Memory	Price	The catch
NVIDIA DGX Spark	128GB unified	~$4,699	~273GB/s real bandwidth — dense 70B decode is slow
RTX PRO 6000 Blackwell	96GB GDDR7	~$8,565	1,792GB/s, actually trains things, needs a whole PC around it
RTX 5090	32GB	~$4,300+	Fastest per dollar until your model doesn't fit. Then it's over.
Mac Studio M5 Ultra	96–512GB	$5,499–$10,799+	CUDA is not here

The honest summary: NVIDIA wins tokens per second, Apple wins gigabytes per dollar. Nothing else at any price puts 256GB — soon 512GB — of fast, coherent memory in a box that draws a few hundred watts and makes no noise on your desk.

That "no noise" thing is not a joke, by the way. A 4-GPU rig in a home office is a space heater with a jet engine attached. This is a small metal cube.

The CUDA tax is the real cost. Say it out loud before you buy: vLLM's continuous batching, TensorRT-LLM, most fine-tuning tutorials, most inference-server deployment guides, and half the research code on GitHub assume CUDA. MLX is genuinely good now and Core AI looks promising, but you will hit papers with reference implementations you can't run, and you'll be waiting on someone to port things. If your production target is an NVIDIA box, developing on Apple silicon means your dev environment and your deploy environment disagree.

And for serving concurrent users, it's not close — MLX doesn't match vLLM's batching efficiency. One developer? Great. Twenty concurrent users? Buy the NVIDIA hardware.

The break-even math

The strongest financial argument for local inference is that your API bill never stops.

Take the $6,799 config. If you're spending $200/month on AI subscriptions and API credits, that's a 34-month payback. At $500/month, it's about 14 months. At $1,000/month — a small team, or one person running heavy agentic workloads — you're square in under 7 months, and the machine has residual value after that.

But be honest about three things this math hides:

Electricity and time. Not huge on a Mac, but nonzero. And the hours you spend fighting quantization configs are hours you didn't bill.
Depreciation against a moving target. Apple is already telegraphing M7 Max and M7 Ultra for 2028 with a large AI-performance jump. Hardware you buy today competes against models that get more efficient every quarter.
The frontier gap. This is the big one.

The thing most "run LLMs locally!" posts won't tell you

Local open-weight models are not the frontier models you're currently using.

If your daily driver is a top-tier hosted model for serious coding work, a Mac Studio does not replace it. It gives you a very good open-weight model that runs privately and for free-at-the-margin. Those are different products. The gap has narrowed a lot and keeps narrowing — but if you buy this expecting to cancel your subscriptions and notice no difference, you will be disappointed.

Where local genuinely wins, and wins decisively:

Data that legally cannot leave your building. Health records, client code under NDA, regulated financial data. This isn't a preference, it's a compliance requirement, and it's the single best reason to buy.
Volume grunt work. Classifying 10 million documents, generating synthetic training data, bulk embeddings. Work where a good-enough model running 24/7 at zero marginal cost beats a great model with a meter running.
Agent loops that burn tokens like oxygen. Long-running agents that iterate hundreds of times. Cost per iteration going to zero changes what you're willing to attempt.
Fine-tuning small models on your own data, where the resulting specialist beats a generalist at your narrow task.
Airplanes, and not being at the mercy of someone's rate limits.

So: who should actually buy this?

Buy the M5 Ultra if:

Privacy or compliance forces inference on-prem, and you'd otherwise be quoting datacenter hardware
You're doing local inference research where model size is the binding constraint
You're a team of 2–5 sharing one inference box (and the alternative is a $30k server)
You genuinely spend $500+/month on inference already and the workload is steady

Buy the M5 Max (40-core, $3,099) instead if:

You're a working developer who wants strong local inference and a fast build machine
128GB is enough for your models — for most people running 30B-class models with real context, it is
You want the same Neural Accelerator architecture without the Ultra tax

Honestly? For most developers reading this, the M5 Max is the right machine and the M5 Ultra is ego. Compile times, Docker, a local model for autocomplete and refactoring — 128GB handles that comfortably at half the price.

Don't buy either if:

You want maximum tokens/sec per dollar → RTX 5090
You need CUDA for training or production parity → NVIDIA, no contest
You're serving many concurrent users → vLLM on NVIDIA
Your API spend is under $100/month → the math doesn't work; it won't work.

DeviceCheck and App Attest: Stopping Fraud in iOS Apps

ArshTechPro — Mon, 24 Aug 2026 10:57:39 +0000

Your API has no idea what is calling it.

A request arriving at POST /api/redeem looks identical whether it came from your app on a real iPhone, from a modified build running on a jailbroken device, or from a Python script someone wrote after reading your traffic in Charles Proxy. HTTPS proves the connection is encrypted. It proves nothing about the client.

Apple gives you two frameworks to close that gap. This post covers what each one actually guarantees, what it does not, and how to implement both without the mistakes that show up in most tutorials.

What DeviceCheck actually does
What App Attest actually does
Choosing between them
Implementing DeviceCheck
Implementing App Attest
Fraud scenarios
Mistakes to avoid

What DeviceCheck actually does

DeviceCheck (iOS 11+) does two things, and it is worth being precise because it is routinely oversold.

One. It confirms a token came from a genuine Apple device that has your app installed, where your app is tied to your developer account.

Two. It gives you two bits of storage per device, per developer, held on Apple's servers. Two bits means four states. It survives app deletion and reinstall, which is the entire point.

That's it. Read the list again for what is not on it. DeviceCheck does not detect jailbreaks. It does not tell you whether your app binary was modified. It does not identify the user. It is not authentication.

The two-bit storage is the interesting part. Because it persists across reinstalls, it answers questions that a locally-stored flag cannot:

Has this device already claimed the new-user promo?
Has this device been flagged for chargeback fraud?

A user who deletes your app, reinstalls it, and creates a fresh account still hits the same two bits.

One gotcha: the device token from generateToken is single-use. You should treat the token you receive in the completion block as single-use — although it remains valid long enough to retry a specific request, you should not use it multiple times. Generate a fresh one per request.

What App Attest actually does

App Attest (iOS 14+) answers a harder question: is this specific request coming from an unmodified copy of my app?

It works by generating a key pair in the device's Secure Enclave. The private key never leaves the hardware and cannot be extracted. Apple then issues a certificate chain vouching that this key belongs to a legitimate instance of your app, with your Team ID and Bundle ID baked in.

Once that key is attested, your app signs each sensitive request with it. Your server verifies the signature. A tampered app cannot produce valid signatures, because it cannot get its own key attested.

The flow splits into two phases, and conflating them is the most common implementation error.

Attestation happens once per key install. Apple's servers are involved. It is relatively expensive.

Assertion happens per request afterward. It is cheap. Critically, the assertion flow is simpler than attestation, as the Apple servers are no longer involved — your server does the verification with the public key it stored during attestation.

There is no Apple REST endpoint that validates attestations or assertions for you. Your server, not the app, must validate attestations — a compromised client cannot be trusted to validate its own integrity. You parse the CBOR attestation object and check the certificate chain against Apple's App Attest root CA yourself, or you use a library that does it.

Choosing between them

	DeviceCheck	App Attest
Confirms genuine Apple device	Yes	Yes
Confirms app binary unmodified	No	Yes
Persistent per-device state	Yes (2 bits)	No
Secure Enclave keys	No	Yes
Replay protection	No	Yes (counter + nonce)
Minimum iOS	11	14
Apple servers in the loop	Every call	Attestation only
Server work	Call Apple's API	Verify crypto yourself

They solve different problems and compose well. App Attest tells you the request is authentic. DeviceCheck remembers that this device already burned its free trial. Plenty of production apps run both.

Implementing DeviceCheck

Client

import DeviceCheck

func fetchDeviceToken() async throws -> String {
    guard DCDevice.current.isSupported else {
        throw DeviceCheckError.unsupported
    }
    let token = try await DCDevice.current.generateToken()
    return token.base64EncodedString()
}

isSupported returns false on the Simulator. Plan for that in your dev workflow.

Server

You need a .p8 key with DeviceCheck enabled from the Apple Developer portal, and you sign an ES256 JWT with it. The HTTP header field in each request must contain the authentication key you receive from Apple in a JSON web token.

Three endpoints, all POST:

validate_device_token — is this a real device?
query_two_bits — read the stored state
update_two_bits — write it

Swap api.devicecheck.apple.com for api.development.devicecheck.apple.com in dev.

import jwt from 'jsonwebtoken';
import { randomUUID } from 'crypto';

function appleJWT() {
  return jwt.sign({}, PRIVATE_KEY_P8, {
    algorithm: 'ES256',
    keyid: KEY_ID,        // 10-char Key ID
    issuer: TEAM_ID,      // 10-char Team ID
  });
}

async function queryBits(deviceToken) {
  const res = await fetch(
    `https://${HOST}/v1/query_two_bits`,
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${appleJWT()}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        device_token: deviceToken,
        transaction_id: randomUUID(),
        timestamp: Date.now(),   // milliseconds, not seconds
      }),
    }
  );

  // A device with no bits set yet returns a plain-text body,
  // not JSON. Handle it before parsing.
  const text = await res.text();
  if (text.includes('Failed to find bit state')) {
    return { bit0: false, bit1: false, isNew: true };
  }
  return { ...JSON.parse(text), isNew: false };
}

Two things bite people here: timestamp is in milliseconds, and transaction_id must be unique per request. A brand-new device returns a non-JSON body, so parse defensively.

Implementing App Attest

Phase 1: attestation (once)

import DeviceCheck
import CryptoKit

func attest() async throws {
    let service = DCAppAttestService.shared
    guard service.isSupported else { throw AttestError.unsupported }

    // 1. Server issues a one-time random challenge.
    let challenge = try await api.fetchChallenge()

    // 2. Create a Secure Enclave key. Persist the ID in Keychain.
    let keyId = try await service.generateKey()
    try Keychain.store(keyId, for: "appattest.keyId")

    // 3. Hash the challenge. This must be SHA256.
    let clientDataHash = Data(SHA256.hash(data: Data(challenge.utf8)))

    // 4. Attest. Apple's servers participate in this step.
    let attestation = try await service.attestKey(keyId, clientDataHash: clientDataHash)

    // 5. Ship it to your server for verification.
    try await api.verifyAttestation(
        keyId: keyId,
        challenge: challenge,
        attestation: attestation.base64EncodedString()
    )
}

Persist that keyId. If you lose it you must attest a fresh key, and each call to generateKey returns a new keyId referring to a unique key pair — the old ones do not get replaced.

Your server then verifies the attestation object. Do not write the CBOR and X.509 parsing yourself unless you have a reason to; use node-app-attest, appattest-checker-node, or veehaitch/devicecheck-appattest for JVM.

import { verifyAttestation } from 'node-app-attest';

const { keyId, publicKey, receipt } = verifyAttestation({
  attestation: Buffer.from(req.body.attestation, 'base64'),
  challenge: storedChallenge,          // the one YOU issued
  keyId: req.body.keyId,
  bundleIdentifier: 'com.example.app',
  teamIdentifier: 'ABCDE12345',
  allowDevelopmentEnvironment: !isProd,
});

// Store publicKey for assertions, receipt for the fraud metric,
// and signCount starting at 0.
await db.saveAttestation({ keyId, publicKey, receipt, signCount: 0 });

Burn the challenge after use. A reused challenge defeats the whole mechanism.

Phase 2: assertion (every sensitive request)

func signedRequest(payload: [String: Any]) async throws -> Data {
    let keyId = try Keychain.read("appattest.keyId")
    let challenge = try await api.fetchChallenge()

    var body = payload
    body["challenge"] = challenge
    let bodyData = try JSONSerialization.data(withJSONObject: body)

    let clientDataHash = Data(SHA256.hash(data: bodyData))
    let assertion = try await DCAppAttestService.shared
        .generateAssertion(keyId, clientDataHash: clientDataHash)

    // Send bodyData AND the assertion AND the keyId.
    // The assertion object does not contain the keyId.
    return try await api.send(body: bodyData, assertion: assertion, keyId: keyId)
}

Server side, no Apple call:

const stored = await db.getAttestation(req.body.keyId);

const { signCount } = verifyAssertion({
  assertion: Buffer.from(req.body.assertion, 'base64'),
  payload: req.rawBody,
  publicKey: stored.publicKey,
  bundleIdentifier: 'com.example.app',
  teamIdentifier: 'ABCDE12345',
});

// The counter must strictly increase. A repeat or a
// decrease means someone is replaying a captured assertion.
if (signCount <= stored.signCount) {
  return res.status(401).json({ error: 'replay detected' });
}
await db.updateSignCount(req.body.keyId, signCount);

The authenticator data includes an ever-increasing counter — checking it is what gives you replay protection, and skipping the check throws that away.

The fraud metric

That receipt you stored is worth something. The fraud metric is an approximate 30-day count of unique attested keys associated with your app on a particular device, retrieved by your server from the App Attest data server using a stored attestation receipt. A device generating hundreds of keys is very likely an attestation broker feeding a bot farm. A device with two or three has probably just reinstalled the app.

Fraud scenarios

Bot traffic and credential stuffing. A script hitting your API cannot produce an assertion, because it has no Secure Enclave key and cannot get one attested. App Attest turns "rate limit the abuse" into "the abuse cannot reach the endpoint."

Simulator and emulator abuse. Both frameworks report isSupported == false on the Simulator. Free-tier farming through simulators stops working.

Repeat promo abuse. DeviceCheck's bits outlive app deletion. Set bit0 when the promo is claimed; check it before granting.

Modified builds. Someone patches your IPA to skip the receipt validation and sideloads it. The modified app's key will not attest, because the attestation includes a hash of your app's identity that Apple signs.

Account takeover. Attestation gives you a stable per-install identity independent of credentials. Stolen password plus unrecognized attested key equals a good reason to demand a second factor.

Mistakes to avoid

Treating App Attest as a boolean. Do not reject every new key for an existing user — app reinstall and device restore can legitimately invalidate a key and require key rotation. Legitimate users rotate keys. Feed the signal into a risk score; do not hard-block on it.

Validating on the client. If the app decides whether its own attestation is valid, an attacker patches out the check. Verification belongs on the server, always.

Reusing challenges. One challenge, one use, short expiry, stored server-side. Otherwise a captured assertion replays forever.

Skipping the counter check. It is three lines and it is the difference between replay protection and none.

Attesting during checkout. Perform attestation outside critical user flows when possible, retry later on failures, and use exponential backoff instead of hard-coded retry loops. Attestation can fail transiently. Do it at launch or during onboarding, not while the user is trying to pay.

Shipping the .p8 in the app. Your DeviceCheck key lives on the server. Nowhere else.

Assuming this replaces everything else. Attestation raises the cost of attack; it does not make it infinite. A determined attacker with a jailbroken device and Frida can hook the call and relay valid assertions from a script. Keep your rate limiting, your behavioral analysis, and your server-side validation.

References

How Dopamine Works: The Architecture of a Modern iOS Jailbreak

ArshTechPro — Tue, 11 Aug 2026 14:06:56 +0000

Most developers will never jailbreak a phone. That is fine. This article is not a how-to, and there is no install guide here.

What makes Dopamine worth reading as an engineer is the constraint it operates under: it has to run a full package ecosystem on an operating system that was explicitly designed to make that impossible, without modifying a single byte of the system partition, and it has to survive every process launch on the device.

Dopamine is a rootless, semi-untethered jailbreak by opa334 and évelyne, written mostly in C and Objective-C. Version support depends heavily on chip and iOS version, so check the README rather than trusting any number in a blog post.

Let's walk the architecture.

The rules of the game

Every design decision downstream falls out of what iOS enforces. Five things matter:

The system volume is sealed. Since iOS 15, the root filesystem is a cryptographically sealed snapshot. You cannot write to /usr/lib and have the device boot. So the entire jailbreak has to live somewhere else.

Code must be signed. The kernel refuses to execute pages that do not carry a valid signature chain. There is also a trust cache, a kernel-side list of hashes that are allowed to run. A tweak you compiled ten seconds ago is in neither.

Processes are sandboxed. Even as root, a process only sees what its sandbox profile allows.

Libraries are validated. Library validation means a process will typically only load libraries signed by the same team as the main binary. That is the single biggest obstacle to loading third-party code into Apple's own processes.

Memory is protected below the kernel. On modern arm64e chips there are protection layers beneath the kernel itself (PPL, and later SPTM) that guard page tables, plus pointer authentication on function pointers. Kernel read/write alone is no longer enough.

So: no writable system directory, no way to sign code, no way to load unsigned libraries, and a kernel you cannot fully trust yourself inside. Everything below is a response to one of those five facts.

Two layers

The repo splits cleanly in two:

Application/   Objective-C, UIKit. The app you tap. Orchestration, UI, logs.
BaseBin/       C, Mach, assembly. The runtime that lives on the device afterwards.

Application is the installer and control panel. BaseBin is the actual jailbreak. Almost everything interesting is in BaseBin, and it keeps running long after the app is closed.

Phase 1: exploits as plugins

The app has a DOExploitManager that selects an exploit based on the device's chip family and OS build, and a DOJailbreaker that drives the whole sequence.

The part worth stealing here is not the exploits, it is the plugin boundary. Each exploit ships as a bundle with an Info.plist declaring what it supports. The repo has several of them side by side, and the wiki has a page on adding new ones. The orchestration code does not care which one runs. It asks the manager for something compatible with this device, runs it, and gets a set of capabilities back.

This is a hardware abstraction layer, applied to bugs. When a new technique appears, you add a bundle instead of rewriting the jailbreak. Given how quickly individual entry points get patched, that boundary is the reason the project survived across four-plus years of OS releases.

Phase 2: from a bug to a stable primitive

Raw exploitation gives you something awkward and fragile. What the rest of the system wants is a clean interface: read kernel memory, write kernel memory, call a kernel function, mark this page executable.

That translation lives in libjailbreak. It also holds a table of kernel structure offsets that vary per Darwin version, because struct layouts change between iOS releases and there are no headers for the ones that matter.

That table is why version support is enumerated so precisely, and why "it should probably work on the next point release" is never true. A wrong offset is not a bug report, it is a kernel panic.

Note the layering discipline: exploitation is one module, primitives are another, and every consumer above talks to the primitive API only. A large percentage of the codebase never has to know how privileges were obtained.

Phase 3: the rootless bootstrap

The system volume is sealed, so Dopamine installs into a randomized path under /private/preboot, and exposes it at /var/jb.

If you have ever built software that must be relocatable, this will look familiar. It is /usr/local versus /usr, or a container volume mount versus the base image. Every package is compiled to reference /var/jb/... instead of /, the actual location is randomized per install, and the symlink hides that indirection from everything above.

The environment itself is a Procursus bootstrap: a proper Debian-style userland with dpkg, so packages install through Sileo or Zebra using ordinary .deb semantics.

Two things fall out of this design. Restoring the device is mostly a matter of deleting a directory, not repairing a system partition. And system updates do not fight with a modified root. "Rootless" sounds like a limitation; in practice it made jailbreaks dramatically less destructive.

Phase 4: a capability server inside PID 1

Here is the design decision I find most interesting.

You have kernel read/write. The naive approach is to hand that to every process that needs it. That is a disaster: any of them can panic the kernel, and every one of them is now a privilege escalation target.

Dopamine does the opposite. It injects a hook into launchd (PID 1), and inside it runs jbserver, a Mach service that owns the privileged primitives. Everything else is a client that sends requests over Mach or XPC via libjailbreak. Requests are organized into domains, and callers are checked for what they are allowed to ask for.

That is a broker pattern, straight out of browser sandbox design. One privileged component, a narrow typed API, everyone else unprivileged. The clients cannot corrupt the kernel because they never touch it.

Putting it inside launchd also solves persistence: PID 1 never dies while userspace is alive, so the jailbreak state outlives the app entirely.

Phase 5: getting into every process

For tweaks to work, code has to load into arbitrary system processes. Two components handle this.

dyldhook patches the dynamic linker itself. It runs before the process's main, checks the process in with jbserver to receive its sandbox extensions and environment info, and handles library validation by making sure a library's signature is registered in the trust cache before the kernel evaluates it.

systemhook.dylib is inserted via DYLD_INSERT_LIBRARIES and does the ongoing work: loading tweaks, and hooking posix_spawn and execve so that every child process inherits the injection.

That last detail is the whole trick. Think LD_PRELOAD, except it re-preloads itself into everything it spawns. Inject once into PID 1, and the property propagates down the entire process tree by induction. You never have to enumerate processes or race a launch.

Actual tweak hooking is delegated to ElleKit, an open-source hooking library that replaced the old proprietary Substrate.

Phase 6: making the system not notice

This is where most of the engineering hours actually went, and it is the least glamorous part.

Once you modify a running process, the OS starts noticing. csops reports the process as invalid. On iOS 16 the networking policy layer began checking code signing validity, which meant modified processes silently lost network access. So systemhook hooks those paths and re-validates.

On arm64e, fork() breaks, because the child needs to inherit memory protections and signing state that the kernel will not copy for it. The fix, forkfix, is a small masterpiece of pragmatism: hook __fork, use a pipe pair to freeze the child immediately after it appears, have the parent ask jbserver to apply the necessary fixups to the child PID, then let it continue.

There is also a jetsam multiplier, because processes carrying a stack of injected tweaks blow through memory limits and get killed.

None of this is the exciting part of a jailbreak. All of it is why it is usable.

Semi-untethered, and the userspace reboot

Everything above lives in memory. A real reboot wipes it, which is what "semi-untethered" means: the device boots stock, and you reopen the app to re-apply.

There is a middle option, though. A userspace reboot tears down and restarts userland without a kernel boot, which means the jailbreak state can be re-established without re-running an exploit. Practically, it turns "something broke, reboot and start over" into a thirty-second operation. launchdhook is what makes it possible, because PID 1 is where the state lives.

The map

  Dopamine.app
        |
        | selects + runs
        v
  Exploit bundle  --->  libjailbreak  (kernel primitives, version offsets)
                              |
                              v
                        launchdhook  in PID 1
                              |
                        +-----+-----+
                        |  jbserver |  <---- Mach / XPC ---- every process
                        +-----+-----+
                              |
   /var/jb  ------------------+   trust cache, sandbox extensions, fixups
   (Procursus bootstrap)
                              |
     dyldhook + systemhook injected into each process on spawn
                              |
                        ElleKit -> tweaks

What transfers to normal software

Strip away the iOS specifics and there are four patterns here worth borrowing:

Isolate the volatile part behind an interface. Exploits are plugins with declared compatibility. When your dependency on the outside world is guaranteed to break, make replacing it a config change.
Centralize dangerous capability, distribute access. One broker owns the primitive, everyone else gets a narrow API. This is browser sandboxing, syscall filtering, and jbserver, all the same shape.
Make your install root relocatable and additive. Never modify what you do not own. Add a prefix and indirect through it.
Propagate through inheritance, not enumeration. Hooking spawn beats scanning for processes, in the same way that fixing a base image beats patching running containers.

Notes

Jailbreaking is legal in many jurisdictions but not all, it voids your warranty, and the same mechanisms described here are why a jailbroken device is a weaker security boundary than a stock one. Read the code for the engineering. That is where the value is.

Xcode 27: Everything Developers Need to Know

ArshTechPro — Mon, 10 Aug 2026 10:27:47 +0000

Xcode 27 is in beta right now (beta 4 at the time of writing), and it is a big release. Apple's official release notes are lots of lines of radar numbers and one-line bug fixes, which is great as a reference and terrible as a read.

Can you even run it?

Before anything else, check these three lines:

Xcode 27 requires a Mac running macOS Tahoe 26.4 or later.
Xcode 27 only installs and runs on Apple silicon Macs. If you are still on an Intel Mac, this release is the end of the line for you.
On-device debugging supports iOS 17+, tvOS 17+, watchOS 10+, and visionOS. Older devices are no longer debuggable.

It ships with Swift 6.4 and the SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27.

Part 1: The breaking changes (read this section)

I am putting these first because they are the parts that turn into a red build log on Monday morning. Everything else is upside.

Intel is being phased out of your build settings

If a target's minimum deployment target is macOS 27.0 or DriverKit 27.0, it will no longer build Universal by default. The ARCHS_STANDARD setting drops x86_64 once MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET is 27.0 or higher.

If you still ship to Intel Macs, you have two options:

Keep your minimum deployment target below macOS 27.0.
Explicitly add x86_64 back to the ARCHS build setting.

The macOS 27 SDK can still back-deploy Universal apps down to macOS 12, so this is a default change, not a hard removal.

The old linker is gone

ld64 has been removed and the -ld_classic flag is no longer supported. If you have that flag lingering in OTHER_LDFLAGS from some 2023-era workaround, delete it now. This one is a hard failure, not a warning.

On Demand Resources is deprecated

NSBundleResourceRequest and the whole On Demand Resources system are deprecated. The replacement is Background Assets, which got a solid round of improvements this release (more on that below).

PreviewProvider is deprecated

PreviewProvider and its family of preview modifiers are now deprecated. If you still have the old struct-based previews hanging around, this is your nudge to move to the #Preview macro.

Before:

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

After:

#Preview {
    ContentView()
}

A real Swift source break

This one is subtle. A computed property that has both an init accessor and an array or dictionary literal as its initial value will no longer compile if the getter is declared before the init accessor. This is a known source break from SE-0508.

Broken:

struct S {
    var _strings: [String]
    var strings: [String] = ["hello"] {
        get { _strings }
        @storageRestrictions(initializes: _strings)
        init { _strings = newValue }
    }
}

The fix is to reorder: declare the init accessor first, then the getter. Annoying, but a one-line move.

Duplicate Clang module names now fail

The Swift dependency scanner was optimized to skip redundant header searches, and the tradeoff is that every Clang module reachable from a single dependency scan must have a unique module name. Previously the scanner tolerated duplicates; now it may error out.

The two situations that trigger this in the real world:

An SDK or project that vends the same Clang module name from more than one location on the header search path.
Vendored third-party sources shipping a module.modulemap that redeclares a module already in the SDK.

If you get a mysterious scanning error after upgrading, this is the first thing to check.

C++ changes worth knowing

If you have C++ in your app, a few things moved:

The minimum macOS deployment target for the C++ standard library is now 11.0.
multimap::find and multiset::find no longer guarantee returning an iterator to the first equal element. libc++ used to do this by accident, and the Standard never promised it. Use lower_bound or equal_range if you were relying on it.
lower_bound and upper_bound on std::map and std::set behave differently for comparators that are not a strict weak order. Defining _LIBCPP_ENABLE_LEGACY_TREE_LOWER_UPPER_BOUND gets the old behavior back, but that escape hatch is going away, likely next release.
bitset::operator[] now returns bool, which is actually what the Standard says it should do.
std::allocator is now trivially default-constructible.

The upside is significant: associative and unordered containers got up to 11x faster in some functions, several algorithms got up to 3x faster, and distance on non-random-access segmented iterators improved dramatically. A number of C++ papers landed too, including std::optional<T&>, zip, and std::views::indices(n).

Part 2: Agentic coding is now a first-class citizen

This is the headline feature, and it is a lot more than a chat box.

The assistant moved out of the sidebar

The coding assistant now lives in the editor area, not the navigator, with a redesigned conversation transcript. Artifacts the agent produces (code diffs, plans, SwiftUI preview snapshots) show up next to the transcript, and you can annotate code snippets and plan documents to give targeted inline feedback without leaving the conversation.

The sidebar is now dedicated purely to organizing conversations: real-time status, unread indicators, drag-and-drop grouping, archiving, renaming, multi-select for bulk actions, and a context menu to open conversations in new tabs, windows, or editor panes.

There is also a New Conversation button in the toolbar that works from anywhere in Xcode, with a status indicator you can click to jump to whichever conversation needs your attention.

Plan mode

Planning is now a proper feature rather than a prompting trick. Plans appear as editable Markdown artifacts next to the conversation. You review, annotate, discuss changes, and approve before the agent writes any code.

This is the workflow I would recommend for anything non-trivial: get the plan right first, then let it execute.

Agents can actually run your app

This is the part that changes what agents are useful for. In Xcode 27, agents can:

Boot simulators, install and launch apps, synthesize touch events, and capture screenshots to verify UI behavior.
Manipulate the active run state, read and interact with the debugger console.
List and switch between schemes and run destinations.
Inspect and modify build settings, compiler flags, entitlements, and Info.plist keys.
Access project insights such as crashes, disk writes, energy, hangs, and launch issues affecting your shipped app.

In other words, an agent can now write a fix, build it, run it, look at the screen, and check whether it worked.

Gemini, ACP, and plugins

Google Gemini is now available in the coding assistant alongside the existing options.
Xcode supports the Agent Client Protocol (ACP).
Agents can be extended with plugins containing skills, MCP servers, and ACP agent configurations. Skills are invokable as slash commands with completion support.
Apple ships its own specialists for targeted tasks like localization, UIKit resizing, and accessibility.
Two security-focused skills landed in beta 3: adopt-c-bounds-safety for a file-by-file -fbounds-safety adoption workflow, and audit-xcode-security-settings to suggest security-oriented build settings and entitlements.

Plugin authors can customize how their MCP servers appear in the UI using _meta fields:

{
  "name": "MyGreatPlugin",
  "description": "An awesome MCP server configuration.",
  "version": "1.0.0",
  "mcpServers": {
    "MyGreatMCP": {
      "type": "http",
      "url": "...",
      "tools": ["*"],
      "_meta": {
        "ideToolIconPath": "./icon.svg",
        "ideToolIconRendersAsTemplate": true,
        "ideToolTitles": {
          "whoami": "Who Am I",
          "get-current-email": "Get Current Email Message"
        }
      }
    }
  }
}

A sandbox for agents

Coding Intelligence includes a new security layer that monitors and controls filesystem access by coding agents and any processes they spawn. It is opt-in via Coding Intelligence settings. If you are nervous about letting an agent loose in your repo, turn this on before you do anything else.

One known issue to watch

If the "Implement the plan?" confirmation bar appears while the agent is still streaming, clicking Yes or No can start a new agent turn on top of the in-flight one and leave the conversation in a broken state. Wait for the agent to finish responding before confirming.

Part 3: Device Hub replaces the Simulator workflow

Device Hub is the new unified interface for both simulators and physical devices. Two features stand out.

Wireless pairing

You can now pair iPhone, iPad, and Apple Watch running OS 27 or later over a network. Click the + button in the Device Hub sidebar and choose "Pair Nearby Device". No cable needed for iPhone and iPad, and watch pairing is noticeably more reliable.

Mouse and trackpad gestures on iOS

Standard Mac gestures (scrolling, pinching, rotating) now work with UIKit components on iOS devices, physical or simulated.

There is a nuance worth understanding here. When you scroll with a pointing device, UIEvent.EventType.scroll is emitted. Pinch or rotate produces UIEvent.EventType.transform. But clicking with a mouse produces a simulated finger touch of type UITouch.TouchType.direct, not UITouch.TouchType.indirectPointer.

That is a convenience hybrid, not a faithful simulation. To validate real pointer behavior, use "Simulate Trackpad or Mouse" from the Device menu, test on a physical iPad with a paired pointing device, or use iPhone Mirroring.

Simulator boot is faster

Simulator runtimes now ship with a pre-built dyld cache, which makes the first launch of a simulator much faster. Small change, noticeable every single day.

Device Hub rough edges

Beta software, so expect some friction:

Game controllers only work with the visionOS simulator.
Video and input for a physical Apple Vision Pro are not supported (use AirPlay to view remotely). Everything else, like settings and DeviceFS, works.
Two-finger touches cannot be sent.
Scrolling over an Apple Watch face does not emulate the digital crown. Move the pointer over the crown in the bezel instead.
Devices may not appear during parallel testing even though tests are running. Disable parallel runs if you want to watch UI tests execute.
Downloaded app data containers land in a folder named after the bundle identifier rather than a proper .xcappdata bundle. The workaround is to rename the folder with an .xcappdata extension and nest the contents inside an AppData subfolder.

Part 4: Previews and Playgrounds

Previews got real quality-of-life work this cycle.

Argument grids

#Preview(arguments:) renders a grid of previews, one per argument. Click any cell to open it in Interactive mode. This is great for state matrices.

#Preview(arguments: [
    Order.empty,
    Order.singleItem,
    Order.manyItems
]) { order in
    OrderSummaryView(order: order)
}

Resizable canvas

iOS previews get a Resizable Canvas mode so you can view your view in arbitrarily sized containers rather than fixed device frames. Helpful for adaptive layout work, and no longer constrained to specific size ratios.

Other improvements

Each #Preview and #Playground tab can be pinned independently in the canvas.
You can preview your UI in a different localization.
Code inside #Preview now explicitly runs on the main actor, so calling main-actor-isolated APIs no longer produces concurrency warnings or runtime check failures. That was a real annoyance under strict concurrency.
Holding Command routes zoom and scroll events to the canvas. Toggleable via Editor > Canvas.
Error messages across previews are meaningfully better: clearer timeouts, full diagnostics on MCP tool failures, and a placeholder view instead of a silent macOS fallback when a runtime is not installed.

Known issue: standalone Swift files opened by double-clicking in Finder may fail to run #Playground or #Preview blocks. Use File > Open, or drag onto the Dock icon.

Part 5: Localization becomes an agent workflow

This is probably the most immediately practical feature for small teams.

Agents can now translate strings in String Catalogs, from a single feature to an entire project, into one or more languages. Xcode handles the plumbing: it adds languages to your project settings, creates missing String Catalogs, and feeds context to the agent as it translates.

The String Catalog editor has a Generate Translations button, and you can right-click specific strings to translate just those.

Supporting changes that make this workable in a real pipeline:

A localization comment of "do not translate" automatically marks the string as Don't Translate in String Catalogs and translate="no" in exported XLIFFs.
Exported XLIFFs use state-qualifier="leveraged-mt" to flag machine-translated strings, so your human translators know what to review.
You can annotate translations in String Catalog artifacts when agents are translating.
Exporting localizations now extracts NSLocalizedString and similar macros from header files, not just implementation files. That is a fifteen-year-old bug report finally closed.
The "Prepare Project for Localization" tool surfaces newly added strings as artifacts, and shows keys removed because they no longer appear in source.

The honest take: this handles the bulk of the work, but you still want a professional translator reviewing the output before you ship to a new market.

Part 6: Instruments got a serious upgrade

If you do performance work, this might be the most valuable section of the release.

Swift Concurrency tooling

A new Swift Executors instrument shows tracks for the Cooperative Thread Pool, the Main Actor, and any type conforming to TaskExecutor or SerialExecutor. Full capture on OS 27; older systems show "Unknown executor".
Task tracks now group into Swift Task Collections, sorted by name or creation site. You can switch a collection track between showing task lifetimes and task states.
Tasks, Collections, Actors, and Executors have a Profile detail showing a call tree built from data captured while the task was running. Requires recording alongside Time Profiler or CPU Profiler.
Selecting a bar chart interval in an Actor or Executor queue plot lists the waiting tasks in the inspector.
Tasks and Actors whose lifetime started before the trace now show up, on a best-effort basis.
language swift task tree in LLDB prints a tree of every Swift Task the debugger knows about.

Foundation Models instrument

New instrument for tracing and debugging Foundation Models usage: instructions, prompts, responses, token usage, and inference performance. If you are shipping on-device AI features, you now have visibility into them.

System Trace and QoS

System Trace unifies system calls, VM faults, and thread states into a single plot, with a blending algorithm that keeps dense regions readable when zoomed out. You can walk the chain of scheduling events for a thread with left/right arrow keys, and the inspector offers quick actions like pinning the thread that made another thread runnable.

The System Trace template also graphs thread priority over time, which makes priority inversion and resource starvation much easier to spot. Thread Activity now displays effective QoS by default, with requested QoS available from the track dropdown.

Everything else in Instruments

Graphs no longer rescale to the local maximum when you pan the timeline, so comparisons across tracks are consistent. Manual rescale is under View > Rescale.
Pinned tracks are restored from the previous run, and can be saved and restored explicitly via View > Track States.
A new inspector shows details for the selected event with quick actions for pinning, filtering tracks, and filtering the detail view.
os_log data can be overlaid on process and thread tracks via the Track Graph Display popover.
os_signpost gets a track per signpost name, nested under the category.
The SwiftUI instrument records more detail about layout passes and why a layout computation was not cached, plus a "Summary of Updates" focus action on the view hierarchy.
Allocations marks tagged allocations with a (tagged) suffix when the process runs with Memory Integrity Enforcement.
Drag and drop .atrc, .logarchive, or .sample files onto the sidebar to create a run for each.
Memory usage when importing .atrc files dropped by roughly 1.5 GB on average.
Animation Hitches supports visionOS 27.0 and later.

On the command line, xctrace record accepts recording options as JSON (--show-recording-options prints the available ones), xctrace export can restrict a time range, and export now takes .atrc and .logarchive directly instead of requiring an import step first.

Deprecation: Instruments now requires iOS 17, watchOS 10, or tvOS 17 as a minimum on target devices.

Part 7: Organizer and production insights

The Organizer quietly became a planning tool rather than a crash dump viewer.

Insights Overview summarizes high-impact performance regressions across metrics and diagnostic reports, so you can prioritize instead of guessing.
The Hitches metric replaces Scrolling and covers all animations in your app, not just scroll.
Storage metrics track Documents & Data and app size across releases, which catches cache bloat and bundle growth.
AI-driven analysis generates recommendations for Crash, Energy, Disk Write, Hang, and Launch diagnostics, with links into your source and the coding assistant.
Metric goals now cover Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage. Similar-app goals are supported for Hang Rate, on-screen Battery Usage, Disk Writes, and Storage, and Launch Time baselines were recalibrated.

Combined with agents having access to these insights, the loop is: Organizer flags a hang regression, you ask the agent about it, the agent reads the diagnostic and proposes a fix.

Part 8: Testing

XCUIVoiceOverService is a new UI testing API for verifying VoiceOver behavior. You can drive VoiceOver from UI tests and assert on focus, spoken output, and navigation. Accessibility testing that actually tests accessibility.
A launch test file template that opts into runsForEachTargetApplicationUIConfiguration, so the test runs across every combination of orientation, localization, and appearance your app supports.
Test plans let you choose how the system responds when the target app crashes during UI testing: off, warning, failure (the default), or fatal failure.
Mixing frameworks now warns you: calling an XCTest assertion inside a Swift Testing test (or the reverse) produces a warning-severity runtime issue. Configurable via the new interoperability setting in your test plan.
Filters were added to the test plan configurations tab, plus recent tests and open tests filters in the Test Navigator.
Large Swift Testing suites with many parameterized cases perform significantly better.
Test Repetition Mode now repeats individual Swift Testing cases instead of the whole test plan.

On the SwiftPM side, swift test summarizes failures at the end of a run, and supports --maximum-repetitions with --repeat-until [pass|fail] for hunting flaky tests. Only cases matching the condition get repeated.

swift test --maximum-repetitions 20 --repeat-until fail

Part 9: Everything else worth a mention

Interface Builder builds without a simulator

A new IB compilation mode, toolchain, is enabled by default for UIKit documents. It compiles IB documents without downloading a simulator, which is a genuine win for CI and build servers.

Background Assets

Since On Demand Resources is deprecated, this matters:

Asset-pack manifests support path wildcards, file exclusion, hard-coded source roots, and custom destination subpaths.
Localized asset packs: the system delivers only the packs matching the user's preferred languages, cutting storage usage.
A Steam Asset Converter turns Steam depots into asset packs.
Xcode can serve asset packs to your app while debugging on device. Set a Background Asset Packs folder in the Run scheme action's Options tab.

StoreKit testing

New configuration UI for In-App Purchase offer codes, plus off-device purchase options to test them through the Transaction Manager.
Subscription Bundles and Subscription Suites can be configured for local testing.
Volume purchase transactions can be created for 1-month and 1-year auto-renewing subscriptions.

Swift and C++ interoperability

C++ constructors with default parameter expressions no longer require passing every argument explicitly from Swift.
Swift closures convert to std::function instances.
__counted_by and __noescape-annotated std::span parameters map to Swift Span without the experimental feature flag. Return values via __lifetimebound still need it.
Safe wrappers can be generated for functions taking std::span directly, without hiding the instantiation behind a typedef, as long as the parameter is __noescape.
The new SWIFT_REFCOUNTED_PTR macro bridges smart pointers to intrusively reference-counted types into Swift classes.

Debugging

LLDB can inspect data types with ~Copyable fields in the standard library and system frameworks.
LLDB ships with an MCP server (lldb-mcp).
In projects using bridging headers, LLDB imports explicitly built Swift modules and PCH from DerivedData directly. This can dramatically speed up the first po in a debug session, which has historically been painfully slow.

Documentation search

You can search developer documentation using natural language, with results matched semantically rather than by keyword.

Icon Composer 2.0

Supports a sharper rendering mode for the 2027 operating systems, with refractivity, outside specular, and deeper shadows. Edit the new properties in the group inspector and preview either design generation from the toolbar. One icon covers all OS versions.

Migration checklist

If you want the short version, here it is:

Confirm you are on an Apple silicon Mac with macOS Tahoe 26.4+.
Remove -ld_classic from your linker flags.
Decide your Intel story: lower your deployment target, or add x86_64 to ARCHS explicitly.
Migrate PreviewProvider to #Preview.
Plan the move from On Demand Resources to Background Assets.
Check for duplicate Clang module names if dependency scanning starts failing.
Fix any init accessor ordering issues flagged by the Swift compiler.
If you use C++, audit multimap/multiset find usage and any custom comparators.
Turn on the agent filesystem security layer before letting agents run.
Drop your minimum device targets for testing to iOS 17 or later.

Reference
Source: Xcode 27 Release Notes

Reasonix - Deepseek: A Terminal Coding Agent Built Around the Thing Everyone Else Ignores

ArshTechPro — Wed, 05 Aug 2026 18:27:59 +0000

Most terminal coding agents are architecturally similar: a loop, a tool registry, some context management, a TUI. Reasonix picks a different thing to optimize for, and it is a thing that shows up on your bill rather than in a demo video.

The tagline is "engineered around prefix-cache stability — leave it running." That phrase is doing a lot of work, so let's unpack it.

Why prefix caching is the whole pitch

DeepSeek's API, like several others, caches the prefix of your prompt. If the next request starts with the exact same token sequence as the previous one, the provider serves those tokens from cache and bills them at a small fraction of the normal input rate. Cache hits are dramatically cheaper than cache misses.

Here is the catch: it is a prefix cache. The match has to start at token zero and run forward. Change one character near the top of your context and every token after it is a miss.

Now think about what a typical agent harness does over a long session. It re-summarizes the conversation. It injects a fresh timestamp or a re-scanned directory tree at the top. It reorders tool definitions. It rewrites the system prompt when you switch modes. Every one of those is a mutation near the front of the context, and every one of them silently invalidates the entire cache.

The result is an agent that feels fine and costs several times what it should. You do not notice, because nothing errors. You just watch the number go up.

Reasonix's central design constraint is: don't do that. Keep the front of the context stable, append rather than mutate, and put churn where it costs least.

What that looks like in practice

A small, stable environment summary is injected at startup rather than regenerated each turn.
Stale tool output gets snipped and pruned before summary compaction kicks in, so a giant cat result from twenty turns ago is not still sitting in your prefix.
The built-in tool schema contract is documented and regression-reviewed, because a silent tool-definition reshuffle is a cache invalidation with no visible symptom.
Two-model mode (executor plus planner) runs each model in its own separate, cache-stable session instead of interleaving them into one context.

That last one is the neatest idea in the project. The naive way to add a planner is to inject planning turns into the same conversation, which trashes cache stability for both roles. Keeping them in separate sessions means each one's prefix stays intact.

The rest of the architecture

A single static Go binary. CGO_ENABLED=0, cross-compiles to six targets, and the only dependency is a TOML parser. No Node runtime, no Python venv, no dependency tree to audit.

Config-driven, not model-hardcoded. Providers, agent settings, enabled tools, and plugins all live in a reasonix.toml. DeepSeek ships as a preset, but any OpenAI-compatible endpoint is a config entry rather than a code change. Secrets come from the environment and are never written into the config file. Despite the repo name, this is not DeepSeek-only, and it is not an official DeepSeek project — it is a community project that treats DeepSeek as the first-class default.

MCP client. External tools run as subprocesses over stdio JSON-RPC, or over Streamable HTTP for remote servers. If you already have an .mcp.json, drop it in the project root and it is read as-is. Server prompts show up as slash commands, and resources are pulled into a message with @server:uri.

Permissions and sandbox are separate mechanisms. Permissions are policy: each tool call is evaluated deny, then ask, then allow, then fallback, and approvals are stored as reusable rules like Bash(go test:*) rather than one-off clicks. The sandbox is enforcement: file writers refuse any path outside the workspace root, resolving symlinks and .. so a link cannot tunnel out.

One caveat worth knowing before you use the autonomous mode: bash itself is jailed via Seatbelt on macOS, but on other platforms it currently runs unconfined. On Linux or Windows, your deny list is the real boundary, not the sandbox. Write it accordingly.

Getting started

npm i -g reasonix    # or: brew install esengine/reasonix/reasonix

reasonix setup       # pick a provider, set your key
reasonix             # start an interactive session

That is genuinely the whole first run. There is also a desktop app and a VS Code extension that drive the same local engine, plus prebuilt archives on every release if you would rather not go through npm. Everything else — the TOML schema, permission rules, MCP plugins, custom slash commands, two-model setup — is in the Guide, and none of it is required to try the thing.

Two commands worth knowing on day one: /init generates project instructions, and /branch <turn> forks the conversation from an earlier checkpointed turn. That second one is a much better recovery move than clearing context and re-explaining everything when the agent goes down a bad path.

Is it worth a look?

Yes, if: you already pay for DeepSeek or another OpenAI-compatible endpoint and run long agent sessions, you are cost-sensitive enough to care about cache hit rates, or you want a single static binary instead of a Node or Python install. The MCP support, config-first design, and permission rules are all solid, and the project has real traction — tens of thousands of stars, an active contributor list, CI, code-signed Windows builds, and a bilingual Discord.

Probably not, if: you are locked into a provider without prefix caching, in which case the core optimization is irrelevant and you should pick a harness on other merits. Also skip it if you need a mature autonomous-mode sandbox on Linux or Windows today — that is still on the roadmap.

Things to go in knowing. The active branch is main-v2, not main, which is mildly confusing when you clone. If you are on a 0.x config, there is a migration guide, and your old MCP servers are still read as a lowest-priority source. The issue and PR counts are large, which is what you would expect from a fast-moving project at this size — read it as activity, not instability, but check the changelog before upgrading anything you depend on. And the repo name genuinely does mislead people: this is a community project, not something DeepSeek ships.

The reason I would look at it even if you never install it is the design argument. Most agent harnesses treat context management as a correctness problem: keep the model informed, drop the irrelevant. Reasonix treats it as an economics problem too, where the ordering and stability of your context is a cost variable you control. That reframing is worth twenty minutes of reading whatever tool you end up using.

Repo: https://github.com/esengine/DeepSeek-Reasonix

LoopX: A Control Plane for AI Agents That Have to Keep Working for Days

ArshTechPro — Wed, 05 Aug 2026 18:23:46 +0000

If you have ever pointed a coding agent at a multi-day goal, you know the failure mode. It is not that the model writes a bad function. It is that on turn 40, the agent no longer remembers what the objective was, which decision you already made, what is out of scope, or what the last run actually proved. The context window rolled over, and the plot went with it.

LoopX is an attempt to fix that specific problem. It calls itself "loop engineering for long-running AI agents," and it is a local control plane that sits above your agent runtime rather than replacing it.

The one-sentence version

Your agent (Codex, Claude Code, Cursor, whatever) executes bounded loops. Something (a heartbeat, a cron job, you hitting enter) triggers the next loop. LoopX holds the state that has to survive between those loops.

The project draws the separation like this:

Layer	Role
Codex / Claude Code / Cursor	Execute a bounded agent loop: read, write, run commands, respond
Goal mode / automation / CLI / TUI	Trigger or schedule the next loop
LoopX	Preserve goals, gates, todos, run history, quota, evidence, handoff state

That third row is the whole product. LoopX is not an executor and not an autonomous production controller. It is a state kernel with a CLI.

Why "just use a todo file" isn't enough

A TODO.md plus a long system prompt gets you surprisingly far. It falls over once any of these become true:

The goal changed halfway through, and nothing recorded why.
A decision genuinely needs a human, and that request evaporated into a chat message nobody read.
Two agents are touching the same repo and neither knows who owns what.
The last run claimed success, and there is no artifact proving it.
Some work is safe and read-only, some crosses into writes, production, or private data, and the distinction lives only in your head.

LoopX makes those things explicit and machine-readable, which is what lets a loop run longer without becoming less accountable.

The concepts, in plain English

Lifetime goals. A durable project intention that outlives one chat thread. Importantly, a lifetime goal does not hand the agent open-ended autonomy: only the next bounded transition is executable.

User gates. A concrete decision that belongs to you, recorded as a first-class object instead of a sentence in a transcript. The loop can see that it is blocked on a human.

Safe fallback. When one lane is gated, audited side paths can keep moving without bypassing the gate. This is the part I find most interesting: the alternative designs are usually "block everything" or "let the agent decide," and both are bad.

Todo ownership. Todos are tagged user or agent, with a claimed_by field so multiple agents can coordinate instead of colliding.

Quota. A guard that answers whether an automatic turn should run right now, wait, ask the user, self-repair, or stay quiet. Practically, this is your defense against a heartbeat loop burning tokens on turns that cannot produce a verified transition.

Run history and evidence. Compact append-only events for progress, validation, blockers, rewards, and quota spend.

Public/private boundary checks. A local scan that tries to keep credentials, raw logs, local paths, and private state out of anything you publish.

Setup

Requirements are refreshingly light: Python 3.11+, curl, tar, and a macOS or Linux shell. The Python package has no runtime dependencies outside the standard library. Git is only needed if you want to contribute.

1. Install (no clone)

curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor

The installer drops a release snapshot under ~/.local/share/loopx/releases/, a CLI wrapper in ~/.local/bin, a man page, and reusable agent skills under ~/.codex/skills. As always, read a piped install script before running it if that matters to you.

Updates go through an explicit interface rather than re-running the installer blind:

loopx update --check     # read-only
loopx update --dry-run   # read-only
loopx update --execute

2. Kick the tires without touching a real repo

loopx demo
cd /tmp/loopx-demo
loopx status
loopx quota should-run --goal-id demo-goal
loopx history --goal-id demo-goal

This creates a disposable goal with one user todo and one agent todo. You should see ok: True and a should_run=True / state=eligible quota response. Do this first. It takes thirty seconds and tells you whether the mental model clicks for you.

3. Connect a real project

cd /path/to/your-project
loopx bootstrap \
  --goal-id your-project-goal \
  --objective "Improve this project through bounded, verified goal segments." \
  --goal-doc GOAL.md

loopx connect is an alias for bootstrap. This creates:

your-project/
  .loopx/registry.json
  .codex/goals/your-project-goal/ACTIVE_GOAL_STATE.md

~/.codex/loopx/
  goals/<goal-id>/runs/

Add these to .gitignore before you commit anything:

.loopx/
.codex/goals/
.opencode/goals/
goals/**/ACTIVE_GOAL_STATE.md

That state is live local runtime data. Committing a controller's active goal state is how private paths and internal notes end up in a public repo.

A healthy connection means loopx doctor passes, both files above exist, loopx status shows who acts next, and none of it is staged for commit.

4. The agent-first path

The docs actually push you toward not running these commands yourself. Paste something like this into Codex, Claude Code, or Cursor from your project root:

Connect the current project to LoopX. Do not clone the LoopX repository.
If `loopx` is not on PATH, install it with the official no-clone installer.

Then run `loopx doctor`. Working only from the current project root:
1. If LoopX state already exists, reuse it. Do not overwrite the goal or objective.
2. If the project is not connected, prefer `loopx connect`; use `loopx bootstrap`
   only when state clearly needs initialization.
3. Ensure `.loopx/`, `.codex/goals/`, and `.local/` are ignored.
4. Set up the thin LoopX heartbeat for this surface.
5. Stop after setup and report the active state id, current user gate, top agent
   todo, and next safe action.

Do not start longer delivery work in this setup turn.

One caveat worth knowing before you try this with a non-Codex agent: LoopX can only drive an agent that exposes at least one control hook, such as shell execution, a goal/task command, an automation hook, or its own scheduler. Without one, LoopX still tracks state, but you run the commands by hand.

5. The daily loop

loopx status
loopx history --goal-id your-project-goal
loopx quota should-run --goal-id your-project-goal

Adding work:

loopx todo add --goal-id your-project-goal --role agent \
  --text "Run the next bounded validation slice."

Diagnosing is also meant to be delegated. loopx diagnose deliberately emits an agent-facing evidence packet rather than a verdict, so you ask your agent to run it and reason from it: can this project self-drive, what blocks it, what exact question needs your answer, what happens next.

6. Heartbeats and quota (the token-spend part)

An automatic turn is supposed to check quota before working and record spend exactly once after validated writeback:

loopx quota should-run --goal-id your-project-goal
loopx heartbeat-prompt --thin --goal-id your-project-goal
loopx quota spend-slot --goal-id your-project-goal --slots 1 --source heartbeat --execute

Spend is not appended for quiet skips, preflight failures, or dry runs. should-run returns a fairly rich contract: whether delivery may run, what it is waiting on (user, controller, external evidence, health, quota), the work lane, todo summaries, and the spend policy.

7. Before you publish anything

loopx check --scan-path README.md --scan-path docs/ --scan-path examples/

8. Optional local dashboard

There is a read-first React dashboard for inspecting projects, todos, gates, and evidence across a global registry. It is explicitly experimental: the CLI stays the source of truth and browser writes require local opt-in. Check the repo docs for the current path, since it moved between the README and the getting-started guide.

What it deliberately does not do

The maintainer is unusually direct about this, which is a good sign. LoopX is not a full agent platform, not an autonomous production controller, and not a replacement for your runtime. Project ownership and dangerous permissions stay with the human. It is a local coordination substrate.

Is it worth a look?

Yes, if: you are running agents on goals that span days, you have heartbeat or monitor-style turns firing on a schedule, you coordinate a controller agent with scoped side agents, or you have already been bitten by an agent confidently redoing work it finished last Tuesday. The demo costs you a minute, and the ideas are portable even if you never adopt the tool.

Probably not yet, if: you use agents for single-session tasks, you are on Windows without WSL, you need something battle-tested with a release history and a large user base, or you do not use Codex-family or shell-capable agents. The value shows up proportionally to how long your loops run. Short loops do not drift, and the ceremony will feel like overhead.

Repo: https://github.com/huangruiteng/loopx

Qwen3.8-Max Just Went GA: A Developer's Guide to Alibaba's 2.4T Model

ArshTechPro — Mon, 03 Aug 2026 22:40:19 +0000

Alibaba made Qwen3.8-Max generally available on August 3, 2026.
This is a practical rundown for developers: what the model is, what it costs, how to call it, and where the claims still need a pinch of salt.

The one-line version

Qwen3.8-Max is a 2.4-trillion-parameter Mixture-of-Experts model with a 1M-token context window, native text/image/video input, OpenAI-compatible API, and pricing of $2 in / $6 out per million tokens. Open weights are promised for next week.

First, the naming confusion

The version number trips people up, so let's clear it up:

Qwen3 is the open-weight model family you've probably used (Qwen3-32B, Qwen3-235B-A22B, etc.)
Qwen3.5 / 3.6 / 3.7 / 3.8 are successive flagship generations, not point releases of Qwen3
"Max" is the top tier of each generation

So Qwen3.8-Max is not "Qwen 3, version 8." It is the newest flagship, and it succeeds Qwen3.7-Max from May 2026. Qwen describes it as their most capable model to date, and the first open-weight model at Max scale.

Also note there is a Qwen3.8-Max-Preview (July 19) and now Qwen3.8-Max (August 3, GA). If you're reading a blog post from July, it's about the preview, and half its "not disclosed yet" list has since been answered.

The specs that matter

Spec	Value
Total parameters	2.4 trillion (sparse MoE)
Active parameters per token	~95 billion (reported)
Context window	1,000,000 tokens
Max input	991K tokens (983K with thinking on)
Max output	131K tokens
Max reasoning budget	262K tokens
Input modalities	Text, image, video
Output	Text
Rate limits	2M tokens/min, 15K requests/min
Model ID	`qwen3.8-max`

Why "95B active" is the number to care about

This is the part worth understanding properly, because "2.4 trillion parameters" is close to meaningless on its own.

A sparse Mixture-of-Experts model is not one giant network. Each layer holds many specialist sub-networks ("experts"), and a router picks a small handful for each token. The rest sit idle for that token.

Qwen's own smaller models make the pattern obvious from the naming: Qwen3-235B-A22B carries 235B total parameters but activates 22B per token, and Qwen3-30B-A3B activates roughly 3B.

So:

Total parameters ≈ how much the model knows (and how much memory you'd need to host it)
Active parameters ≈ how much compute each token actually costs

At 2.4T total / ~95B active, roughly 4% of the network fires per token. That's why Alibaba can sell it at $2/M input rather than something ruinous.

One honesty note: this figure needs a small asterisk. MarkTechPost's launch coverage stated Alibaba had not disclosed the activated-parameter count, while benchmark trackers report that Qwen's own August 3 release post lists 2.4T total with 95B active. Other coverage advises treating the number as reported rather than confirmed until Alibaba publishes a model card. Use it for rough cost intuition, not for capacity planning.

And to be clear: 95B active does not mean you can serve this on a 95B-sized box. A serving system still needs fast access to the full expert pool, plus attention state, routing machinery, multimodal components and runtime buffers. The whole 2.4T checkpoint has to be resident somewhere.

Pricing, and the one trick that dominates your bill

Item	Price per 1M tokens
Input	$2.00
Output	$6.00
Input (implicit cache read)	$0.25
Explicit cache creation	$2.50
Explicit cache read	$0.17

Here's the thing to internalize: cached input is eight times cheaper than fresh input, which means prefix stability drives your cost more than prompt length does.

That single sentence should change how you architect against this model. Concretely, imagine an agent loop with a 200K-token stable prefix (system prompt, tool schemas, codebase context) running 50 turns:

No caching:      50 × 0.2M × $2.00                = $20.00
Explicit cache:  (0.2M × $2.50) + (50 × 0.2M × $0.17) = $2.20

Roughly a 9x difference, from nothing but keeping your prefix byte-stable. Practical implications:

Put everything static at the front of your prompt, and everything variable at the end
Don't inject timestamps, request IDs or shuffled context into your system prompt
If you're rebuilding the prefix per request, you're paying 8x for no reason

Compare against the field: Kimi K3 runs $3.00 input / $15.00 output per million tokens, so Qwen3.8-Max undercuts it meaningfully, particularly on output.

Calling the API

Integration is deliberately boring, which is the point. The hosted API is OpenAI- and DashScope-compatible, so integration is a base-URL and model-ID change. It also supports the Anthropic protocol, so tools such as Cursor, Cline, Codex and Claude Code can point at it through existing integrations.

Here's the multimodal example straight from the model page, using the DashScope SDK:

import os
import dashscope

dashscope.base_http_api_url = "https://dashscope-intl.aliyuncs.com/api/v1"

messages = [
    {
        "role": "user",
        "content": [
            {"image": "https://example.com/your-image.jpeg"},
            {"text": "What is depicted in the image?"}
        ]
    }
]

response = dashscope.MultiModalConversation.call(
    api_key=os.getenv('DASHSCOPE_API_KEY'),
    model='qwen3.8-max',
    messages=messages
)

print(response.output.choices[0].message.content[0]["text"])

If you're already on the OpenAI SDK, you point base_url at Alibaba's compatible-mode endpoint and change the model string to qwen3.8-max. Grab the exact base URL from docs.qwencloud.com rather than guessing, since it differs between the international and China-domestic deployments.

Watch out for the two regional endpoints. Availability is split between an international deployment (qwencloud.com) and a China-domestic one (platform.qianwenai.com), each requiring separate registration and billing. Keys are not interchangeable.

It's also on third-party gateways already. Vercel's AI Gateway added it as alibaba/qwen3.8-max on August 2 at provider pricing with no markup.

Supported features

Function calling, structured outputs, batches, prefix completion and fine-tuning are all supported. Five built-in tools ship on the Responses API: code_interpreter, web_search, web_extractor, t2i_search and i2i_search.

The built-in tools are worth a look before you hand-roll your own. If you're currently maintaining a custom web-search tool wrapper, that's now a server-side flag.

Benchmarks: the honest read

Unlike the July preview, GA came with actual numbers. Alibaba published a benchmark table with the formal launch showing 86.6 on Terminal-Bench 2.1, 67.7 on SWE-bench Pro, and 92.6 on GPQA Diamond, with the strongest gains in multimodal and agentic categories rather than general reasoning.

Filling in the competitive picture:

Benchmark	Qwen3.8-Max	Claude Fable 5	Notes
Terminal-Bench 2.1	86.6	84.6	GPT-5.6 Sol (max) leads at 88.8
SWE-bench Pro	67.7	80.0	Fable 5 ahead
FrontierSWE	73.5	88.8	Fable 5 ahead
GPQA Diamond	92.6	—	Up marginally from 3.7-Max's 92.4
PaperBench	93.0	—	Qwen leads
IFBench	82.8	—	Qwen leads

It also tops most vision rows, including OSWorld-Verified at 86.1, Parametric CAD Bench at 91.5, and OmniDocBench 1.5 at 92.1. Against its own predecessor the jump is large: DeepSWE 1.1 moves from 21.6 to 56.6, FrontierSWE from 40.7 to 73.5, and JobBench from 31.3 to 53.4.

Two caveats that belong in any fair reading, both flagged by MarkTechPost: the multimodal table benchmarks against Qwen3.7-Plus rather than Qwen3.7-Max, which flatters the generational delta; and Alibaba's own RL scaling curve peaks at 0.725 near 4,000 training environments, then declines to 0.719 and 0.689.

Open weights: read the fine print

Alibaba confirmed open weights ship next week, along with a second checkpoint, Qwen3.8-27B. Releases are expected the week of August 10 via Alibaba Cloud Model Studio. This marks Alibaba's return to open-sourcing its top-tier models after keeping several recent flagships proprietary earlier this year.

What's still missing

Being straight about the gaps:

No model card. The GA launch still did not provide an official training and safety model card. No training data disclosure, no safety evaluation methodology.
No published license. Until the weights land, there's nothing to review on commercial-use terms.
Active parameter count is reported, not officially confirmed in a spec sheet.
No independent Artificial Analysis score yet.

Should you use it?

Try it now if: you're doing multimodal work (documents, video indexing, screenshots, UI automation), you want long-context agent runs at a fraction of Western frontier pricing, or you have an existing OpenAI/Anthropic-protocol setup where testing costs you a base-URL change and an afternoon.

References:

Qwen3.8-Max model page (QwenCloud) — canonical specs, pricing, rate limits

Running this in production yet? I'd be interested in real latency and tokens-per-second numbers, since Alibaba hasn't published throughput figures.

AirLLM Runs a 70B Model on a 4GB GPU. It's True, and That's Not the Interesting Part

ArshTechPro — Mon, 03 Aug 2026 22:23:56 +0000

AirLLM's README opens with a line that sounds like it can't be true:

AirLLM dramatically reduces inference memory usage, letting 70B large language models run on a single 4GB GPU card — without quantization, distillation, or pruning.

So let's actually check it. Is the claim real? How do you set it up? And — the question nobody asks loudly enough — should you?

TL;DR: The claim is technically true and the engineering is legitimate.

The trick, in one paragraph

Here's the thing about a transformer: it's a stack of layers, and it runs them in order.

Input → Layer 1 → Layer 2 → Layer 3 → ... → Layer 80 → Output

When Layer 1 is computing, layers 2 through 80 are just... sitting in your VRAM. Doing nothing. Taking up space.

Normal inference loads all 80 layers into GPU memory because keeping them there is fast. AirLLM asks the obvious follow-up question: what if we didn't? Load Layer 1, run it, throw it away, load Layer 2, run it, throw it away.

Now your VRAM requirement isn't "the size of the model." It's "the size of the single largest layer."

For a 70B model at full FP16 precision, that's roughly 1.75GB per layer. Which fits in 4GB with room to spare. The model is still 140GB — it just lives on your disk instead of your GPU, streaming through one slice at a time.

That's it. That's the whole idea. And it genuinely works.

Fact-check: is the claim real?

Yes — with an asterisk the size of the model itself.

Let's take the claims one at a time.

"70B on a single 4GB GPU"

Real. The math checks out (~1.75GB per layer at FP16), and it's been independently reproduced by enough people that this isn't in dispute.

"Without quantization, distillation, or pruning"

Real, and this is the genuinely interesting part. Most "run big models on small hardware" tricks work by making the model worse — squashing weights from 16 bits to 4, which costs you some accuracy. AirLLM doesn't have to. You get the actual, unmodified, full-precision model.

(Quantization is optional here — you can pass compression='4bit' to make it faster. But you don't have to, and that's the distinction they're drawing.)

The bigger numbers, too

The README's scaling table looks absurd but follows from the same logic:

Model	Size	Claimed VRAM
Llama 3.x 70B	70B	~4 GB
Llama 3.1 405B	405B	~8 GB
DeepSeek-V3	671B	~12 GB
Qwen3-235B (MoE)	235B	~3 GB
Kimi K3 (MoE)	2.8T	~3.7 GB

Notice something weird? The 2.8-trillion-parameter model needs less VRAM than the 671B one.

That's not an error. Those are Mixture-of-Experts models. An MoE layer contains hundreds of "expert" sub-networks, but each token only routes to a handful of them. Per the v3.1.0 release notes, Kimi K3 holds 896 experts per layer and routes each token to just 16 — so while a full layer's experts expand to ~55GB, a single token only actually needs ~1GB of them. AirLLM streams just those experts instead of the whole layer.

Sparser model → smaller working set → less VRAM. Counterintuitive, correct.

What the headline leaves out

Here's the part that isn't in the big bold text. From AirLLM's own v3.1.0 release notes, measured on an RTX 6000 Ada:

Metric	Value
Peak VRAM during generation	3.72 GB
One-time init	900 seconds
Generation speed	292 s/token, disk-bound

To be clear about what that means: a 100-token response would take just over 8 hours.

Credit where it's due — the maintainer publishes this honestly in the release notes. It's just not the number on the marketing line.

For more typical setups, community reports land in the range of:

70B on a decent NVMe: roughly 5–35 seconds per token
70B on a MacBook: reports as low as ~0.07 tokens/sec (~14 s/token)
For comparison, llama.cpp with a quantized 70B on an RTX 4090: 8–15 tokens per second

So the honest version of the claim is:

AirLLM doesn't make 70B fast on a 4GB GPU. It makes 70B possible on a 4GB GPU.

Why it's slow (do this math once and you'll never be confused again)

This is worth internalizing, because it explains everything and it's not complicated.

To generate one token, the model must run every single layer. Which means AirLLM must read the entire model off disk — for every token.

So:

seconds per token ≈ model size on disk ÷ disk read speed

Let's plug in a 70B model at FP16 (~140GB):

Storage	Speed	Time per token
Gen4 NVMe SSD	~7 GB/s	~20 s
Gen3 NVMe SSD	~3.5 GB/s	~40 s
SATA SSD	~0.5 GB/s	~280 s
Spinning HDD	~0.15 GB/s

Your disk is your inference engine. The GPU is barely working — it's sitting idle waiting for data. This is why AirLLM users report their fans screaming and their laptop becoming unusable: the bottleneck is I/O and CPU, not compute.

Two consequences that fall right out of this formula:

Use compression='4bit'. It shrinks the bytes you have to read by ~4x. The README advertises up to 3x speedup, and now you know exactly why — this isn't about faster math, it's about moving less data.
RAM is secretly your best upgrade. If your system RAM can hold a big chunk of the model, the OS page cache serves layers from memory instead of disk. This is why people with 128GB machines report dramatically better numbers than the raw disk math predicts.

Setup

Requirements — read this part before you start

Disk space is the #1 thing that will bite you. AirLLM downloads the model, then decomposes it into per-layer shards. For a while, you have both copies on disk.

For a 70B FP16 model, budget:

~140GB (original download)
+ ~140GB (layer shards)
= ~280GB free space

The single most common error in the repo's FAQ — safetensors_rust.SafetensorError: Error while deserializing header: MetadataIncompleteBuffer — is, per the maintainers, almost always just you ran out of disk.

You'll also want:

An NVMe SSD (not SATA, definitely not HDD)
As much system RAM as you can get
A Hugging Face token for gated models like Llama
Patience. Real, genuine patience.

1. Install

pip install airllm

For the 4-bit compression speedup (recommended — see the math above):

pip install -U bitsandbytes

2. Run it

from airllm import AutoModel

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",
    compression='4bit',        # ~3x faster; skip for full precision
    delete_original=True,      # deletes the original after splitting — saves ~50% disk
    profiling_mode=True,       # logs per-layer timing so you can see the bottleneck
)

input_text = ['What is the capital of United States?']

input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False,             # avoids a common tokenizer error
)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(generation_output.sequences[0]))

That's the whole API. Swapping to a 671B model is a one-line change:

model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")   # 671B, ~12GB VRAM

Start small. Please run an 8B model first to validate your setup before committing 280GB and several hours to a 70B download.

3. Useful config flags

Flag	What it does
`compression`	`'4bit'` or `'8bit'` block-wise quantization — biggest speed lever
`delete_original`	Deletes the original download after splitting; halves disk usage
`layer_shards_saving_path`	Put shards on a different (faster/bigger) drive
`profiling_mode`	Logs time consumption per layer
`hf_token`	For gated models (Llama, etc.)
`prefetching`	Overlaps loading and compute (~10% gain); on by default

Common errors, decoded

Error	Actual cause
`MetadataIncompleteBuffer`	Out of disk space. It's basically always this.
`401 Client Error... Repo is gated`	Pass `hf_token='...'`
`Asking to pad but the tokenizer does not have a padding token`	Set `padding=False`
`ValueError: max() arg is an empty sequence`	Use `AutoModel`, not a specific model class

macOS

Works on Apple Silicon only. Install mlx plus torch, and make sure you're on native (not Rosetta) Python. Same code otherwise.

Is it worth checking out?

Depends entirely on which of these you are.

Skip it if you want to chat with a big model

This is the fantasy that draws people in, and it just doesn't work. Interactive chat needs ~20+ tokens/sec. AirLLM gives you seconds-to-minutes per token. You will not be having a conversation.

Skip it if you're doing serious volume

Every token reads tens of GB off your SSD. Consumer NVMe drives are rated for a finite number of terabytes written; hammering one with continuous full-model reads and shard rewrites is not what it was designed for. Also, your machine will be effectively unusable while it runs.

It's genuinely great for offline batch work

This is the real use case, and it's underrated.

The killer insight: the expensive part is loading a layer, not using it. So if you load Layer 1 and run 50 prompts through it before moving on, you amortize that cost 50 ways.

One reported benchmark: 35 s/token for a single prompt vs 5.3 s/token when batching 50 — a 6.6x improvement for free.

So if you have 10,000 documents to classify overnight and no GPU budget, AirLLM is a legitimately reasonable tool. Latency doesn't matter when nobody's waiting.

It's great if you need full precision, specifically

Research on quantization effects, numerical reproducibility, evaluating a model as-published — cases where a 4-bit approximation defeats the point. AirLLM is close to the only way to do this on hardware you already own.

The verdict

The claim is real. 70B on 4GB VRAM, full precision, no tricks in the "lying" sense. The engineering is clever and the MoE expert-streaming work is legitimately impressive.

The framing is the problem. "Run 70B on a 4GB GPU" implies you get 70B-quality answers on cheap hardware. What you actually get is 70B-quality answers eventually — at a pace measured in minutes per token, with your SSD as the engine and your GPU mostly idle.

AirLLM didn't remove the cost of running a huge model. It moved it — out of VRAM, into time and disk I/O. Whether that's a good trade depends entirely on whether you have more time than money.

Links:

AirLLM on GitHub

Have you actually run this on real hardware? I'd love to hear your tokens/sec and your disk setup in the comments — the community numbers vary wildly and more data points would help.

DEV Community: ArshTechPro

Humanizer: The 40k-Star Agent Skill That Strips AI Tells From Your Writing

It is a Markdown file

How it works

Does it work with Claude?

Does it work with other agents?

What it does not do

Worth using?

TimesFM: Google's Foundation Model for Time Series, Explained for Developers

The mental model: patches are tokens

Getting started

The 2.5 API

What changed in 3.0

The catch nobody mentions in the benchmark charts

Is it worth a try?

Where to go next

Omarchy: an opinionated Arch install that ships someone else's taste

What it actually is

Installation

The keyboard-first part

The AI-workstation angle

The maintenance question

Where I'd push back

Is it worth a try?

Ponytail: the AI coding skill that makes your agent write less code

The idea in one screen

Installing it

The commands

What the numbers actually say

Where I'd push back

Is it worth a try?

The M5 Ultra Mac Studio: I Did the Math So You Don't Have To

What actually changed (and what's marketing)

The pricing trap nobody will put in the headline

The only formula you need

Versus the alternatives

The break-even math

The thing most "run LLMs locally!" posts won't tell you

So: who should actually buy this?

DeviceCheck and App Attest: Stopping Fraud in iOS Apps

Table of contents

What DeviceCheck actually does

What App Attest actually does

Choosing between them

Implementing DeviceCheck

Client

Server

Implementing App Attest

Phase 1: attestation (once)

Phase 2: assertion (every sensitive request)

The fraud metric

Fraud scenarios

Mistakes to avoid

References

How Dopamine Works: The Architecture of a Modern iOS Jailbreak

The rules of the game

Two layers

Phase 1: exploits as plugins

Phase 2: from a bug to a stable primitive

Phase 3: the rootless bootstrap

Phase 4: a capability server inside PID 1

Phase 5: getting into every process

Phase 6: making the system not notice

Semi-untethered, and the userspace reboot

The map

What transfers to normal software

Notes

Xcode 27: Everything Developers Need to Know

Can you even run it?

Part 1: The breaking changes (read this section)

Intel is being phased out of your build settings

The old linker is gone

On Demand Resources is deprecated

PreviewProvider is deprecated

A real Swift source break

Duplicate Clang module names now fail

C++ changes worth knowing

Part 2: Agentic coding is now a first-class citizen

The assistant moved out of the sidebar

Plan mode