DEV Community: ArshTechPro

OpenMausBot: A Local-First, Open-Source Team of AI Agents in a Chat App

ArshTechPro — Sun, 08 Nov 2026 19:02:52 +0000

If you use agent CLIs like Claude Code or Codex every day, you have probably wished you could run several of them side by side, give each one a role, and manage them like contacts in a messaging app. That is the idea behind OpenMausBot.

This post is a practical walkthrough for developers: what it is, how it is built, how to run it in a few minutes, and where you can extend it.

What is OpenMausBot?

OpenMausBot is an open-source, local-first chat app where every chat is a real AI agent. Each bot in the sidebar is backed by an agent CLI running on your machine, and each one can have its own:

personality and instructions
model
computer (a cloud Linux desktop, an isolated local VM, or your own machine)
set of connected apps

The project describes itself as an independent, open-source alternative to products like Grok Bot, Meta Muse, OpenAI dots, and Cue by Manus. It is not affiliated with xAI, Meta, OpenAI, or Manus. It is also known as MausBot and was formerly called OpenGrokBot.

Quick facts from the repository:

Item	Detail
Language	TypeScript
UI	React, Vite, Tailwind CSS
Desktop shell	Electron (macOS, Windows, Ubuntu 24.04)
License	Apache 2.0 (the `enterprise/` folder has its own source-available license)
Runtime requirement	Node 24 or newer, pnpm for source builds
Agent engines	`claude`, `codex`, and `grok` CLIs, plus custom engines

Why developers might care

There are three design choices that make this project interesting from an engineering point of view.

1. Bring your own agents. OpenMausBot does not proxy your requests through a hosted service. Bots run on the claude, codex, and grok CLIs already installed and logged in on your machine, so your existing subscriptions and logins are reused. You can point an engine at a custom CLI binary in Settings under Engines.

2. Local first. One small harness server listens on 127.0.0.1 and owns every agent process. Transcripts, keys, and events are stored in ~/.openmausbot, not in someone else's cloud.

3. Approvals instead of blind autonomy. A permission broker turns risky actions such as shell commands and file edits into inline cards in the chat. You choose Allow or Deny, for cloud and local computers alike.

Architecture in two minutes

OpenMausBot is split into two processes.

The app (React and Tailwind, port 5199 in dev) holds no transports of its own. It sends typed commands over HTTP and folds a single Server-Sent Events (SSE) stream into state.
The harness server (127.0.0.1:8799) owns every agent process. It normalizes each provider's native protocol into one canonical runtime event stream, which is logged per thread as NDJSON.

App (React + Tailwind, :5199)
   |  HTTP commands          ^  one SSE stream
   v                         |
Harness server (127.0.0.1:8799)
   |-- Driver registry --> claude CLI / codex CLI / grok CLI
   |-- Event bus (SSE)
   |-- Permission broker <-- permission requests from agents
   |-- Boat API         --> cloud computer
   |-- Composio session --> Gmail, Slack, GitHub, ...

The main layers map to folders in the repo:

Layer	Path	Responsibility
Drivers	`server/drivers/`	One per provider, over stream-JSON, JSON-RPC, or ACP. Unknown drivers degrade to "unavailable" instead of crashing the fleet.
Harness	`server/harness/`	Registry (configs to live instances) and the fan-in event bus.
API	`server/index.ts`	Bots, turns, approvals, model catalog, computer lifecycle, connectors, config over HTTP and SSE.
Voice	`server/tts/`	Text-to-speech providers; cloud keys stay on the server.
App	`src/`	The chat shell: server-backed store, one reducer, no client-side transports.
Desktop	`electron/`	Desktop shells with an embedded harness.

If you have built anything with an event-sourced UI, this will feel familiar: commands go in over HTTP, events come out over one stream, and the client is a reducer over those events.

Get it running

You have three options.

Option 1: Download a release

Released builds embed the harness server, so there is no separate server setup. Builds are available for macOS (Apple silicon and Intel), Windows x64, and Ubuntu 24.04 x64 (beta, as a .deb or AppImage). Grab them from the latest release.

Note that the Windows installer is not code-signed yet, so SmartScreen will show "unknown publisher". Use More info, then Run anyway.

Option 2: Run from the terminal with npm

This is the fastest path if you just want to try it, and it works on a server too. You need Node 24 or newer.

npm install -g openmausbot
openmausbot

You can also skip the global install:

npx openmausbot

First launch walks you through arrow-key prompts: choose AI access, sign in or paste a hidden API key, choose a model, and optionally connect a phone. The next run reuses your saved setup. Useful flags and commands:

openmausbot --no-open     # do not open the browser automatically
openmausbot setup         # reconfigure without resetting bots or conversations
npx openmausbot serve     # background service for a VPS or always-on machine

Option 3: Build from source

git clone https://github.com/milind-soni/OpenMausBot && cd OpenMausBot
pnpm install

pnpm dev:server    # harness server on 127.0.0.1:8799
pnpm dev           # app on http://127.0.0.1:5199
pnpm dev:desktop   # Electron shell; keep the two commands above running

Requirements: macOS, Windows, or Ubuntu 24.04 x64, Node 24+, pnpm, and at least one agent CLI (claude, codex, or grok) installed and logged in. Installed CLIs show up in the model picker automatically.

Useful scripts while developing:

pnpm typecheck        # app and server
pnpm test             # unit, driver, API, and desktop capability tests
pnpm build            # typecheck and production build
pnpm check:electron   # syntax-check Electron main and preload files
pnpm package:mac      # DMG and ZIP (needs Swift/Xcode tools)
pnpm package:win      # installer and ZIP
pnpm package:linux    # .deb, AppImage, verified CUA runtime

Optional credentials

Local chat works without any extra keys. Add these in App Settings (the gear icon in the sidebar footer) only when you want the matching feature:

Credential	What it enables
Composio project key	Connect Gmail, GitHub, Slack, Notion, and other apps as tools for your bots
Boat API key	Give bots an isolated remote Linux computer with a desktop and terminal
ElevenLabs or Fish Audio key	Read replies aloud and call your bots

Composio and Boat are third-party services with their own accounts and terms. Boat is paid after its trial, so a cloud computer can incur charges.

Features worth knowing about

Model picker per bot. Claude and Codex models appear side by side, and you can switch a bot's model mid-conversation.

Computers for bots. A bot can use a cloud desktop, an isolated Local VM, or your own computer. Control of your own machine is explicit opt-in and available on macOS and Ubuntu Xorg. On Ubuntu Wayland it is currently disabled behind a safety gate (tracked in issue #345).

Channels. Separate Work, Personal, and project contexts without cloning bots. Each channel has its own transcript, shared instructions, working folder, and roster.

Teams from one Markdown file. A team package uses YAML frontmatter plus a normal Markdown playbook, so the app can install it in one click while humans can still read it. Connections stay off until you approve them, routines arrive paused, and packages never carry credentials, conversations, or memory.

Triggers. Schedules and webhooks let a bot act without you. Schedules can run once, on selected weekdays, or every 5 to 1,440 minutes. Interval schedules skip a run if the previous one is still active, so slow work cannot pile up in a queue.

Voice. Spoken replies and calls through ElevenLabs, Fish Audio, Grok, built-in Mac voices, or a local Chatterbox server. Calls are macOS-only for now.

Automate it: webhooks, CLI, and MCP

This is where it gets useful for developers.

Webhook triggers

OpenMausBot starts a webhook-only receiver on 127.0.0.1:8800 by default. Set OMB_WEBHOOK_PORT to change it. Key points:

The webhook secret is shown once, when the trigger is created or rotated.
Bearer authentication is recommended so the secret stays out of URLs and access logs.
The receiver exposes only /health and secret /hooks/... endpoints. It never exposes the broader API.
The app must be running to accept a delivery. For public delivery, proxy only this receiver through a hosted relay or something like Tailscale Funnel.

Headless CLI for scripts and CI

The openmausbot command can drive a running workspace without a screen. It returns one JSON document with --json and uses exit codes a script can branch on.

openmausbot team apply team.yaml
openmausbot run "Room Lead" "Rehearse the launch of https://example.com" --export ./out

MCP server

OpenMausBot ships a stdio MCP server so external clients such as Claude Desktop and Cursor can orchestrate your bots. The tool surface is deliberately bounded: inspect bots and channels, read and search transcripts, create and configure bots, channels, and tasks, send work, wait for completion, switch models, and interrupt turns.

It does not expose approval grants, deletion, arbitrary settings, credentials, or computer lifecycle. That is a sensible boundary, because it means an outside client cannot approve its own risky actions. Setup details are in the MCP docs.

Extending it

You have three extension paths, in increasing order of effort.

Add an MCP tool server with zero code. See docs/custom-mcp-servers.md in the repo.
Add a custom engine with config only. Any ACP-speaking CLI or OpenAI-compatible endpoint plugs in through configuration. See docs/custom-engines.md. The docs also cover running bots on OpenRouter, Fireworks AI, DeepSeek, Cline, or your own OpenAI- or Anthropic-compatible provider.
Write a new driver. The driver interface in server/contracts.ts is deliberately small. Adding a provider is one file in server/drivers/ plus a one-line registration.

If you want to contribute, read CONTRIBUTING.md and LICENSING.md first. The repo uses a CLA and describes how contributions are signed off.

Security mindset

Any tool that lets an agent run shell commands and control a computer deserves care. Reasonable defaults when you try it:

Keep bots on Ask mode (approval cards) until you trust a workflow.
Start with the cloud computer or Local VM before pointing a bot at your own machine.
Connect only the apps a given bot needs.
Review a team package before importing it from someone else.
If you expose it to the internet, use a managed HTTPS endpoint with pairing, Tailscale, or your own reverse proxy, never a bare open port.

Where to go next

Repository: github.com/milind-soni/OpenMausBot
Website: openmausbot.com
Self-hosting guide: docs/self-hosting.md and docs/deploy-vps.md in the repo

If you try it, start with npx openmausbot, create one bot, and watch the approval cards while it works. That is the fastest way to see why the architecture is built the way it is.

NVKE: Run Your Own Managed GPU Kubernetes Service on Bare Metal

ArshTechPro — Sun, 08 Nov 2026 18:56:30 +0000

If you have ever tried to hand out Kubernetes clusters on GPU servers to several teams or customers, you know the problem. Provisioning machines, forming clusters, keeping them isolated, upgrading them and replacing broken nodes all turn into glue scripts very quickly.

NVIDIA Kubernetes Engine (NVKE) is an open source project that tackles this. It is a management plane you install on your own NVIDIA GPU infrastructure, and it creates and operates Kubernetes clusters on demand. Think of it as the thing that lets a platform team run something like a managed Kubernetes service, but on bare metal that you own.

Heads up: NVKE is currently a preview. APIs, configuration and behavior can change between releases, and the project does not recommend it for production workloads. This article covers what that means in practice further down.

The short version

You run the NVKE management plane. Your users run workloads on the clusters it creates.
Every workload cluster gets its own Kubernetes control plane, its own etcd and its own node pools.
Users talk to their cluster with plain kubectl and the Kubernetes API. They do not need to know NVKE exists.
Machines are provisioned through NVIDIA Infra Controller (NICo), which is the only supported infrastructure provider in the preview.
License is Apache-2.0, and the code is written in Go.

Who this is for

NVKE is aimed at platform teams: the people who own a pool of GPU servers and need to give other teams or customers their own isolated Kubernetes clusters.

If you only want to run workloads on a single GPU cluster, this is probably more than you need. If you are building an internal "Kubernetes as a service" on top of GPU hardware, keep reading.

How it is structured

An NVKE installation has two kinds of Kubernetes cluster.

1. The management cluster. This runs the NVKE management plane and the infrastructure controllers. You create it with the nvkectl command line tool, which uses a temporary seed cluster to bootstrap it. Installing the management plane services is a separate step after that.

2. Workload clusters. These are the clusters your users actually run applications on. The management plane creates and operates them through NICo, Cluster API and a node agent.

The README describes NVKE as a self-hosting factory for Kubernetes clusters, and explicitly says it is not a Kubernetes distribution and not a Cluster API flavour. A throwaway seed cluster stands up the management cluster, and the management plane then provisions and manages many isolated workload clusters.

Here is the flow in plain terms:

seed cluster (temporary)
        |
        v
management cluster  (runs the NVKE management plane)
        |
        |  requests machines through NICo
        v
workload clusters   (own control plane, etcd, node pools)
        |
        v
your users, using kubectl

What NVKE does for you

Creates independent workload clusters. You request a cluster through the NVKE API or nvkectl. NVKE provisions the machines through NICo and forms a Kubernetes cluster with its own control plane.

Manages the cluster lifecycle. You can create, scale and delete node pools, upgrade Kubernetes and replace nodes. In the preview, some of these steps are manual and have limits, so read the node pool guide before relying on them.

Establishes node identity. Nodes attest themselves through SPIFFE/SPIRE, using their TPM, before they receive join credentials. This means a machine has to prove what it is before it can join a cluster. Encryption of etcd data is available per cluster.

Connects builds to deployment. A companion project, NVIDIA Kubernetes Recipes (NVKR), builds the node images and NVKE components from pinned inputs. NVKE deploys those artifacts, while NVKR owns their build and release evidence.

Try it without GPU hardware

You do not need GPUs or an NVIDIA account to evaluate NVKE. The local quickstart creates a development management plane and a workload cluster on simulated machines.

What you need:

A Linux host or VM, amd64 or arm64
At least 6 CPUs, 12 GiB of free memory and 100 GiB of free disk
Docker, virtual TPM support and the other tools listed in the guide

Follow the local quickstart through workload cluster creation, and confirm the cluster's nodes report Ready. That is your success check.

On macOS, use the local site guide instead. It runs the evaluation inside a Colima virtual machine.

Install it on real infrastructure

For a real installation you bring your own:

Machines
Networking
Node images
Registries
Access to NICo

Start with Plan your installation. It covers the prerequisites and the order of operations: prepare nodes, bootstrap the management cluster, then install the management plane services.

The platform and version reference lists the validated combinations and pinned dependencies. Check it before you pick hardware or versions.

Build from source

If you want to read the code, hack on it or contribute, you can build everything locally.

Requirements:

Go 1.27.3, the version pinned in go.work
GNU Make 4 or later
Public Go modules reachable on the first build
Optional: Flox, which supplies the repository's development tools (and GNU Make 4 on macOS)

git clone https://github.com/dsx-ai-factory/nvke.git
cd nvke
make build

This builds the Go workspace and writes seven binaries to bin/:

Binary	Notes
`agent`	The node agent, which runs on Linux
`updater`
`controller`
`nvkectl`	The command line tool
`capd-reboot-controller`
`nvke-os-image-check`
`management-engine`

Building does not start a management plane or create a cluster. It only produces the binaries.

The repository is a multi-module Go workspace, and the workspace guide explains how the modules and outputs fit together.

What developers should know before starting

This is the section to read twice.

1. It is a preview, so expect change

APIs, configuration and behavior can change between releases. Do not plan a production rollout around the current behavior. See Preview status and known limitations.

2. API authentication is off by default

After installation, the API uses plain HTTP and authentication is turned off. You must configure API authentication and protected access before you let any callers in. Do not expose a fresh install to a network you do not control.

3. The management cluster does not look after itself

The management cluster does not upgrade, scale or replace itself. There is also no management-plane upgrade procedure and no backup and restore procedure yet. Plan for that operational gap.

4. FDE node images are for evaluation only

The FDE node images provide no data-at-rest confidentiality. Treat them as an evaluation tool, not a security feature.

5. NICo is the only infrastructure provider

For the preview, NVIDIA Infra Controller (NICo) is the sole compatible infrastructure provider. If your hardware is managed some other way, NVKE does not support it yet.

6. Some lifecycle steps are manual

Node replacement and Kubernetes upgrades have manual steps and preview limits. The node pool guide documents them.

A sensible path for a first evaluation

Read What is NVKE to understand the operator workflow.
Run the local quickstart on a Linux VM and get a workload cluster to Ready.
Read the Architecture doc to see the data flows between components.
Read the known limitations page and decide whether the preview gaps matter for your use case.
If you have GPU hardware and NICo access, move on to planning a real installation.

Where to find the docs

I want to...	Go to
Prepare nodes and bootstrap the management cluster	Bootstrap the management cluster
Install NVKE services	Deploy path README
Build node images and get release artifacts	Get NVKE artifacts from NVKR
Create and manage customer clusters	Create a workload cluster and Manage node pools
Give a customer access	Access a workload cluster
Inspect cluster health and telemetry	Observe NVKE and its clusters

The project also publishes documentation at docs.nvidia.com/nvke.

Closing up

NVKE gives platform teams a way to run a managed Kubernetes service on their own NVIDIA GPU hardware, with isolated clusters, TPM-based node attestation and a lifecycle managed through an API and nvkectl. It is early, and the preview limitations are real, especially the disabled API authentication and the missing management-plane upgrade and backup procedures.

Repository: github.com/dsx-ai-factory/nvke

LZ4 Explained for Developers - The Compression Library Built for Speed

ArshTechPro — Thu, 05 Nov 2026 12:29:12 +0000

If you have ever used ZFS, zram on Linux, Kafka, or ClickHouse, you have probably used LZ4 without knowing it. It is one of those libraries that quietly sits underneath a lot of infrastructure because it does one thing extremely well: it compresses and decompresses data fast.

This article covers what LZ4 is, when you should (and should not) use it, the things that trip developers up, and how it compares to other free and paid compression tools.

What is LZ4?

LZ4 is a lossless compression algorithm and C library written by Yann Collet (who also created Zstandard). It was first released in 2011, is licensed under the BSD 2-Clause license for the library, and has more than 12k stars on GitHub.

The design goal is simple: trade some compression ratio for raw speed.

Compression: more than 500 MB/s per core
Decompression: multiple GB/s per core, often hitting RAM bandwidth limits
Ratio: roughly 2:1 on typical mixed data at the default level

In other words, LZ4 does not make your files as small as gzip or Zstandard can, but it is so fast that compression often costs less than the I/O or network time it saves.

The numbers

These figures come from the benchmark published in the LZ4 README (lzbench, Silesia corpus, single thread, Core i7-9700K @ 4.9GHz):

Compressor	Ratio	Compression	Decompression
memcpy (no compression)	1.000	13700 MB/s	13700 MB/s
LZ4 default	2.101	780 MB/s	4970 MB/s
LZO 2.09	2.108	670 MB/s	860 MB/s
Snappy 1.1.4	2.091	565 MB/s	1950 MB/s
Zstandard 1.4.0 -1	2.883	515 MB/s	1380 MB/s
zlib deflate -1	2.730	100 MB/s	415 MB/s
LZ4 HC -9	2.721	41 MB/s	4900 MB/s
zlib deflate -6	3.099	36 MB/s	445 MB/s

Two things stand out:

LZ4 decompresses several times faster than everything else in the table.
LZ4 HC reaches a ratio close to zlib -1 while keeping the same blazing decompression speed. That matters a lot for "compress once, read many times" workloads.

Note: these numbers are from older versions of each library. Always benchmark with your own data (more on that below).

Getting started

Install

Most Linux distributions and package managers already ship it:

# Debian / Ubuntu
sudo apt install lz4 liblz4-dev

# Fedora / RHEL
sudo dnf install lz4 lz4-devel

# macOS
brew install lz4

# Windows (vcpkg)
vcpkg install lz4

Or build from source:

git clone https://github.com/lz4/lz4.git
cd lz4
make
sudo make install

Command line

The lz4 CLI feels a lot like gzip:

# Compress (creates file.txt.lz4)
lz4 file.txt

# Decompress
lz4 -d file.txt.lz4

# Higher compression (levels 3-12 use the HC compressor)
lz4 -9 big.log

# Use multiple threads (v1.10+), 0 = auto-detect cores
lz4 -T0 huge-file.bin

# Compress a directory with tar
tar -I lz4 -cf backup.tar.lz4 ./my-folder

# Benchmark levels 1 through 9 on your own file
lz4 -b1e9 sample.dat

That last command is the most useful one in this article. Run it on real data before choosing a level.

C API

The core API is small. Here is a complete round trip:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <lz4.h>

int main(void) {
    const char *src = "Hello LZ4! Hello LZ4! Hello LZ4! Hello LZ4!";
    const int src_size = (int)strlen(src) + 1;

    /* Worst-case output size for incompressible input */
    const int max_dst = LZ4_compressBound(src_size);
    char *compressed = malloc(max_dst);

    const int comp_size = LZ4_compress_default(src, compressed, src_size, max_dst);
    if (comp_size <= 0) { fprintf(stderr, "compression failed\n"); return 1; }

    /* You must know (or store) the original size yourself */
    char *restored = malloc(src_size);
    const int dec_size = LZ4_decompress_safe(compressed, restored, comp_size, src_size);
    if (dec_size < 0) { fprintf(stderr, "decompression failed\n"); return 1; }

    printf("%d -> %d bytes, restored: %s\n", src_size, comp_size, restored);
    free(compressed);
    free(restored);
    return 0;
}

Compile with:

gcc demo.c -llz4 -o demo

Python

pip install lz4

import lz4.frame

data = b"some repetitive payload " * 10_000

compressed = lz4.frame.compress(data)
restored = lz4.frame.decompress(compressed)

assert restored == data
print(f"{len(data)} -> {len(compressed)} bytes")

Other languages

LZ4 has bindings or ports in almost every ecosystem:

Language	Common package
Python	`lz4` (PyPI)
Go	`github.com/pierrec/lz4/v4`
Rust	`lz4_flex` (pure Rust) or `lz4` (bindings)
Java	`at.yawk.lz4:lz4-java` (see the security note below)
C#/.NET	`K4os.Compression.LZ4`

What developers really need to know

This is the section to read even if you skip everything else.

1. Block format vs frame format

LZ4 has two formats, and mixing them up is the most common source of bugs.

Block format (lz4.h): raw compressed bytes. No header, no checksum, no record of the original size. You must store the uncompressed size yourself and pass it at decompression time.
Frame format (lz4frame.h): a self-describing container with a magic number, optional content size, optional xxHash checksums, and support for streaming arbitrarily large data.

Rule of thumb: use the frame format unless you are building your own container and know exactly why you need raw blocks. The frame format is what the CLI produces, and it is what other tools and languages expect for interoperability.

2. Always use the safe decompressor

Use LZ4_decompress_safe() (or the frame API). It checks bounds and will not write past your buffer even if the input is corrupted or malicious.

Avoid LZ4_decompress_fast(). It is deprecated, and it trusts the input, which makes it unsafe for anything that comes from a network, a user, or a disk you do not fully control.

3. Compression level does not slow down decompression

LZ4 offers:

Acceleration (LZ4_compress_fast with a factor > 1): even faster compression, lower ratio.
Default (level 1): the classic fast mode.
Level 2: new in v1.10, a middle ground between fast and HC.
HC levels 3 to 12: much slower compression, better ratio.

All of these decompress at essentially the same speed. So for assets, packages, or anything written once and read many times, use a high HC level at build time and enjoy fast reads forever.

4. Small data needs a dictionary

Compressing a 300-byte JSON message on its own gives poor results because there is no history to find repeats in. LZ4 supports dictionary compression, which pre-loads shared context. Only the last 64 KB of a dictionary is used.

You can train a dictionary with Zstandard's builder and use it with LZ4:

zstd --train samples/*.json -o messages.dict
lz4 -D messages.dict message.json

Dictionary support was fully stabilized in v1.10.

5. Multithreading arrived in v1.10

Version 1.10.0 (July 2024, "Multicores edition") added multithreaded compression to the CLI, which gives large speedups on big files with many cores. Decompression is still effectively single-threaded, but it is already fast enough to saturate most NVMe drives.

If your distro ships an older 1.9.x build, you will not get -T.

6. Do not compress data that is already compressed

JPEGs, MP4s, ZIPs, and encrypted data will not shrink. LZ4 is fast enough that this is rarely a disaster, but you still burn CPU for nothing. Many systems check the ratio after compressing and store the raw data if the gain is too small.

7. Check your bindings for security updates

The C library is heavily fuzzed (it is part of OSS-Fuzz), but bindings are separate projects with their own bugs. A notable example: the original org.lz4:lz4-java is no longer maintained, and the community fork moved to the at.yawk.lz4:lz4-java Maven coordinates, which includes fixes for CVE-2025-12183 and CVE-2025-66566. If you are on the JVM, check which artifact your dependency tree actually pulls in (Kafka clients and many other libraries depend on it transitively).

Where LZ4 is used in the real world

Linux kernel: zram, zswap, SquashFS, and kernel image compression
Filesystems: ZFS and OpenZFS use LZ4 as the go-to on-the-fly compression
Databases and analytics: ClickHouse (default codec), plus many column stores
Messaging: Kafka and Pulsar support LZ4 for message batches
Game engines and asset pipelines: fast asset loading

The common thread: places where latency and throughput matter more than squeezing out the last few percent of disk space.

Comparison with other tools

Free and open source

Tool	License	Speed	Ratio	Best for
LZ4	BSD-2	Fastest decompression, very fast compression	Low to medium (HC)	Real-time, in-memory, storage engines, read-heavy data
Zstandard (zstd)	BSD / GPLv2	Fast, tunable from very fast to very slow	Medium to very high	The best general-purpose default today
Snappy (Google)	BSD-3	Fast	Low (similar to LZ4)	Existing Google/Hadoop/Parquet ecosystems
gzip / zlib (deflate)	zlib	Slow compression, slow decompression	Medium	Maximum compatibility (HTTP, archives, everywhere)
Brotli (Google)	MIT	Slow at high levels, decent decompression	High, especially for text	Static web assets served over HTTP
xz / LZMA	Public domain / LGPL	Very slow compression	Very high	Distribution packages, long-term archives
LZO	GPL	Fast	Low	Legacy systems

How to read this:

LZ4 vs Zstandard: Zstandard (same author) is the better all-rounder. At its fastest levels it is competitive with LZ4 on compression speed and gets a noticeably better ratio, but LZ4 still decompresses roughly 2-4x faster. Pick LZ4 when decompression speed or CPU budget is the bottleneck; pick zstd when storage or bandwidth costs dominate.
LZ4 vs Snappy: they target the same niche with similar ratios. In most benchmarks LZ4 is faster on both compression and decompression. Snappy is mainly worth choosing when your ecosystem already standardizes on it.
LZ4 vs gzip: gzip compresses better but is many times slower in both directions. Use gzip when you need universal compatibility, not speed.
LZ4 vs Brotli / xz: different goals. Those tools aim for small output and accept slow compression; LZ4 aims for speed.

Paid and commercial options

There are few commercial libraries in this space because the open source options are so strong, but a few are worth knowing:

Tool	Model	What it offers	When it makes sense
Oodle (Epic Games Tools, formerly RAD Game Tools)	Proprietary, commercially licensed; bundled with Unreal Engine	Codecs such as Kraken, Mermaid, Selkie and Leviathan, tuned for very fast decompression with better ratios than LZ4 at similar speeds; also network packet compression	Game studios shipping large assets, especially on consoles
Intel QuickAssist Technology (QAT)	Hardware accelerator, paid via supported CPUs or add-in cards	Offloads compression (including deflate and LZ4) from the CPU	High-throughput servers where CPU cycles are expensive
Commercial archivers (WinZip, WinRAR, PKZIP)	Paid end-user software	GUI tools, encryption, archive management	Desktop users, not libraries you embed in an application

Honest take: for the vast majority of developers there is no compelling reason to pay for a compression library. The paid options shine in narrow cases, mainly game asset delivery (Oodle) and hardware offload at data center scale (QAT). For everything else, LZ4 and Zstandard cover the field.

Wrapping up

LZ4 is not trying to win the compression ratio contest. It is trying to make compression so cheap that you can turn it on almost everywhere, and it succeeds.

T3 Code: A Free, Open-Source Control Panel for Claude Code, Codex and Other Coding Agents

ArshTechPro — Tue, 03 Nov 2026 07:19:51 +0000

If you use AI coding agents every day, you have probably hit this wall: three terminals running Claude Code, one running Codex, all poking at the same repo, and no single place to see what each one is doing or what it changed.

T3 Code is an attempt to fix that. It comes from Theo Browne's team (the people behind the T3 Stack and T3 Chat), it is MIT licensed, and it costs nothing. In this post I will cover what it actually is, how to get it running, what you need to watch out for, and how it stacks up against the free and paid alternatives.

TL;DR

T3 Code is not a coding agent and has no model of its own. It is a GUI and control layer that drives the agent CLIs you already have installed.
It works with Claude Code, Codex, Cursor, Grok Build, OpenCode and Google Antigravity, using your existing subscriptions.
You get a desktop app (macOS, Windows, Linux), a web app, and iOS/Android apps for checking on agents remotely.
Each task is a thread that can run on its own Git branch or worktree, with an inline diff and a one-click PR flow.
It is very early software (v0.0.x). New threads default to Full access, which means no approval prompts. Change that first.

What T3 Code actually is

The project describes itself as an "agent harness control surface". In plain terms:

 You (desktop / web / phone)
          |
          v
   T3 Code server  <-- owns processes, terminals, Git, project files
          |
   +------+-------+-----------+----------+
   |      |       |           |          |
 Claude  Codex  Cursor CLI  OpenCode   Grok / Antigravity
  Code    CLI

A server process on your machine owns everything that runs: the agent processes, terminals, Git operations and project files. The desktop, web and mobile apps are thin clients that connect to that server. The desktop app bundles its own server, so on a single machine you do not have to think about this split at all.

Because T3 Code drives the official CLIs, it signs in through each CLI's own login. It does not resell API keys or add its own usage quota. Whatever you pay Anthropic, OpenAI or Cursor today is what you keep paying. T3 Code itself is $0.

Why developers are paying attention

One window for many agents. Run Claude Code and Codex side by side, compare their approaches on the same problem, and switch models in the middle of a thread.

Branch per thread. Each thread can work on its own branch or Git worktree. A worktree is a second checkout of the same repo on a different branch, so two agents can edit files at the same time without stepping on each other.

Diff review and PRs in the same place. You see the diff as the agent works, then commit, push and open a pull request from the app. The PR gets a generated title and body.

Remote control. Leave the agents running on your workstation and check on them from your phone or laptop.

An MCP server. Other agents (Claude Code in a terminal, Codex, ChatGPT) can connect to T3 Code over MCP to read threads and start new ones. That makes a "coordinator agent" pattern possible without writing your own plumbing.

Getting started

Step 1: Install and log in to at least one agent CLI

T3 Code cannot do anything without an agent behind it. Set up at least one of these first:

# Claude Code
claude auth login

# Codex
codex login

# Cursor CLI
agent login

# OpenCode
opencode auth login

# Grok Build
grok login

Google Antigravity is the exception: you enable it inside T3 Code's settings and sign in with Google. No CLI needed.

Step 2: Install T3 Code

Pick whichever fits your workflow.

Try it once without installing anything permanent:

npx t3@latest

Install the CLI (server plus local web app):

# macOS / Linux
curl -fsSL https://t3.codes/install.sh | sh

# Windows (PowerShell)
irm https://t3.codes/install.ps1 | iex

Then:

t3                   # start the server and open the local web app
t3 service install   # keep it running in the background
t3 update            # move to a newer release
t3 --help            # full reference

Install the desktop app:

# macOS
brew install --cask t3-code

# Windows
winget install T3Tools.T3Code
# or
scoop install extras/t3code

# Debian / Ubuntu (download the .deb from GitHub Releases first)
sudo apt install ./T3-Code-*.deb

# Arch Linux
yay -S t3code-bin

Step 3: Change the default permission mode

Do this before your first real task. See the next section for why.

Step 4: Open a project and start a thread

Add your repo as a project, start a thread, choose the agent and whether it should run in a new worktree, and give it a task. When it finishes, review the diff and decide whether to open a PR or throw the branch away.

Permission modes: the setting that matters most

Every thread has a permission mode that decides how much the agent can do without asking you:

Mode	What it does	When to use it
Supervised	Asks before commands and file changes. Work outside the workspace is restricted.	Important repos, unfamiliar tasks
Auto-accept edits	File edits go through, commands still need approval	Refactors where you mainly care about shell commands
Auto	Routine actions run, risky ones still ask	Day-to-day work with providers that support it
Full access	No prompts at all for commands or edits	Throwaway worktrees and sandboxes only

Two things to know:

Full access is the default for new threads. The agent can run any command and edit any file without asking. For a tool designed to run several agents at once, that is a risky default. Change it in Settings to Supervised or Auto.
Auto mode depends on the provider. Codex hands routine approvals to an AI reviewer and Claude uses its own auto permission mode. Providers without an equivalent, such as OpenCode, fall back to asking every time, like Supervised.

The mode is set per thread, so changing it in one thread does not affect others.

Remote access in practice

The machine running T3 Code does the work. Your phone or laptop is just a remote. That means the host has to stay awake and reachable.

You have three main ways to connect:

LAN or Tailscale (traffic stays on your network):

t3 serve --host <your-lan-or-tailnet-ip>
t3 pair            # prints a QR code and a one-time pairing link

For HTTPS over Tailscale:

t3 serve --tailscale-serve

T3 Connect (no router or VPN setup):

t3 connect

This needs a T3 account and routes the connection through T3's relay. Convenient, but be aware of that trade-off if your company has rules about where code-related traffic goes.

SSH from the desktop app: add an SSH host in Settings, and T3 Code starts a server there and forwards the port for you. Projects, credentials and agent work stay on the remote machine. The remote host must be Linux or an Apple Silicon Mac.

Treat pairing links and codes like passwords. Keep them out of screenshots, logs and bug reports.

Letting other agents drive T3 Code (MCP)

Every T3 Code environment exposes an MCP endpoint at https://<environment-address>/mcp. For example, to connect Claude Code running in a terminal:

claude mcp add --transport http t3 https://<environment-address>/mcp
claude mcp login t3

For Codex:

codex mcp add t3 --url https://<environment-address>/mcp
codex mcp login t3

A new agent gets Read only access by default. You can raise it to Supervised or higher so it can start, message and stop threads. The address must be HTTPS (or localhost on the same machine), and sign-ins expire after 30 days.

What to know before you adopt it

It is early. The README says to expect bugs, and stable releases are still on v0.0.x with nightly builds shipping several times a day. Stick to the stable channel for real work.

Contributions are mostly closed. The team says small fixes may be considered, but big features will not be accepted for now. Feature ideas go to GitHub Discussions. If you need something specific, the MIT license lets you fork.

Docs live in the repo. There is no docs site yet. Everything is under docs/, and it is genuinely useful.

Your existing agent config still applies. Because T3 Code runs the real CLIs, things like your CLAUDE.md, AGENTS.md, hooks and MCP servers configured for each CLI should keep working.

The PR flow assumes a Git and GitHub-style workflow. If your work is not branch-and-PR shaped, you will get less out of it.

Costs still exist, just not here. Running four agents in parallel burns through your Claude or ChatGPT plan limits four times faster.

How T3 Code compares to other tools

There are two broad groups to compare against: orchestrators (tools like T3 Code that sit on top of agents) and AI editors and first-party agent apps (tools that come with their own model access).

Orchestrators and agent managers

Tool	Price	License	Platforms	Agents supported	Interface	Mobile / remote
T3 Code	Free	MIT	macOS, Windows, Linux, web	Claude Code, Codex, Cursor, OpenCode, Grok Build, Antigravity	Desktop + web GUI	Yes: iOS, Android, web
Conductor	Free local plan; paid Pro for cloud workspaces	Closed source	macOS only	Claude Code, Codex, Cursor, OpenCode	Native Mac app	Cloud workspaces on paid plan
Claude Squad	Free	AGPL-3.0	macOS, Linux (Windows via WSL)	Claude Code, Codex, Gemini, Aider, others	Terminal UI (tmux)	Via SSH
Vibe Kanban	Free	Apache-2.0	Cross-platform (runs via npx)	10+ including Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, OpenCode	Kanban board in browser	Self-host and tunnel

Quick notes on each:

Conductor is the closest competitor and the most polished Mac experience. It uses Git worktrees per workspace, like T3 Code. Its free plan covers local workspaces; reviews list Pro at around $50/month for cloud workspaces that keep running when your laptop is closed. If you are not on a Mac, it is not an option.
Claude Squad is a lightweight Go binary built on tmux and worktrees. It is great if you live in the terminal and do not want a GUI at all. No phone app.
Vibe Kanban frames agent work as kanban tickets, which suits people who like to plan a backlog first. Its original company, bloop, shut down in 2026 and the project continues as a community-maintained open-source tool, which is worth weighing for long-term support.

AI editors and first-party agent apps

Tool	Price	What you get	Difference from T3 Code
Cursor	Free Hobby tier; Pro $20/mo, Pro+ $60/mo, Ultra $200/mo, Teams $40/user/mo	Full AI code editor with bundled model usage	It is an editor with its own billing. T3 Code is a control layer and can even drive the Cursor CLI.
Codex app	Included with ChatGPT plans	OpenAI's own app for Codex	Codex only
Claude Code / Claude desktop	Included with Claude plans	Anthropic's own agent, with built-in worktree support	Claude only

The key difference: Cursor, Codex and Claude Code are where the model access and billing live. T3 Code does not replace them. It sits on top and lets you run several of them from one place.

Which one should you pick?

You use more than one agent and want a GUI on any OS: T3 Code.
You are on a Mac, want the most polished experience, and are fine with closed source: Conductor.
You prefer staying entirely in the terminal: Claude Squad.
You want to plan agent work as tickets on a board: Vibe Kanban.
You only use one agent and are happy with it: Its own app or CLI is probably enough. Claude Code and Codex both support parallel work on their own.
You want an editor with AI built in, not an agent manager: Cursor.

Wrapping up

T3 Code is not trying to be another AI model or another editor. It is a free, open control layer for the agents you already pay for, with worktrees, diffs, PRs and a phone app in one place. It is rough around the edges and changing fast, so treat it as early-adopter software and lock down the permission defaults. But if you already juggle several coding agents, it is one of the more interesting open-source projects to try right now.

Links:

GitHub: pingdotgg/t3code

Pricing and feature details were checked in early November 2026. These tools change quickly, so verify on each project's site before making a decision.

Maestro Deep Dive: Testing a SwiftUI App End to End

ArshTechPro — Tue, 27 Oct 2026 19:13:41 +0000

In Part 1 we covered what Maestro is, how it works and how it compares to Appium, XCUITest, Detox and the paid device clouds. Now it is time to write real tests.

In this article we will:

Build a small SwiftUI app with a login screen and a to-do list.
Make it testable with accessibility identifiers.
Write a Maestro suite with reusable sub-flows, environment variables, conditional logic, JavaScript and tags.
Run it locally, generate reports and debug failures.
Look at how the same test would look in XCUITest, and where AI agents fit in.

Everything here uses the free, open-source Maestro CLI. The full app is about 120 lines of Swift, so you can copy it into a new Xcode project and follow along.

Prerequisites

macOS with Xcode 16 or newer and an iOS 17+ Simulator runtime
Java 17 or newer (java -version)
Maestro CLI:

curl -fsSL "https://get.maestro.mobile.dev" | bash
maestro --version

This article was written against Maestro CLI 2.10.0.

Part A: The sample app

Create a new Xcode project:

Template: iOS > App
Product name: TodoDemo
Organization identifier: com.example
Interface: SwiftUI
Minimum deployment: iOS 17

That gives the bundle ID com.example.TodoDemo, which Maestro uses as the appId.

The app has two screens:

Login: email, password, a "Log In" button and an error message for wrong credentials. The valid credentials are demo@example.com / password123.
My Tasks: add tasks, tap to complete them, swipe to delete, see a progress label, and log out. After login it asks for notification permission, which gives us a system dialog to deal with.

`TodoDemoApp.swift`

import SwiftUI

@main
struct TodoDemoApp: App {
    @AppStorage("isLoggedIn") private var isLoggedIn = false

    var body: some Scene {
        WindowGroup {
            if isLoggedIn {
                TodoListView()
            } else {
                LoginView()
            }
        }
    }
}

The login state is stored in UserDefaults through @AppStorage. That matters for testing: it survives an app restart, so we will need to clear app state between tests.

`LoginView.swift`

import SwiftUI

struct LoginView: View {
    @AppStorage("isLoggedIn") private var isLoggedIn = false
    @State private var email = ""
    @State private var password = ""
    @State private var errorMessage: String?

    var body: some View {
        NavigationStack {
            Form {
                Section {
                    TextField("Email", text: $email)
                        .keyboardType(.emailAddress)
                        .textInputAutocapitalization(.never)
                        .autocorrectionDisabled()
                        .accessibilityIdentifier("emailField")

                    SecureField("Password", text: $password)
                        .accessibilityIdentifier("passwordField")
                }

                if let errorMessage {
                    Text(errorMessage)
                        .foregroundStyle(.red)
                        .accessibilityIdentifier("loginError")
                }

                Button("Log In", action: logIn)
                    .accessibilityIdentifier("loginButton")
                    .disabled(email.isEmpty || password.isEmpty)
            }
            .navigationTitle("Welcome")
        }
    }

    private func logIn() {
        // Demo only. A real app would call an auth service here.
        if email.lowercased() == "demo@example.com" && password == "password123" {
            errorMessage = nil
            isLoggedIn = true
        } else {
            errorMessage = "Invalid email or password"
        }
    }
}

`TodoListView.swift`

import SwiftUI
import UserNotifications

struct TodoItem: Identifiable {
    let id = UUID()
    var title: String
    var isDone = false
}

struct TodoListView: View {
    @AppStorage("isLoggedIn") private var isLoggedIn = false
    @State private var items: [TodoItem] = []
    @State private var newTitle = ""

    private var doneCount: Int { items.filter(\.isDone).count }

    var body: some View {
        NavigationStack {
            VStack(spacing: 12) {
                HStack {
                    TextField("New task", text: $newTitle)
                        .textFieldStyle(.roundedBorder)
                        .onSubmit(addItem)
                        .accessibilityIdentifier("newTaskField")

                    Button("Add", action: addItem)
                        .accessibilityIdentifier("addTaskButton")
                        .disabled(newTitle.trimmingCharacters(in: .whitespaces).isEmpty)
                }
                .padding(.horizontal)

                if items.isEmpty {
                    ContentUnavailableView(
                        "No tasks yet",
                        systemImage: "checklist",
                        description: Text("Add your first task above.")
                    )
                } else {
                    List {
                        ForEach($items) { $item in
                            Button {
                                item.isDone.toggle()
                            } label: {
                                HStack {
                                    Image(systemName: item.isDone ? "checkmark.circle.fill" : "circle")
                                    Text(item.title)
                                        .strikethrough(item.isDone)
                                }
                            }
                        }
                        .onDelete { items.remove(atOffsets: $0) }
                    }

                    Text("\(doneCount) of \(items.count) done")
                        .font(.footnote)
                        .foregroundStyle(.secondary)
                        .accessibilityIdentifier("progressLabel")
                }
            }
            .navigationTitle("My Tasks")
            .toolbar {
                ToolbarItem(placement: .topBarTrailing) {
                    Button("Log Out") { isLoggedIn = false }
                        .accessibilityIdentifier("logoutButton")
                }
            }
            .task {
                _ = try? await UNUserNotificationCenter.current()
                    .requestAuthorization(options: [.alert, .sound])
            }
        }
    }

    private func addItem() {
        let title = newTitle.trimmingCharacters(in: .whitespaces)
        guard !title.isEmpty else { return }
        items.append(TodoItem(title: title))
        newTitle = ""
    }
}

Run it once in the Simulator from Xcode to make sure it works.

Why the accessibility identifiers?

Maestro can find elements by visible text (tapOn: "Log In"), and that is often fine. But text changes: a designer renames "Log In" to "Sign In", or you test in German. Identifiers do not change with copy or locale.

A practical rule:

Static controls (buttons, fields, labels you assert on): give them an accessibilityIdentifier and target them with id.
Dynamic content (task titles, user names, server data): target by text, because the text is the thing you are verifying.

You can see exactly what Maestro sees with:

maestro hierarchy

or by opening the Maestro Studio desktop app and clicking on elements in the live device view.

Part B: Build and install for the Simulator

Maestro tests the Simulator build of your app (.app). You can install it by running from Xcode, or from the command line, which is what CI will do:

# Boot a simulator (the device name depends on your installed runtimes)
xcrun simctl boot "iPhone 16" || true

# Build for the simulator
xcodebuild \
  -project TodoDemo.xcodeproj \
  -scheme TodoDemo \
  -configuration Debug \
  -sdk iphonesimulator \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -derivedDataPath build \
  build

# Install the .app on the booted simulator
xcrun simctl install booted build/Build/Products/Debug-iphonesimulator/TodoDemo.app

Part C: The test suite

Here is the structure we are going to build:

.maestro/
├── config.yaml
├── subflows/
│   ├── login.yaml
│   └── dismiss_permission_dialog.yaml
└── flows/
    ├── 01_login_invalid.yaml
    ├── 02_login_success.yaml
    ├── 03_add_and_complete_tasks.yaml
    ├── 04_delete_task.yaml
    └── 05_session_and_logout.yaml

flows/ contains the tests. subflows/ contains reusable building blocks that are never run on their own.

`config.yaml`: the workspace configuration

# Only files matching these patterns are treated as tests.
# Sub-flows live outside flows/, so they are not run directly.
flows:
  - "flows/*"

When you run maestro test .maestro/, Maestro reads this file to decide which flows belong to the suite.

Sub-flow 1: `login.yaml`

appId: com.example.TodoDemo
---
- tapOn:
    id: "emailField"
- inputText: ${EMAIL || 'demo@example.com'}
- tapOn:
    id: "passwordField"
- inputText: ${PASSWORD || 'password123'}
- tapOn:
    id: "loginButton"

Two things to notice:

Everything inside ${...} is JavaScript. EMAIL || 'demo@example.com' means "use the EMAIL variable if someone passed one, otherwise fall back to the default". That lets the same sub-flow handle valid and invalid logins.
There are no waits. After tapOn: { id: "emailField" }, Maestro waits for the screen to settle before typing.

Sub-flow 2: `dismiss_permission_dialog.yaml`

appId: com.example.TodoDemo
---
- runFlow:
    when:
      visible: "Allow"
    commands:
      - tapOn: "Allow"

This is a conditional flow. If the system notification dialog is on screen, tap "Allow". If it is not, do nothing and continue. Because Maestro drives the whole device rather than just your app process, it can tap system alerts that in-process frameworks cannot reach directly.

We will mostly avoid the dialog entirely by pre-granting permissions in launchApp, but this sub-flow is a safety net for cases where you cannot.

Test 1: `01_login_invalid.yaml`

appId: com.example.TodoDemo
name: Login fails with wrong credentials
tags:
  - auth
  - regression
---
- launchApp:
    clearState: true
- assertVisible: "Welcome"
- runFlow:
    file: ../subflows/login.yaml
    env:
      EMAIL: "wrong@example.com"
      PASSWORD: "not-the-password"
- assertVisible:
    id: "loginError"
    text: "Invalid email or password"
- assertNotVisible: "My Tasks"

clearState: true wipes the app's data before launching, so every test starts logged out. This is the single most important habit for a reliable suite: never let one test depend on what a previous test left behind.
runFlow with env overrides the variables for that sub-flow only.
The selector { id: "loginError", text: "..." } matches an element that has that identifier and that text.

Test 2: `02_login_success.yaml`

appId: com.example.TodoDemo
name: Login succeeds with valid credentials
tags:
  - smoke
  - auth
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml
- assertVisible: "My Tasks"
- assertVisible: "No tasks yet"
- takeScreenshot: after_login

permissions: { notifications: allow } grants the permission before the app starts, so the dialog should never appear. takeScreenshot saves a PNG, which is useful for reviewing UI in CI artifacts.

Test 3: `03_add_and_complete_tasks.yaml`

appId: com.example.TodoDemo
name: Add tasks and mark one as done
tags:
  - smoke
  - tasks
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml

- tapOn:
    id: "newTaskField"
- inputText: "Buy milk"
- tapOn:
    id: "addTaskButton"

- tapOn:
    id: "newTaskField"
- inputText: "Write Maestro article"
- tapOn:
    id: "addTaskButton"

- assertVisible: "Buy milk"
- assertVisible: "Write Maestro article"
- assertVisible:
    id: "progressLabel"
    text: "0 of 2 done"

- tapOn: "Buy milk"
- assertVisible:
    id: "progressLabel"
    text: "1 of 2 done"

Notice how the test reads almost exactly like a manual QA script. That readability is the main reason teams adopt Maestro.

Test 4: `04_delete_task.yaml` (loops, JavaScript and swipes)

appId: com.example.TodoDemo
name: Delete a task with swipe
tags:
  - tasks
  - regression
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml

# Create "Task 1", "Task 2" and "Task 3" using a loop and a JS counter
- evalScript: ${output.counter = 0}
- repeat:
    times: 3
    commands:
      - evalScript: ${output.counter = output.counter + 1}
      - tapOn:
          id: "newTaskField"
      - inputText: "Task ${output.counter}"
      - tapOn:
          id: "addTaskButton"

- assertVisible: "Task 3"

# Swipe left on the row to reveal the system Delete action
- swipe:
    from:
      text: "Task 2"
    direction: LEFT
- tapOn: "Delete"

- assertNotVisible: "Task 2"
- assertVisible: "Task 1"
- assertVisible: "Task 3"
- assertVisible:
    id: "progressLabel"
    text: "0 of 2 done"

output is a JavaScript object Maestro provides for storing values across steps.
repeat runs a block a fixed number of times (it also supports a while condition).
swipe with from starts the gesture on a specific element, which is how you trigger SwiftUI's .onDelete.

Use loops and scripts sparingly. If a flow starts to look like a program, consider seeding data through a test backend or launch arguments instead.

Test 5: `05_session_and_logout.yaml`

appId: com.example.TodoDemo
name: Session persists across restarts until logout
tags:
  - auth
  - regression
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow
- runFlow: ../subflows/login.yaml
- runFlow: ../subflows/dismiss_permission_dialog.yaml
- assertVisible: "My Tasks"

# Restart without clearing state: the user should still be logged in
- stopApp
- launchApp
- assertVisible: "My Tasks"

# Log out and confirm we are back on the login screen
- tapOn:
    id: "logoutButton"
- assertVisible: "Welcome"
- assertVisible:
    id: "loginButton"

This test checks behavior that crosses an app restart, something that is awkward to do in many in-process frameworks.

Part D: Running the suite

Make sure the Simulator is booted and the app is installed, then from the project root:

# Run the whole suite
maestro test .maestro/

# Run a single flow
maestro test .maestro/flows/02_login_success.yaml

# Run only smoke tests
maestro test --include-tags smoke .maestro/

# Exclude slow tests
maestro test --exclude-tags regression .maestro/

# Pass variables from the command line
maestro test -e EMAIL=qa@example.com -e PASSWORD=secret .maestro/flows/02_login_success.yaml

Faster authoring with continuous mode

While writing a flow, use continuous mode. Maestro reruns the flow every time you save the file:

maestro test -c .maestro/flows/03_add_and_complete_tasks.yaml

Combined with Maestro Studio for finding selectors, this gives you a feedback loop of a few seconds.

Validate syntax without a device

maestro check-syntax .maestro/flows/04_delete_task.yaml

Useful as a pre-commit hook or a quick CI step.

Reports and artifacts

# JUnit XML, understood by most CI systems
maestro test .maestro/ --format junit --output build/maestro-report.xml

# HTML report for humans
maestro test .maestro/ --format html --output build/maestro-report.html

# Put screenshots, logs and per-flow artifacts in a known folder
maestro test .maestro/ --test-output-dir build/maestro-artifacts

When a flow fails, the artifacts include a screenshot before each step, the view hierarchy at the moment of failure, device logs and crash reports. Start debugging there, not in the terminal output.

Running on several simulators in parallel

If you have more than one simulator booted, you can split the suite across them:

maestro test --shard-split 2 .maestro/

--shard-split divides the flows between devices. --shard-all runs every flow on every device, which is useful for testing several iOS versions or screen sizes at once.

Part E: The same test in XCUITest

To make the comparison from Part 1 concrete, here is roughly what Test 2 (successful login) looks like in XCUITest:

import XCTest

final class LoginUITests: XCTestCase {
    override func setUp() {
        continueAfterFailure = false
    }

    func testLoginSucceeds() {
        let app = XCUIApplication()
        app.launchArguments = ["-isLoggedIn", "NO"]   // reset @AppStorage
        app.launch()

        let email = app.textFields["emailField"]
        XCTAssertTrue(email.waitForExistence(timeout: 5))
        email.tap()
        email.typeText("demo@example.com")

        let password = app.secureTextFields["passwordField"]
        password.tap()
        password.typeText("password123")

        app.buttons["loginButton"].tap()

        // System alerts live in SpringBoard, outside the app under test
        let springboard = XCUIApplication(bundleIdentifier: "com.apple.springboard")
        let allow = springboard.buttons["Allow"]
        if allow.waitForExistence(timeout: 3) {
            allow.tap()
        }

        XCTAssertTrue(app.navigationBars["My Tasks"].waitForExistence(timeout: 5))
        XCTAssertTrue(app.staticTexts["No tasks yet"].exists)
    }
}

XCUITest is not bad. It is fast, it is Apple's own tooling and it runs on physical devices. But compare the two:

	Maestro	XCUITest
Lines for this test	About 10 (plus a reusable sub-flow)	About 30
Explicit waits	None	`waitForExistence` on most steps
System dialogs	`tapOn: "Allow"`	Separate SpringBoard app handle
Resetting state	`clearState: true`	Launch arguments or custom reset code
Rebuild after change	No	Yes, test target recompiles
Reusable on Android	Often, with the same flow	No, rewrite in Espresso
Physical iPhones	Not officially, see Part 1	Yes

Many teams use both: XCUITest or unit tests for detailed component behavior, Maestro for end-to-end user journeys.

Part F: Writing flows with an AI coding agent

Maestro ships an MCP server inside the CLI. It lets an AI coding agent see the simulator, inspect the view hierarchy, run flows and read the results. To connect it, add this to your agent's MCP configuration:

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

Most agents also have a one-line command. For example, with the Codex CLI:

codex mcp add maestro -- maestro mcp

and with the Gemini CLI:

gemini mcp add maestro maestro mcp

Then you can ask something like: "Write a Maestro flow that logs in to TodoDemo, adds three tasks, completes the second one and checks the progress label. Run it and fix it until it passes."

Troubleshooting checklist

Symptom	What to check
`Element not found`	Run `maestro hierarchy` or open Studio. Is the identifier set on the element you think it is? Is the text an exact match?
Tap lands on the keyboard	The keyboard may cover the target. Add `- hideKeyboard` or scroll first with `scrollUntilVisible`.
Test passes locally, fails in CI	CI machines are slower. Use `extendedWaitUntil` with a longer timeout for slow screens, and increase `MAESTRO_DRIVER_STARTUP_TIMEOUT`.
Tests affect each other	Use `launchApp: { clearState: true }` at the start of every flow.
Long animations break assertions	Add `- waitForAnimationToEnd` before the assertion.
`.ipa` will not install	Maestro needs a Simulator build (`.app`) built with `-sdk iphonesimulator`.
Flags stopped working after an upgrade	Check the changelog. `--ios-version` is being replaced by `--device-os`.

Example of a longer explicit wait for a slow screen:

- extendedWaitUntil:
    visible:
      id: "progressLabel"
    timeout: 15000   # milliseconds

Best practices summary

One user journey per flow. Short flows fail for one clear reason.
Reset state at the start of every flow with clearState: true.
Use identifiers for controls, text for content.
Extract repeated steps into sub-flows (login, onboarding, navigation).
Keep logic out of YAML where possible. Seed data through APIs or launch arguments.
Tag your flows (smoke, regression, feature names) and run smoke tests on every PR, the full suite nightly.
Pin the Maestro version in CI and upgrade on purpose.
Always keep artifacts from failed runs.

Ending

With about 120 lines of Swift and five short YAML files, we have a test suite that covers login, error handling, adding, completing and deleting tasks, session persistence, logout and system permission dialogs. It runs locally in under a couple of minutes, runs in GitHub Actions without changes, and can move to a device cloud with one command.

That is Maestro's real value: the distance between "we should test this" and "it is tested in CI" is very short.

Resources

GitHub: mobile-dev-inc/maestro

Maestro: Mobile UI Testing Without the Pain - Introduction

ArshTechPro — Tue, 27 Oct 2026 19:10:57 +0000

If you have ever written mobile end-to-end tests, you probably know the routine. You set up Appium, fight with drivers and capabilities, write a test that passes locally, and then watch it fail in CI because an animation took 200ms longer than expected. You add a sleep(2). Then another. Six months later nobody trusts the suite.

Maestro is an open-source framework built to make that experience less painful. This article covers what it is, how it works, what you should know before adopting it, and how it stacks up against the other free and paid options.

This is Part 1 of a two-part series. Part 2 is a hands-on deep dive with a small SwiftUI app and a complete test suite.

What is Maestro?

Maestro is a UI and end-to-end testing framework for Android, iOS and web apps. Instead of writing tests in Java, Kotlin, Swift or JavaScript, you describe user journeys (called Flows) in YAML:

appId: com.example.myapp
---
- launchApp
- tapOn: "Sign in"
- tapOn: "Email"
- inputText: "jane@example.com"
- tapOn: "Password"
- inputText: "hunter2"
- tapOn: "Continue"
- assertVisible: "Welcome, Jane"

That is a complete, runnable test. No page objects, no driver setup code, no explicit waits.

How Maestro works (and why it matters)

Maestro is a black-box tool. It does not link into your app, does not need an SDK, and does not need your source code. It drives the device the way a user would, and it reads the screen through the platform's accessibility layer and view hierarchy.

On iOS, Maestro installs a small XCTest-based driver on the simulator. On Android, it installs a driver app that talks to UIAutomator. The CLI sends commands to the driver, reads back the UI hierarchy, and decides what to do next.

Three design choices make it feel different from older tools:

1. Automatic waiting. After each command, Maestro waits for the screen to settle before moving on. If you tapOn: "Continue" and the button is not visible yet, it keeps looking for a while before failing. In practice this removes most of the sleep() calls you would write elsewhere.

2. Flakiness tolerance. Mobile UIs are noisy: taps sometimes do not register, elements shift during animations, keyboards appear and disappear. Maestro's commands are designed to retry and re-check rather than fail on the first miss.

3. Interpreted, not compiled. Flows are read at runtime. Change a YAML file, rerun, and see the result in seconds. There is no test target to rebuild.

Because it operates "at arm's length", Maestro can also do things in-process tools cannot: tap system permission dialogs, open Safari or Settings, and come back to your app in the same flow.

The ecosystem: CLI, Studio, MCP and Cloud

Maestro is more than one binary. Here is what each piece does and what it costs.

Component	What it does	Cost	Open source?
Maestro CLI	Runs flows locally and in CI. The core of everything.	Free	Yes (Apache 2.0)
Maestro Studio (desktop)	Visual IDE: inspect elements, record interactions, build flows without the terminal. Available for macOS, Windows and Linux.	Free	No
Maestro MCP	Built into the CLI (`maestro mcp`). Lets AI coding agents such as Claude Code, Cursor, Copilot, Codex and Gemini run flows, inspect the screen and write tests.	Free	Yes
Maestro Cloud	Hosted parallel execution on managed simulators, emulators and browsers.	Paid	No

A note on Studio: older versions of the CLI shipped a browser-based Studio (maestro studio). That was removed in CLI 2.6.0 in favor of the desktop app. If you find older tutorials using maestro studio, that is why they no longer match.

A note on AI: the old maestro chat command was discontinued in 2.7.0. The supported path for AI-assisted test authoring is now Maestro MCP.

Getting started in five minutes

1. Install

You need Java 17 or newer.

java -version

Then install the CLI on macOS, Linux or Windows (WSL):

curl -fsSL "https://get.maestro.mobile.dev" | bash

Or, on macOS with Homebrew:

brew tap mobile-dev-inc/tap
brew install maestro

Verify:

maestro --version

2. Start a device

For iOS you need Xcode with at least one Simulator runtime installed. For Android, an emulator from Android Studio. Maestro can also start one for you:

maestro list-devices
maestro start-device --platform ios

3. Write a flow

Save this as contacts.yaml. It uses the built-in iOS Contacts app, so you do not need your own app yet:

appId: com.apple.MobileAddressBook
---
- launchApp
- tapOn: "Add"
- tapOn: "First name"
- inputText: "Ada"
- tapOn: "Last name"
- inputText: "Lovelace"
- tapOn: "Done"
- assertVisible: "Ada Lovelace"

Button and field labels in Apple's built-in apps can change between iOS versions. If a step fails, open Maestro Studio or run maestro hierarchy to see the exact labels on your simulator.

4. Run it

maestro test contacts.yaml

You will see each step printed as it runs, with a pass or fail marker. On failure, Maestro saves a screenshot, the view hierarchy and logs so you can see what was on screen at the moment it broke.

What is important for developers to know

These are the things that are easy to miss in the marketing material but matter once you adopt Maestro on a real project.

1. iOS testing targets Simulators

Maestro's officially supported local iOS target is the Simulator. You need a Simulator build (.app), not an App Store or Ad Hoc .ipa. Support for physical iPhones has been one of the most requested features in the repository for a long time. Today, if you need real iOS hardware, your options are third-party projects or device clouds that have added Maestro support on physical devices (TestingBot is one example). Check the current docs before you plan around real devices.

Android has no such limitation: emulators and USB-connected physical devices both work.

2. Accessibility identifiers make tests stable

Maestro can find elements by visible text, which is great for getting started. For a test suite you plan to keep, add stable identifiers:

SwiftUI / UIKit: accessibilityIdentifier
Android: resource-id / testTag
React Native: testID
Flutter: Semantics(identifier: ...) or keys exposed through semantics

Then target them with id:

- tapOn:
    id: "loginButton"

Text selectors break when copy changes or when you test in another language. IDs do not.

3. YAML is simple until it isn't

For linear user journeys, YAML is a joy. For complex logic (loops with conditions, computed data, calling a backend to seed state), you will reach for Maestro's JavaScript support (runScript, evalScript, ${...} expressions and an http client). It works, but it is not a full programming language with an IDE, types and a debugger. If your test strategy depends on heavy logic, factor that into your choice.

4. Black-box means no app internals

You cannot call into your app's code, stub a network layer from inside the process, or read internal state. If you need that, it has to happen outside Maestro: a test backend, launch arguments, or a debug-only screen. Maestro's own built-in network mocking was deprecated years ago.

5. It is not a replacement for unit or in-process UI tests

Maestro is excellent for high-level user journeys: sign-up, checkout, onboarding, critical paths. It is not the right tool for testing every state of a single component. Keep XCTest/XCUITest, Espresso or your framework's widget tests for that.

6. CI is straightforward, scaling is the hard part

Running Maestro in CI is just maestro test plus JUnit or HTML reports. Scaling is where costs appear. iOS Simulators need macOS machines. Locally you can shard across several simulators (parallel iOS simulator execution became reliable in CLI 2.6.0), but at some point teams either buy more Mac runners or move to a cloud.

7. The project moves fast

The CLI ships frequently, and some releases deprecate flags. For example, --ios-version and --android-api-level are being replaced by --device-os and --device-model. Pin your Maestro version in CI and read the changelog when upgrading.

How Maestro compares to other tools

Free and open-source frameworks

Tool	Platforms	Test language	Approach	Setup effort	Best for
Maestro	iOS, Android, Web	YAML (+ JS)	Black-box	Minutes	Cross-platform user journeys, mixed teams, fast feedback
Appium	iOS, Android, Web, Windows, more	Java, JS/TS, Python, C#, Ruby	Black-box (WebDriver)	Hours to days	Large cross-platform suites, teams with existing Selenium skills
XCUITest	iOS only	Swift / Obj-C	In Xcode, separate test process	Low (built into Xcode)	iOS-only teams who want native tooling and real-device support
Espresso	Android only	Kotlin / Java	Gray-box, in-process	Low	Android-only teams, fast and stable component-level UI tests
Detox	iOS, Android (React Native)	JS / TS	Gray-box, syncs with RN internals	Moderate to high	React Native apps that need tight synchronization
Flutter integration_test / Patrol	iOS, Android (Flutter)	Dart	In-process, Patrol adds native interaction	Moderate	Flutter teams who want tests in Dart

Maestro vs Appium. Appium is the most flexible and the most mature: any language, any platform, huge ecosystem, real iOS devices. It is also the most work to set up and maintain, and tests tend to need explicit waits. Maestro trades flexibility for speed of authoring and lower flakiness. Many teams that move from Appium to Maestro do so because test maintenance, not test execution, was their bottleneck.

Maestro vs XCUITest. XCUITest is Apple's own framework. It is fast, deeply integrated with Xcode and supports real devices. But tests are Swift code that needs a test target, compilation and more boilerplate, and it only covers iOS. If you ship on both platforms, you would also need Espresso and two separate suites. Maestro gives you one suite, often with shared flows across platforms.

Maestro vs Detox. Detox is gray-box: it knows when React Native is idle, which makes it very stable for RN apps. That same coupling makes setup harder and limits it to React Native. Maestro works with any framework but synchronizes based on what is on screen rather than JS thread state.

Paid platforms and device clouds

Most paid offerings are infrastructure: they run tests you have already written on hosted devices. Prices below are list prices published at the time of writing (October 2026). Always confirm on the vendor's pricing page.

Service	What you get	Pricing model	Maestro support
Maestro Cloud	Official hosted runner for Maestro flows, parallel execution, artifacts, notifications	$250 per device per month for iOS or Android, $125 per browser per month for web; enterprise plans available; 7-day free trial	Native
BrowserStack App Automate	Large real-device cloud for Appium, Espresso, XCUITest and more	Per parallel session; App Automate starts around $199 per parallel per month billed annually	Yes, via integration
Sauce Labs	Real devices and emulators, enterprise features	Per parallel test with unlimited users and minutes	Check current docs
TestingBot	Real devices and simulators, Maestro CLI integration	Subscription	Yes, including physical iOS devices
DeviceCloud (devicecloud.dev)	Maestro-focused cloud runner	Pro plan from $25 per month including test credits, usage on top	Yes
AWS Device Farm / Firebase Test Lab	Pay-as-you-go device access from the major clouds	Metered usage with free tiers or trials	Possible with custom setup, not first-class
AI-native testing tools (for example Drizz, Autosana)	Natural-language or vision-based test authoring and self-healing	Subscription, usually quote-based	Not applicable; they are alternatives

A simple way to think about it:

Authoring cost (how long tests take to write and maintain): Maestro is among the lowest.
Execution cost (where tests run): free on your own machines, then you pay either for Mac CI runners or for a device cloud. The cloud choice is mostly about price per parallel, device coverage (real vs virtual) and where your data is allowed to go.

When to choose Maestro

Maestro is a strong fit if:

You ship on both iOS and Android, or plan to.
You want end-to-end coverage of critical user journeys without building a test framework.
QA engineers, product people or designers should be able to read and contribute to tests.
Flaky tests are a bigger problem for you than raw test speed.

Look elsewhere, or combine tools, if:

You must run iOS tests on physical devices in your own lab with official support.
Your tests need deep access to app internals or in-process mocking.
You need thousands of fine-grained UI assertions per component (use XCUITest, Espresso or framework tests for those).
Your organization already has a large, healthy Appium suite.

Wrapping up

Maestro's pitch is simple: describe what a user does, in plain YAML, and let the framework handle the waiting and retrying. For most teams the biggest win is not execution speed but the fact that tests are quick to write, easy to read and less likely to become the flaky suite nobody trusts.

In Part 2, we will build a small SwiftUI app with a login screen and a to-do list, then write a full Maestro suite for it: stable selectors, sub-flows, environment variables, conditional logic for permission dialogs, tags, reports and a GitHub Actions workflow.

Resources

GitHub: mobile-dev-inc/maestro

Xcode 27.2: What Developers Need to Know (Including the New JSON Project Format)

ArshTechPro — Fri, 23 Oct 2026 11:15:00 +0000

Xcode 27.2 is a point release, but it ships one change that will affect almost every team sooner or later: a new JSON-based project file that replaces the old project.pbxproj. The rest of the release is a mix of small features, a solid batch of Device Hub and Previews fixes, and a few known issues you should know about before you upgrade your CI machines.

This post walks through what matters, in order of how likely it is to affect your day.

Note: This is based on Apple's Xcode 27.2 release candidate notes. Details can still shift before the final release, so check the official notes linked at the end before making team-wide decisions.

TL;DR

Requirements: macOS Tahoe 26.6 or later. Ships with Swift 6.4 and the 27.2 SDKs for iOS, iPadOS, macOS, tvOS, watchOS, and visionOS.
Biggest change: a new JSON project format (.xcproj) that is readable, diff-friendly, and much less prone to merge conflicts. It is the default for new projects and opt-in for existing ones.
Compatibility gotcha: .xcproj projects open in Xcode 27 and later only. Anyone still on Xcode 26 cannot open them.
Coding Assistant: a new GetCodeCoverage MCP tool so agents can read coverage from your latest test run.
Previews: a new Display group in the canvas overrides picker for alternate displays, plus several reliability fixes.
Device Hub: many input-related fixes, including iOS 17 simulator input.
Watch out for: a deployment-target bug in the non-iOS SDKs, Mac Catalyst compile errors with iOS 27.1-only APIs, and a few simulator quirks (workarounds below).

Requirements and platform support

Item	Xcode 27.2
Host macOS	macOS Tahoe 26.6 or later
Swift	6.4
SDKs	iOS, iPadOS, tvOS, watchOS, macOS, visionOS 27.2
On-device debugging	iOS 17+, tvOS 17+, watchOS 10+, visionOS

If your build machines are still on an older macOS, update them first. That is usually the step that blocks CI upgrades, not Xcode itself.

Apple also notes that the iOS SDK and simulator support for iPhone Duo come from a separate download on the Apple Developer downloads page, so grab that if you are targeting the new hardware.

The headline: a JSON project format (`.xcproj`)

If you have ever resolved a merge conflict in project.pbxproj, this is the section you care about.

What changed

An .xcodeproj bundle has always contained a project configuration file called project.pbxproj. It is an old-style property list full of generated 24-character object IDs, cross-references, and comments. It works, but it is hard to read, hard to review, and famously painful to merge.

Starting in Xcode 27.2, Xcode can store that configuration as a JSON file named project.xcproj instead. According to Apple, the new file is:

Smaller and hierarchical. Structure is nested rather than a flat table of objects pointing at each other by ID.
Self-describing. You can open it and understand what you are looking at.
Easier to review. Changes in a diff line up with what you actually did in Xcode, so a pull request that adds one file shows a small, readable change.
Less conflict-prone. Configuration changes are more isolated, so two people adding files to the same target are far less likely to collide.
Agent-friendly. Coding assistants (Xcode's own or external ones over MCP) can edit it reliably instead of guessing at pbxproj IDs.

The outer .xcodeproj folder stays the same. Only the file inside it changes:

Before:
MyApp.xcodeproj/
  project.pbxproj
  project.xcworkspace/
  xcshareddata/

After:
MyApp.xcodeproj/
  project.xcproj        <- new JSON file
  project.xcworkspace/
  xcshareddata/

So scripts and tools that just point at MyApp.xcodeproj (for example xcodebuild -project MyApp.xcodeproj) keep the same path. Tools that open and parse project.pbxproj directly are a different story; more on that below.

Is it the default?

New projects created in Xcode 27.2 use the JSON format by default.
Existing projects keep using project.pbxproj until you switch them.

Xcode 27 and later understands both formats, so there is no forced migration.

How to convert an existing project

Open the project in Xcode 27.2.
Select the project in the Project navigator.
Open the File inspector (right sidebar).
Under Project Document, set Project Format to JSON.
If a confirmation dialog appears, click Continue.

Xcode removes project.pbxproj and adds project.xcproj inside your .xcodeproj.

How to undo it

If you use source control, reverting is simple: discard the change that deleted project.pbxproj and added project.xcproj. For example, with Git:

git restore MyApp.xcodeproj/project.pbxproj
rm MyApp.xcodeproj/project.xcproj

My recommendation: do the conversion as its own commit with nothing else in it. That makes it trivial to review and trivial to roll back.

Compatibility: read this before converting a shared project

This is the part that can bite a team.

.xcproj projects open in Xcode 27 and later, including earlier Xcode 27.x releases.
They do not open in Xcode 26 or earlier.

Before converting a shared repository, check:

Every developer on the team is on Xcode 27 or later.
Every CI runner (GitHub Actions, Xcode Cloud, Bitrise, self-hosted, and so on) uses an Xcode 27 image.
Release branches that still build with an older Xcode are not affected. Convert on your main branch, not on a maintenance branch that must keep building with Xcode 26.

Check your tooling

A lot of iOS tooling reads or writes project.pbxproj directly. Common examples include project generators, dependency managers that patch your project, release automation, and linters that inspect build settings or file membership. Until those tools announce support for .xcproj, assume they may not understand it.

Practical approach:

Convert on a branch.
Run your full pipeline: dependency install, build, tests, signing, and any scripts that touch the project.
Only merge once everything passes.

If you generate your project from a spec (for example with a project generator), you may not need to convert at all; keep generating whatever format your tool supports and revisit later.

Apple open sourced the format

Apple published the format as an open source Swift package, xcode-project-format (Apache 2.0). It models the whole project (targets, groups, file references, build phases, build rules, and more) as typed Swift values under an XCSchema namespace, and it includes a small CLI called xcprojformatter.

That matters because tool authors no longer need to reverse-engineer the format. If you maintain internal scripts that poke at project files, this is the library to build on.

Add it to a package:

dependencies: [
    .package(url: "https://github.com/apple/xcode-project-format/", from: "0.1.0")
]

A quick script that prints every target in a project:

import Foundation
import XcodeProjectFormat

let url = URL(fileURLWithPath: "MyApp.xcodeproj/project.xcproj")
let data = try Data(contentsOf: url)
let project = try XCSchema.Project(jsonRepresentation: data)

for target in project.targets {
    print(target.name)
}

The package requires Swift 6.1 or later and macOS 14 or later, and also builds on non-Apple platforms, which is handy for Linux-based CI checks.

Should you switch now?

Switch now if:

Your whole team and CI are already on Xcode 27.
You regularly fight project.pbxproj merge conflicts.
You use coding agents to add files, targets, or build settings.

Wait if:

Anyone still needs to open the project in Xcode 26.
You depend on tools that edit the project file and have not confirmed .xcproj support.
You generate the project from a spec and the generator does not output .xcproj yet.

Coding Assistant: code coverage over MCP

Xcode 27.2 adds a GetCodeCoverage MCP tool. It reports code coverage from your most recent test result, and you can filter it by target or by file.

Why it is useful: an agent can now run your tests, check which lines are not covered, and write tests for exactly those gaps, all without you exporting coverage reports by hand. If you use an external agent connected to Xcode over MCP, it gets access to this tool too.

Related fix: the RenderPreview MCP tool now returns the list of available render destinations and lets the caller choose which one to render on. Agents that render SwiftUI previews can now target a specific device instead of whatever the default happens to be.

Previews

New: the canvas overrides picker now has a Display group, so you can preview content on a device's alternate display. If you are building for hardware with more than one screen (such as iPhone Duo), this is how you check the second display without running the app.

Fixed:

Previews no longer fail in source files that use Windows-style CRLF line endings. If you share code with Windows-based tooling or have files that came through a cross-platform repo, this one may have been silently breaking your canvas.
If another user account on the same Mac owns the Previews JIT directory, Xcode now shows a clear error with recovery steps instead of a vague failure. Shared build Macs and multi-user setups hit this.
Clearer error when the selected platform cannot show a preview's content.
Selecting a preview from a preview group's thumbnail grid on macOS now reliably opens the right one.

Device Hub and Simulator fixes

Device Hub got a lot of input-handling fixes. If you mirror and control devices or simulators from Xcode, most of these will feel like things just started working:

Keyboard and mouse input now works for simulators running older OS versions (before iOS 18, tvOS 18, watchOS 11, and visionOS 2).
Device Hub now supports input to iOS 17 simulators.
Device Hub no longer stops sending touch and button input to a connected device after it has been idle for a while.
Disconnecting a physical device while Simulate Hardware Keyboard was on no longer leaves it stuck in hardware keyboard mode (which used to hide the software keyboard for up to two minutes).
Modifier keys (Shift, Control, Option, Command) now go to the right device when multiple device windows are open.
Holding Escape now exits keyboard capture mode.
Deleted simulator runtimes are now fully removed, instead of reappearing after a reboot.

Known issues to plan around

These are the ones most likely to cost you time.

SDK deployment target bug (macOS, watchOS, tvOS, visionOS)

The macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly list 27.1 as a valid deployment target. If you pick it, builds and other features may behave unexpectedly. Mac Catalyst builds with a 27.1 or 27.2 deployment target may also be unable to use newly introduced APIs.

What to do: do not set your deployment target to 27.1 on those platforms with this Xcode. Stick with the target you already had, or 27.2 if you need the new APIs and are not building for Catalyst.

Mac Catalyst: compile errors with iOS 27.1-only APIs

Projects that use APIs specific to iOS 27.1 can fail to compile for Mac Catalyst with errors like "undeclared identifier", "has no member", or "cannot find".

Workaround: wrap the affected code in a compile-time check.

Swift:

#if !targetEnvironment(macCatalyst)
// iOS 27.1-only API usage here
#endif

Objective-C:

#if !TARGET_OS_MACCATALYST
// iOS 27.1-only API usage here
#endif

Simulator runtime shows as unavailable after reinstalling

If you delete a simulator runtime and reinstall it, Xcode may still show it as unavailable.

Workaround: restart the CoreSimulator service.

killall -9 com.apple.CoreSimulator.CoreSimulatorService

Device Hub crashes when selecting a Vision Pro simulator without a runtime

If no visionOS runtime is installed, selecting a Vision Pro simulator in Device Hub can make Device Hub quit.

Workaround: install the matching visionOS runtime from Xcode, or delete that simulator device.

Smaller ones

Simulate Memory Warning (Device menu) does not work. If you test memory-pressure handling, trigger it another way for now.
iPhone Duo screenshots and recordings can come out black for up to a few minutes after the device boots. Wait a bit before capturing App Store screenshots.
Cloning a 27.2 simulator device can fail due to incorrect file permissions. If you script simulator cloning for parallel tests, watch for this.
Accessibility tools (VoiceOver, Accessibility Inspector) cannot read screen content on iPhone Duo inside Device Hub. Test accessibility on a physical device or a regular simulator window.
CarPlay in Device Hub needs a USB-connected device. Network-connected devices and the iOS Simulator are not supported for CarPlay.

Upgrade checklist

Update build Macs to macOS Tahoe 26.6 or later.
Install Xcode 27.2 side by side with your current Xcode first, and run your full test suite.
If you target iPhone Duo, download its SDK and simulator support separately.
Check your non-iOS deployment targets are not set to 27.1.
If you ship Mac Catalyst, look for iOS 27.1-only API usage and add #if !targetEnvironment(macCatalyst) guards.
Decide on .xcproj: convert only when the whole team and CI are on Xcode 27, and do it as a standalone commit.
If you use coding agents, try GetCodeCoverage to have them target untested code.

Wrapping up

Most of Xcode 27.2 is polish: better Device Hub input, sturdier Previews, and a couple of handy MCP tools for agents. The JSON project format is the real story. It fixes one of the oldest pain points in Apple development, and because it is open source, the tooling ecosystem can catch up quickly. Give your CI and tools a test run on a branch, and once everything is green, the days of untangling project.pbxproj conflicts are over.

References

Xcode 27.2 Release Notes

Supabase in 2026: Is This Open Source Backend Worth a Try?

ArshTechPro — Tue, 20 Oct 2026 11:35:33 +0000

If you have ever started a side project and spent the first weekend wiring up a database, user sign-ups, file uploads and an API before writing a single feature, Supabase was built for you.

In this article we will look at what Supabase actually is, how it works under the hood, how to get a project running in a few minutes, and whether it is worth adding to your toolbox.

What is Supabase?

Supabase describes itself as "the Postgres development platform." The short version: you get a real Postgres database, plus the backend pieces most apps need, without having to build them yourself.

Out of the box you get:

A hosted Postgres database (a full one, not a limited abstraction)
Authentication with email, magic links, OAuth providers and more
Auto-generated APIs (REST and GraphQL) based on your tables
Realtime subscriptions to database changes over websockets
Storage for files like images and documents
Edge Functions for custom server-side logic
Vector support through pgvector for AI and embeddings work
A dashboard with a table editor, SQL editor and logs

It is often called an open source Firebase alternative. The big difference is that Supabase is built on SQL and Postgres instead of a proprietary NoSQL store, so your data model is relational and portable.

The project is very active: the main repository has over 100k stars on GitHub and is licensed under Apache 2.0.

How it works under the hood

One thing I like about Supabase is that it is not a black box. It is a collection of open source tools, glued together:

Piece	What it does
Postgres	The database at the center of everything
PostgREST	Turns your database schema into a REST API
GoTrue (Auth)	JWT-based sign-up, login and sessions
Realtime	An Elixir server that broadcasts database changes over websockets
Storage API	S3-compatible file storage, with permissions handled in Postgres
pg_graphql	A Postgres extension that exposes a GraphQL API

Because everything sits on top of Postgres, permissions are handled with Postgres Row Level Security (RLS). That means your security rules live next to your data, not scattered across your app code.

Getting started in 5 minutes

1. Create a project

Your project URL
Your publishable (anon) key

2. Create a table

Open the SQL editor in the dashboard and run:

create table todos (
  id bigint generated always as identity primary key,
  user_id uuid references auth.users not null default auth.uid(),
  title text not null,
  done boolean default false,
  created_at timestamptz default now()
);

alter table todos enable row level security;

create policy "Users can manage their own todos"
on todos for all
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

That last part matters. With RLS enabled and this policy in place, each user can only see and edit their own rows, even though the frontend talks to the database directly.

3. Install the client

npm install @supabase/supabase-js

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://your-project.supabase.co',
  'your-publishable-key'
)

4. Sign up a user

const { data, error } = await supabase.auth.signUp({
  email: 'dev@example.com',
  password: 'a-strong-password',
})

5. Read and write data

// Insert
await supabase.from('todos').insert({ title: 'Write a dev.to article' })

// Select
const { data: todos } = await supabase
  .from('todos')
  .select('*')
  .order('created_at', { ascending: false })

No API routes, no ORM setup, no controller files. The REST API already exists because the table exists.

6. Listen for changes in realtime

supabase
  .channel('todos-changes')
  .on(
    'postgres_changes',
    { event: 'INSERT', schema: 'public', table: 'todos' },
    (payload) => console.log('New todo:', payload.new)
  )
  .subscribe()

That is enough to build a live-updating todo app, chat, or dashboard.

Local development

You do not have to develop against the cloud. The Supabase CLI runs the whole stack locally with Docker:

npx supabase init
npx supabase start

This gives you a local database, auth, storage and dashboard. You can write migrations, test them locally, and push them to your hosted project when you are ready. It also generates TypeScript types from your schema, which makes the client fully typed:

npx supabase gen types typescript --local > database.types.ts

If you want to avoid cloud hosting entirely, Supabase can also be self-hosted with Docker.

Client libraries

Official clients exist for JavaScript/TypeScript, Flutter, Swift and Python. The community maintains clients for C#, Kotlin, Go, Ruby and others. So whether you are building a Next.js app, a mobile app or a Python backend, you are covered.

The good and the not-so-good

What works well

It is just Postgres. You can use SQL, joins, views, triggers, extensions and any Postgres tool you already know. If you ever leave, you take a standard Postgres database with you.
Very fast to start. Auth, storage and an API in minutes is not marketing speak; it really is that quick.
Open source. You can read the code, self-host it, and avoid hard lock-in.
Strong docs and community. The docs are good, and the Discord and GitHub discussions are active.
Good fit for AI apps. pgvector support means you can store embeddings next to your regular data.

What to watch out for

You need to learn RLS. If you forget to enable Row Level Security or write a loose policy, your data can be exposed. Take the time to understand it.
Logic in the database is a mindset shift. Policies, functions and triggers in SQL can feel unfamiliar if you are used to keeping all logic in your backend code.
Free tier limits. The free plan is generous for learning and prototypes, but inactive free projects can be paused, and real production apps will usually need a paid plan. Check the pricing page for current details.
Self-hosting takes effort. It is possible, but running the full stack yourself in production means you own upgrades, backups and monitoring.

So, is it worth a try?

Yes, for most developers it is.

Supabase is a great choice if you:

Want to ship a side project, MVP or SaaS quickly
Prefer SQL and relational data over document databases
Are building frontend-heavy or mobile apps and do not want to write a custom backend
Want an AI-ready database with vector search built in

It may not be the best fit if you need a highly custom backend architecture, have strict requirements that rule out managed services and do not want to self-host, or your team has no interest in learning Postgres.

The best way to decide is to build something small. Spin up a free project, create one table, turn on RLS, and connect a frontend. In an afternoon you will know whether Supabase fits the way you like to work.

Useful links

GitHub: github.com/supabase/supabase

A Free Prerequisite Graph of Everything Kids Learn: Exploring Marble's os-taxonomy

ArshTechPro — Tue, 20 Oct 2026 09:09:20 +0000

If you have ever tried to build anything in education tech, you have probably hit the same wall: curriculum data is either a flat list of standards in a PDF, or it is locked inside someone's product.

A flat list tells you what a child should learn in Year 2. It does not tell you what they need to know first. And that second question is the one that matters if you are building adaptive practice, a tutoring app, a learning-path generator, or an AI tutor that needs to know where a kid is stuck.

os-taxonomy from Marble is an attempt to fix that. It is an open dataset that breaks primary and elementary learning into small, teachable ideas and connects them with prerequisite edges. It has picked up around 4.8k stars, which is a lot for a pure data repo.

Here is what is in it, how to use it, and whether it is worth your time.

What you actually get

It is a graph, shipped as plain JSON.

1,591 micro-topics (nodes). Each is one teachable idea, like "Building sentences" or "Apparent brightness of stars".
3,225 prerequisite edges. "Topic X depends on topic Y", each tagged hard or soft, with a one-line reason.
Curriculum alignment. Topics link to the standards they came from: Common Core, NGSS, the UK National Curriculum, the C3 social studies framework, and IB PYP.
176 domain clusters. Short, parent-friendly summaries per subject, domain, and age band.
Teaching research. 1,051 records on how to teach Science and Mathematics topics, with activities, feedback ideas, and assessment guidance. More on this below.

Coverage is weighted toward the core subjects:

Subject	Topics
Science	547
Mathematics	504
English	286
History	90
Personal & Social Development	88
Life Skills	37
Computing	21
Learning to Learn	18

There is no runtime, no package, and no dependencies. You clone the repo and read JSON files.

The data model

Everything lives in data/:

File	Contents
`topics.json`	The micro-topics (nodes)
`dependencies.json`	Prerequisite edges
`curriculum-standards.json`	Source standards, grouped by curriculum
`clusters.json`	Domain summaries
`teaching-research.json`	Teaching guidance per topic (about 23 MB)
`manifest.json`	Counts and SHA-256 checksums

JSON Schemas for each file are in schema/.

A topic looks like this (trimmed):

{
  "id": "mt_N8CpN1EJrP",
  "type": "CONCEPTUAL",
  "subject": "English",
  "domain": "Grammar & Punctuation",
  "name": "Building sentences",
  "ageRangeStart": 4,
  "ageRangeEnd": 6,
  "centrality": 0.257,
  "evidence": [
    "Distinguish between complete sentences and fragments",
    "Compose a complete sentence with a subject and verb"
  ],
  "assessmentPrompt": "If {{name}} says something like \"The dog\", can they tell you...",
  "standards": ["ccss-ela:L.K.1f", "uk-nc-2013:Eng.App2.Y1.Sent.1"]
}

A few fields are worth calling out:

type classifies the kind of knowledge: conceptual, procedural, representational, language, or meta.
evidence is a list of observable mastery criteria. This is the useful bit for anyone building assessments.
centrality gives you a rough sense of how connected a topic is in the graph.
assessmentPrompt is a natural-language check with a {{name}} placeholder for the child's name. Replace or strip it before showing it to anyone.

And an edge:

{
  "topicId": "mt__00ZSLnB7p",
  "prerequisiteId": "mt_VBl1T1sFCM",
  "strength": "hard",
  "reason": "Must understand vibrations make sound before finding volume patterns"
}

Read it as "topicId depends on prerequisiteId". Flip it and you get "unlocks".

Getting started in five minutes

git clone https://github.com/withmarbleapp/os-taxonomy.git
cd os-taxonomy
node scripts/validate.mjs   # checks structure, references, and checksums

Find the direct prerequisites of a topic

This uses JSON import attributes, so use a recent Node version (22 or newer is safest):

import topics from './data/topics.json' with { type: 'json' };
import deps from './data/dependencies.json' with { type: 'json' };

const byId = new Map(topics.topics.map(t => [t.id, t]));

const prereqsOf = id =>
  deps.dependencies
    .filter(d => d.topicId === id)
    .map(d => byId.get(d.prerequisiteId));

// "Addition and subtraction word problems"
console.log(prereqsOf('mt_yJmvUCCym7').map(t => t.name));
// [ 'Representing Addition and Subtraction' ]

Build a full learning path

The interesting thing about a prerequisite graph is that you can walk it. Since the graph is a DAG (no cycles), a depth-first walk gives you every topic a learner needs before the target, in an order they could actually study them:

const edgesByTopic = new Map();
for (const d of deps.dependencies) {
  if (!edgesByTopic.has(d.topicId)) edgesByTopic.set(d.topicId, []);
  edgesByTopic.get(d.topicId).push(d);
}

function learningPath(targetId, { hardOnly = true } = {}) {
  const seen = new Set();
  const order = [];

  function visit(id) {
    if (seen.has(id)) return;
    seen.add(id);
    for (const d of edgesByTopic.get(id) ?? []) {
      if (hardOnly && d.strength !== 'hard') continue;
      visit(d.prerequisiteId);
    }
    order.push(byId.get(id));
  }

  visit(targetId);
  return order; // prerequisites first, target last
}

for (const t of learningPath('mt_yJmvUCCym7')) {
  console.log(`${t.ageRangeStart}-${t.ageRangeEnd}  ${t.subject}  ${t.name}`);
}

Running it on "Addition and subtraction word problems" prints:

4-6  Mathematics  One-to-one counting
4-6  Mathematics  How Many in Total?
4-6  Mathematics  Addition as combining or putting together two
4-6  Mathematics  Subtraction as taking away or separating
4-6  Mathematics  Representing Addition and Subtraction
4-6  Mathematics  Addition and subtraction word problems

That is a sensible sequence: count, combine, take away, represent it, then solve word problems.

The hardOnly flag is handy. Hard edges are true blockers. Soft edges are "helpful to know", so include them when you want a gentler path and drop them when you want the shortest one.

Prefer Python?

Same idea with networkx:

import json
import networkx as nx

topics = {t["id"]: t for t in json.load(open("data/topics.json"))["topics"]}
deps = json.load(open("data/dependencies.json"))["dependencies"]

G = nx.DiGraph()
for d in deps:
    G.add_edge(d["prerequisiteId"], d["topicId"], strength=d["strength"])

target = "mt_yJmvUCCym7"
needed = nx.ancestors(G, target) | {target}
path = list(nx.topological_sort(G.subgraph(needed)))

for tid in path:
    print(topics[tid]["name"])

Once it is in networkx, you also get the usual graph tools for free: finding the most "foundational" topics, spotting bottlenecks, or checking which topics unlock the most downstream learning. Note that this version follows soft edges too, so it can return a longer path than the JavaScript one.

Add the teaching guidance

The newest file, teaching-research.json, covers what to do with a topic. Each record joins to a topic by topicId and includes a teaching summary, concrete activities with feedback ideas, common misconceptions, assessment guidance, and sources.

import research from './data/teaching-research.json' with { type: 'json' };

const guidanceByTopic = new Map(research.records.map(r => [r.topicId, r]));
const guidance = guidanceByTopic.get('mt_yJmvUCCym7');

console.log(guidance?.learn.summary);
for (const a of guidance?.learn.activities ?? []) console.log('-', a.title);
// - Story-modelling with counters and a mat
// ...

Only Science and Mathematics are covered so far. For English and the other subjects, guidance will be undefined, so keep that ?. in place.

What you could build with it

Adaptive practice. When a kid fails a topic, walk back one hard edge and test the prerequisite instead of repeating the same question.
AI tutors. Give an LLM the topic, its evidence list, its prerequisites, and (for maths and science) its teaching activities as structured context. That grounds the model far better than "teach my kid fractions".
Placement and diagnostics. Use evidence and assessmentPrompt to build quick checks, then use the graph to infer what a child probably already knows.
Curriculum mapping. Because topics link to both Common Core and the UK National Curriculum, you can roughly map content between the two systems.
Visualizations. The repo includes a 3D graph render, and Marble has an interactive version where you can click a topic and see everything that leads to it.

The caveats, honestly

The licensing needs a careful read. This is the most important part. The dataset has three layers with different terms:

The database (structure, IDs, relationships) is under ODbL 1.0.
Marble's written text (names, descriptions, evidence, prompts, reasons) is under CC BY-SA 4.0.
curriculum-standards.json is not Marble's to license. Each source keeps its upstream terms.

So, is it worth a try?

If you work anywhere near education tech, yes. It takes minutes to load, and a well-structured prerequisite graph with mastery criteria is the kind of thing teams usually spend months building internally. Even if you do not use it as-is, it is a good reference model for how to structure learning data.

It is especially useful as grounding data for AI tutoring tools, where the hard problem is often not generating explanations but knowing what to teach next.

Just read the license section before shipping anything commercial, and treat v1 as a strong foundation that you validate, not a finished curriculum.

A good first experiment: pick a topic your own kid (or a niece, nephew, or student) is struggling with, run learningPath() on it, and see whether the prerequisites match what you see in real life.

Links

Repository: github.com/withmarbleapp/os-taxonomy

CLI-Anything: Turning Desktop Software into Tools Your AI Agent Can Actually Use

ArshTechPro — Tue, 20 Oct 2026 04:52:40 +0000

If you have used an AI coding agent like Claude Code, Codex, or Cursor for more than a week, you have probably noticed something: agents are great in a terminal and pretty bad everywhere else.

Ask an agent to refactor a Python module and it does fine. Ask it to cut a video in Shotcut, add a layer in GIMP, or export a diagram from Draw.io, and things fall apart. The usual workaround is GUI automation: take a screenshot, guess where the button is, click, take another screenshot, repeat. It is slow, expensive in tokens, and breaks the moment a dialog moves.

CLI-Anything from the Data Intelligence Lab at the University of Hong Kong (HKUDS), takes a different route. Instead of teaching agents to use GUIs, it gives the software a proper command-line interface that agents can call directly.

This article covers what it is, how to try it quickly, and whether it is worth your time.

The core idea in one paragraph

Most "GUI" applications are really a user interface sitting on top of an engine. Blender has bpy. LibreOffice can run headless. Shotcut and Kdenlive render through MLT and melt. Inkscape works on SVG. CLI-Anything analyzes an application's codebase, finds that underlying engine, and generates a Python CLI (built on Click) that exposes the real functionality as commands. Every generated CLI supports --json output for agents, a human-readable mode for you, an interactive REPL, and project state with undo/redo.

So instead of an agent clicking through menus, it runs something like:

cli-anything-gimp project new --width 1920 --height 1080 -o poster.json
cli-anything-gimp --json layer add -n "Background" --type solid --color "#1a1a2e"

Structured input, structured output, no screenshots.

Two ways to use it

The project has two distinct entry points, and it helps to know which one you want before you start.

You want to...	Use
Use CLIs that already exist (GIMP, Blender, LibreOffice, OBS, Zotero, n8n, and many more)	CLI-Hub, the package manager
Generate a new CLI for software that is not covered yet, including your own internal tools	The CLI-Anything plugin for your coding agent

Most developers should start with the first one.

Option 1: Install ready-made CLIs with CLI-Hub

You need Python 3.10 or newer.

pip install cli-anything-hub

# See what is available
cli-hub list
cli-hub search image

# Install one and inspect it
cli-hub install gimp
cli-hub info gimp
cli-hub launch gimp

One thing that trips people up: these CLIs wrap the real software. If you install the Blender CLI, you still need Blender installed on your machine. The CLI is the interface, not a replacement for the application.

Let your agent pick the tool

If your agent supports skills (Claude Code, Codex, OpenClaw, and others), you can install a "meta-skill" that teaches it to search CLI-Hub, install what it needs, and read the usage docs on its own:

npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -y

Then just describe the task:

Find appropriate CLI software in CLI-Hub and complete the task: convert
all .docx files in ./reports to PDF and merge them into one file.

Each generated CLI also ships with a SKILL.md file describing its commands, so the agent gets documentation in a format it understands without you writing any prompts.

Option 2: Generate a CLI for something new

This is the more ambitious part of the project. You point the plugin at a codebase (a local folder or a GitHub URL), and your coding agent runs a seven-phase pipeline:

Analyze the source and map GUI actions to backend APIs
Design command groups, state model, and output formats
Implement the Click CLI with REPL, JSON output, and undo/redo
Plan tests in a TEST.md file
Write tests, both unit and end-to-end against the real software
Document the results
Publish a setup.py so the CLI installs onto your PATH

In Claude Code, setup looks like this:

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything

/cli-anything ./gimp

You can also pass a repo URL, for example /cli-anything https://github.com/blender/blender.

When the first pass is done, the refine command looks for gaps between what the software can do and what the CLI covers, then adds commands and tests for them:

/cli-anything:refine ./gimp "batch processing and filters"

Then install and use the result like any Python package:

cd gimp/agent-harness && pip install -e .
cli-anything-gimp --help
cli-anything-gimp          # no arguments opens the REPL

The plugin is available for Claude Code, Cursor, Codex, OpenCode, GitHub Copilot CLI, Pi, Qodercli, OpenClaw, Hermes, and Reasonix. Several of these are marked experimental or community-maintained, so expect the Claude Code path to be the most polished.

A note for Windows users: Claude Code runs shell commands through bash, so install Git for Windows or use WSL, otherwise you will hit cygpath: command not found.

Where it is genuinely useful

A few use cases where this approach makes a lot of sense:

Media and document pipelines. Batch converting documents with LibreOffice, rendering scenes in Blender, cutting and captioning video. These are tasks agents previously could not do reliably at all.
Wrapping messy APIs. You can feed API docs or an SDK to the generator and get one stateful CLI instead of dozens of raw HTTP calls. Fewer tool calls usually means fewer tokens and fewer mistakes.
Internal tools. If your team has an internal app with a decent codebase but no API, this is a fast way to make it scriptable for both agents and humans.
Testing and benchmarks. Once software has a CLI, you can generate agent tasks and evaluators in code rather than through screen recordings.

The repo's demos are worth a look. One shows an agent building a full HTTPS handshake diagram in Draw.io purely through commands. Another shows an agent assembling a rover model in FreeCAD with a live preview updating at each step.

The honest caveats

The project is popular (over 51k stars at the time of writing) and moves fast, but go in with realistic expectations.

Generation is not free. The seven-phase pipeline is a long agent run: reading a large codebase, writing an implementation, then writing and running tests. On a big project like Blender, that is a lot of tokens and time. Treat the output as a solid first draft that you review, not a finished product.

Coverage depends on what was exposed. A CLI is only as good as the commands it has. When a task needs something the harness does not expose, the agent cannot fall back to "just clicking it" the way a GUI agent could. This is a real trade-off: structured interfaces are more reliable when they cover the task and more brittle when they do not. The refine command helps, but it is not magic.

Quality varies across the registry. The core harnesses (GIMP, Blender, LibreOffice, Inkscape, Audacity, and others) have substantial test suites, and the repo reports more than 2,000 passing tests overall. Newer community contributions are thinner. Check the test count and last update before relying on a specific one.

You still need the real software. This is a feature, since it means you get real rendering and not a toy reimplementation, but it also means setup involves installing the upstream app and sometimes configuring it (for example, an API key or a local server).

Mind what you install. Like any community registry, review what a CLI does before giving an agent permission to run it, especially ones that touch credentials, file systems, or remote services. The maintainers have been fixing issues like path injection and unsafe XML parsing, which is a good sign, but it also tells you the attack surface is real.

So, is it worth a try?

Yes, with a clear scope.

If your agent work touches anything outside the code editor, such as documents, media, diagrams, or a desktop app your team relies on, CLI-Hub is a low-effort win. A pip install, one cli-hub install, and your agent can do things it simply could not do before. That takes about ten minutes to evaluate.

The generator is worth trying if you have a specific tool you want agents to control and you are willing to review and refine the output. It is less appealing if you just want to experiment casually, because the token and time cost of a full generation run is real.

The bigger idea behind the project is also worth paying attention to: rather than making agents better at pretending to be humans in front of a screen, give software an interface designed for agents in the first place. Whether or not CLI-Anything becomes the standard way to do that, it is a practical, working example of the approach today.

A good first experiment:

pip install cli-anything-hub
cli-hub search office
cli-hub install libreoffice

Then ask your agent to convert and merge a folder of documents, and compare how that feels against doing it through GUI automation.

Links

Repository: github.com/HKUDS/CLI-Anything

TokenSpeed: A New LLM Inference Engine Built for Coding Agents.

ArshTechPro — Thu, 15 Oct 2026 22:42:25 +0000

If you self-host large language models, you have probably settled into one of two camps. You use vLLM or SGLang because they are easy to run, or you use TensorRT-LLM because it squeezes the most out of NVIDIA hardware and you are willing to pay for that in setup pain.

TokenSpeed wants to end that trade-off. It is an open-source (MIT) inference engine from the LightSeek Foundation that targets TensorRT-LLM-level performance with vLLM-level usability, and it is tuned specifically for agentic workloads like coding assistants.

In this post we will cover what it is, why "agentic" changes the problem, how to get a server running in a few minutes, and whether it deserves a spot in your stack.

What problem is it solving?

Most inference benchmarks look like chat: a short prompt, a short answer, done. Coding agents look nothing like that.

A typical agent session has:

Very long contexts. Prompts regularly pass 50K tokens once you include files, tool output, and history.
Many turns. The same conversation comes back dozens of times, each time slightly longer.
A hard speed floor. If tokens stream slowly, the agent feels broken. The TokenSpeed team targets around 70 tokens per second per user as a minimum, sometimes 200+.

So the goal is not just "maximum throughput." It is maximum throughput per GPU while every user still gets fast generation. That framing drives most of TokenSpeed's design choices.

How it works (the short version)

You do not need to understand the internals to use it, but four pieces are worth knowing about:

Modeling layer. Instead of hand-writing tensor-parallel communication code for every model, developers annotate where data should live at module boundaries, and a small static compiler generates the collective operations. Less custom parallelism code means fewer bugs when adding new models.
Scheduler. The control plane is written in C++ as a finite-state machine. Request lifecycle and KV cache ownership are modeled explicitly, and the type system catches unsafe KV cache reuse at compile time instead of at 3 a.m. in production. The execution side stays in Python so it is still easy to hack on.
Kernels. Kernels live in their own pluggable package with a registry, so NVIDIA and AMD backends can sit side by side. Their MLA (Multi-head Latent Attention) kernel for Blackwell is fast enough that vLLM has adopted it.
Entrypoint. Requests come in through an OpenAI-compatible server built on their SMG project, keeping CPU-side overhead low.

Getting started

What you need

An NVIDIA GPU host (CUDA 13 for the nightly wheels), or an AMD host with ROCm 7.2
Python 3.11 to 3.13
Docker with GPU support if you want the easy path

Option 1: Docker (recommended)

The project ships a runner image with everything preinstalled:

docker pull lightseekorg/tokenspeed-runner:latest

docker run -itd \
  --shm-size 32g \
  --gpus all \
  --ipc=host \
  --network=host \
  -v ~/.cache:/home/runner/.cache \
  --name tokenspeed \
  lightseekorg/tokenspeed-runner:latest \
  /bin/bash

Mounting your cache directory means model weights survive container restarts.

Option 2: pip (nightly wheels)

On a CUDA 13 machine:

python -m pip install --upgrade tokenspeed \
  --extra-index-url https://lightseek.org/whl/nightly

Nightlies are versioned by date, so you can pin one for reproducibility:

python -m pip install "tokenspeed==0.1.0.post20260930" \
  --extra-index-url https://lightseek.org/whl/nightly

AMD users should follow the ROCm instructions in the getting started guide, since you need to install ROCm PyTorch first and use a separate wheel index.

Check that everything is in place:

tokenspeed env
tokenspeed serve --help

Launch your first model

GPT-OSS 20B fits on a single GPU and is a good smoke test:

tokenspeed serve openai/gpt-oss-20b \
  --served-model-name gpt-oss-20b \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1

Call it like OpenAI

Because the server speaks the OpenAI API, your existing client code works with only a base_url change:

from openai import OpenAI

client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")

response = client.chat.completions.create(
    model="gpt-oss-20b",
    messages=[{"role": "user", "content": "Explain KV caching in two sentences."}],
    max_tokens=200,
)
print(response.choices[0].message.content)

Or with curl:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-oss-20b",
    "messages": [{"role": "user", "content": "Hello!"}],
    "max_tokens": 100
  }'

That is the whole loop. Anything that already talks to OpenAI, including most agent frameworks, can point at this server.

Going bigger

For large MoE models the flags will look familiar if you have used vLLM. Here is the shape of a Kimi K2.5 launch on four Blackwell GPUs:

tokenspeed serve nvidia/Kimi-K2.5-NVFP4 \
  --served-model-name kimi-k2.5 \
  --trust-remote-code \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --quantization nvfp4 \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --reasoning-parser kimi_k25 \
  --tool-call-parser kimik2 \
  --host 0.0.0.0 --port 8000

The model recipes page has tested launch commands for DeepSeek V4, Qwen3 and Qwen3.8, GLM 5.x, MiniMax M3, Kimi K3, Nemotron-3 Super, and more. Start from a recipe rather than tuning flags from scratch.

What about performance?

The team's headline numbers, all self-reported:

On Kimi K2.5 running on NVIDIA B200 with a real coding-agent trace (SWE-smith, evaluated with EvalScope), TokenSpeed beat TensorRT-LLM across the whole latency/throughput curve. That works out to about 9% faster at batch size 1 and about 11% more throughput at around 100 tokens per second per user.
Their MLA decode kernel cut latency roughly in half versus TensorRT-LLM's on typical speculative-decoding workloads.
They reported up to 580 tokens per second on Qwen3.5-397B-A17B for agentic workloads.

These are vendor benchmarks, so treat them as a reason to test, not as a guarantee. The good news is the benchmark harness is in the repo under test/agentic_benchmark, so you can reproduce it on your own traffic.

Is it worth a try?

Yes, if:

You serve large MoE models (DeepSeek, Kimi, Qwen, GLM, MiniMax) for coding agents or other long-context, multi-turn workloads.
You run on recent NVIDIA hardware (Hopper, and especially Blackwell) or AMD MI350-class GPUs, and you care about cost per token.
You have been eyeing TensorRT-LLM for speed but do not want its build and setup overhead.
You want day-zero support for new frontier open models. TokenSpeed shipped launch-day support for Kimi K3 and Thinking Machines' Inkling.

REA: Let Your AI Agent Reverse Engineer the App Features You Wish You Had

ArshTechPro — Thu, 08 Oct 2026 11:28:11 +0000

You are using an app and notice a feature that just works. Instant offline search. A clever sync behavior. A smooth update flow. You want something similar in your own product, but you have no source code, no docs, and no idea where to start.

Traditionally, the answer was "learn reverse engineering." That means picking a disassembler, learning its API, digging through strings and symbols, following call graphs by hand, and copying findings between tools. It is a deep skill, and most application developers never have the time to pick it up.

REA takes a different approach: it hands that work to your AI coding agent.

In this post we will cover what REA is, how it works, how to set it up, and whether it is worth your time.

What is REA?

REA is an open-source (MIT) tool, written in TypeScript, that gives AI agents a consistent way to investigate software. It ships as:

A CLI (rea) you can run from your terminal
An MCP server that agents like Claude Code, Cursor, Codex, Gemini CLI, Windsurf, and Claude Desktop can call directly

The pitch is simple: point your agent at an app, ask how a feature works, and the agent uses REA to inspect the app, explain the feature with evidence, and then build a version adapted to your stack.

The mental model: Decompile, Understand, Recreate

REA frames every investigation in three stages:

Decompile - open the app and recover readable code, strings, symbol names, and other clues.
Understand - follow the code from one part of the app to another until the agent can explain how the feature actually works.
Recreate - turn what was learned into a feature for your own product, in your language and framework.

One thing worth stating up front: REA does not claim to recover the original source code, and it does not clone apps. It gives the agent pseudocode, assembly, symbols, strings, and relationships, and it shows the evidence behind every conclusion.

What a real investigation looks like

Say you ask your agent:

Reverse engineer the Notes app. Find how offline search works, explain it,
and build a version for my project using TypeScript and SQLite.

Behind the scenes, the agent works through roughly these steps using REA tools:

Step	What the agent does	Example REA tools
1	Opens and identifies the binary	`open_binary`, `binary_overview`
2	Looks for search-related clues	`search_strings`, `search_procedures`, `list_names`
3	Connects clues to actual code	`find_xrefs_to_name`, `xrefs`, `procedure_callers`
4	Rebuilds the control flow	`get_call_graph`, `procedure_callees`
5	Decompiles the important functions	`procedure_pseudo_code`, `batch_decompile`
6	Writes the feature in your project	Your agent's normal editing and test tools

REA handles steps 1 through 5. Step 6 is your agent doing what it already does well: writing code.

If you have done any manual reverse engineering, you will recognize this workflow. The difference is that the agent drives it instead of you.

How it works under the hood

REA itself is not a disassembler. It is an orchestration layer that sits between your agent and real analysis tools.

Agent / Terminal
      |
      v
  REA (CLI + MCP server)
      |
      +--> Deep analysis providers: Hopper, Ghidra
      +--> Native macOS utilities (Mach-O, code signatures, plists, Swift demangling)
      +--> Artifact provider (ZIP, APK, IPA, ASAR, MSIX inventory)
      +--> Browser provider (passive Chrome DevTools Protocol observation)
      +--> Process capture provider (controlled terminal sessions)
      |
      v
  Evidence records you can export, compare, and reuse

A few design choices stand out:

Providers do the heavy lifting. Hopper is the main deep-analysis provider, and Ghidra is supported as a read-only, bring-your-own option on Linux (plus an experimental Windows x64 mode).
Everything produces evidence. Each successful result is stored as a structured "Evidence v2" record that includes the provider, confidence, and known limitations. You can export these bundles, import them later, and diff them across app versions.
Unknowns stay unknown. REA is strict about not presenting guesses as facts. Static inference and runtime observation are labeled separately, and incomplete data is reported as incomplete.
Local by design. There is no hosted analysis service. The app you analyze stays on your machine (though your AI model provider still has its own data policy).
Same engine for CLI and MCP. Whatever your agent can do, you can also do from the terminal.

What it can analyze today

Native binaries get the deepest support, but REA covers more than that:

Native apps: Mach-O, ELF, PE, and macOS .app bundles, including Swift and Objective-C metadata
Packages and archives: ZIP, APK, IPA, ASAR, plus file-level inventory without extraction
Electron and JavaScript apps: static mapping of entry points, modules, IPC channels, preload scripts, and source maps, without executing anything
Websites: passive observation of a browser you already control, over a local Chrome DevTools endpoint
.NET (managed PE/CLI): execution-free triage of metadata, members, and native boundaries
Version diffs: compare two releases of an app and get a report of what changed

Getting started

Requirements

macOS 12+, or Ubuntu 24.04+, Fedora 41+, or 64-bit Arch Linux (Windows x64 is experimental and Ghidra-only)
Node.js 22.19+ or 24.11+
A deep-analysis provider: Hopper (setup can install it, and the free demo mode works) or your own Ghidra 12.1.2 with JDK 21

Install and run setup

The quickest path:

npx --yes rea-agents@latest setup

Or install the CLI globally:

npm install --global rea-agents
rea setup

Setup is careful. It detects which agents you have installed, asks which capabilities you want, shows the exact files it will change, and defaults to "No" before applying anything. Use rea setup --dry-run if you want to preview the plan first.

When setup finishes, restart your agent so it picks up the new MCP server.

Check your environment

rea doctor

This tells you whether something is missing, misconfigured, or unsupported on your machine.

Try it from the terminal

rea analyze /Applications/Notes.app
rea search /Applications/Notes.app "offline"
rea trace /Applications/Notes.app "offline"

Or just ask your agent

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

Manual MCP configuration

If your agent supports local MCP servers but is not auto-detected, add this to its config:

{
  "mcpServers": {
    "rea": {
      "command": "npx",
      "args": ["-y", "rea-agents@3.1.0", "mcp"]
    }
  }
}

Pin to the latest published version from npm.

Safety and permissions

Reverse-engineering tools can be risky if they run code you do not trust. REA leans heavily toward caution:

Dynamic features (process capture, browser observation, runtime inspection) are disabled by default and need explicit environment variables plus per-call approval.
File-based evidence commands only work inside directories you approve, using variables like REA_EVIDENCE_ROOTS_JSON.
Static JavaScript analysis parses code without running it.
REA never calls sudo, and it uses authenticated local sockets for provider communication.

The flip side: providers and launched targets still run with your user permissions. REA is not a security sandbox, so do not treat it as one when handling malware.

Is it worth a try?

Yes, if:

You are on macOS or Linux and already use an MCP-capable agent like Claude Code or Cursor.
You want to understand how a feature works in an app you use, especially a native or Electron app.
You are curious about reverse engineering but never had time to learn Hopper or Ghidra.
You need to document an undocumented file format, protocol, or interface for interoperability.
You maintain software and want to diff behavior across versions.

Maybe hold off if:

You are on Windows. Support there is experimental and limited.
You want a quick, zero-config tool. REA has a lot of opt-in switches and environment variables, which is good for safety but takes time to learn.

A few practical notes:

Hopper is separate commercial software. The demo mode works, but has vendor-defined limits.
Deep investigations can use a lot of agent tokens, so watch your model costs.
Respect the law and the software license. Reverse engineering for learning and interoperability is common, but some license agreements and jurisdictions restrict it. Recreate ideas and behavior, not copyrighted code or assets.

Summary

REA turns reverse engineering from a specialist skill into something you can delegate to your coding agent. You describe the feature, the agent investigates the app, shows you how it reached its conclusions, and then helps you build your own version.

GitHub: github.com/morluto/rea

DEV Community: ArshTechPro

OpenMausBot: A Local-First, Open-Source Team of AI Agents in a Chat App

What is OpenMausBot?

Why developers might care

Architecture in two minutes

Get it running

Option 1: Download a release

Option 2: Run from the terminal with npm

Option 3: Build from source

Optional credentials

Features worth knowing about

Automate it: webhooks, CLI, and MCP

Webhook triggers

Headless CLI for scripts and CI

MCP server

Extending it

Security mindset

Where to go next

NVKE: Run Your Own Managed GPU Kubernetes Service on Bare Metal

The short version

Who this is for

How it is structured

What NVKE does for you

Try it without GPU hardware

Install it on real infrastructure

Build from source

What developers should know before starting

1. It is a preview, so expect change

2. API authentication is off by default

3. The management cluster does not look after itself

4. FDE node images are for evaluation only

5. NICo is the only infrastructure provider

6. Some lifecycle steps are manual

A sensible path for a first evaluation

Where to find the docs

Closing up

LZ4 Explained for Developers - The Compression Library Built for Speed

What is LZ4?

The numbers

Getting started

Install

Command line

C API

Python

Other languages

What developers really need to know

1. Block format vs frame format

2. Always use the safe decompressor

3. Compression level does not slow down decompression

4. Small data needs a dictionary

5. Multithreading arrived in v1.10

6. Do not compress data that is already compressed

7. Check your bindings for security updates

Where LZ4 is used in the real world

Comparison with other tools

Free and open source

Paid and commercial options

Wrapping up

Further reading

T3 Code: A Free, Open-Source Control Panel for Claude Code, Codex and Other Coding Agents

TL;DR

What T3 Code actually is

Why developers are paying attention

Getting started

Step 1: Install and log in to at least one agent CLI

Step 2: Install T3 Code

Step 3: Change the default permission mode

Step 4: Open a project and start a thread

Permission modes: the setting that matters most

Remote access in practice

Letting other agents drive T3 Code (MCP)

What to know before you adopt it

How T3 Code compares to other tools

Orchestrators and agent managers

AI editors and first-party agent apps

Which one should you pick?

Wrapping up

Maestro Deep Dive: Testing a SwiftUI App End to End

Prerequisites

Part A: The sample app

`TodoDemoApp.swift`

`LoginView.swift`

`TodoListView.swift`

`config.yaml`: the workspace configuration

Sub-flow 1: `login.yaml`

Sub-flow 2: `dismiss_permission_dialog.yaml`

Test 1: `01_login_invalid.yaml`

Test 2: `02_login_success.yaml`

Test 3: `03_add_and_complete_tasks.yaml`

Test 4: `04_delete_task.yaml` (loops, JavaScript and swipes)

Test 5: `05_session_and_logout.yaml`

The headline: a JSON project format (`.xcproj`)