DEV Community: ArshTechPro

Goodbye pbxproj: A Friendly Guide to Xcode 27.2's New JSON Project Format

ArshTechPro — Thu, 24 Sep 2026 16:08:54 +0000

If you've built iOS apps on a team, you know this moment. You pull main, Git says CONFLICT (content): Merge conflict in project.pbxproj, and you open a wall of 24-character hex IDs.

Xcode 27.2 finally changes that. Here's what's new, explained without jargon.

TL;DR

Xcode 27.2 replaces the old project.pbxproj property list with a new JSON-based project.xcproj file.
New projects use the new format by default. Existing projects are not converted automatically, and both formats work side by side.
Xcode 27.0 and 27.2 can both open a JSON project. Xcode 26 cannot.
Diffs get smaller, merge conflicts become rare, and you can read the file without special knowledge.
Check your tools (CocoaPods, fastlane, scripts) before you switch.

First, what is an `.xcodeproj`?

MyApp.xcodeproj looks like a file, but it is a folder. Right-click it and choose Show Package Contents to see what's inside:

MyApp.xcodeproj/
├── project.pbxproj      <- the old project description
├── project.xcworkspace/
├── xcshareddata/        <- shared schemes, Package.resolved
└── xcuserdata/          <- your personal UI state

Only one file changes in 27.2. project.xcproj replaces project.pbxproj. Nothing else in the bundle changes, so schemes, Package.resolved, and xcuserdata stay the same.

Why the old format hurt

project.pbxproj uses an old NeXTSTEP-era plist syntax. It stores your project as one large flat list of objects, and every object points to the others by random hex IDs.

To add a single Swift file, Xcode has to write it in four places:

A PBXFileReference so the file exists
A PBXBuildFile so it gets compiled
An entry in a PBXGroup so it shows in the navigator
An entry in the PBXSourcesBuildPhase so it reaches the target

Xcode generates both IDs fresh, so a teammate who adds a different file on their branch writes different IDs into the same four places. That's where the classic merge conflict comes from.

Build settings had the same problem. Each configuration (Debug, Release) kept its own full copy of the settings, so changing the deployment target meant editing two places.

What the new file looks like

Here's a small example app in the new format:

{
  "default-configuration": "Debug",
  "configurations": ["Debug", "Release",],
  "files": [
    {
      "kind": "group",
      "path": "Sources",
      "children": [
        { "path": "WeatherApp.swift",  "target-membership": ["Weather/compile-sources"] },
        { "path": "ForecastView.swift", "target-membership": ["Weather/compile-sources"] },
      ],
    },
  ],
  "targets": [
    {
      "name": "Weather",
      "id": "...",
      "product-type": "application",
      "build-phases": ["compile-sources",],
      "build-settings": {
        "PRODUCT_BUNDLE_IDENTIFIER": "com.example.weather",
        "SWIFT_VERSION": "6.0",
      },
    },
  ],
  "build-settings": {
    "IPHONEOS_DEPLOYMENT_TARGET": "27.0",
    "SWIFT_OPTIMIZATION_LEVEL[config=Debug]": "-Onone",
    "SWIFT_OPTIMIZATION_LEVEL[config=Release]": "-O",
  },
}

You can probably read it without any explanation. Let's go through the three main ideas.

1. It's a tree, not a flat list

The file follows the structure you see in Xcode's UI. Instead of one big objects table, it is split into sections like files, targets, and build-settings, so a diff looks like what you actually did in the interface.

2. Files say which target they belong to

This is the most important change. In the old format, the target kept a list of its files. In the new format, each file lists its targets:

{ "path": "ForecastView.swift", "target-membership": ["Weather/compile-sources"] }

Read Weather/compile-sources as "compile this file in the Weather target." It combines the target name with the build phase, and no UUID is involved. Adding a file is now one line in one place.

If you need more detail, the entry becomes an object. For example, marking a header as public is done right there on the file, instead of inside PBXBuildFile.settings.ATTRIBUTES.

3. Build settings are written once

A setting that's the same in every configuration now appears once. When Debug and Release differ, the key carries a condition:

"SWIFT_OPTIMIZATION_LEVEL[config=Debug]": "-Onone",
"SWIFT_OPTIMIZATION_LEVEL[config=Release]": "-O",

If you've used .xcconfig files, this [config=...] syntax will look familiar. In one real migration, 161 lines of XCBuildConfiguration shrank to a single build-settings block, and the whole file went from 300 lines of property list to 123 lines of JSON.

Bonus: IDs are mostly gone

IDs are only assigned where they're needed, meaning targets and build products. Everything else is referenced by name or path.

Gotcha: it's "JSON", but with trailing commas

You might have noticed the trailing commas in the examples above. That's intentional. The format allows trailing commas, so a plain JSON.parse can't read it as-is. Apple's open-source library uses JSON5 encoding for this. If you're writing a script, use a JSON5-tolerant parser or Apple's library (see below) instead of jq or JSON.parse.

How to switch an existing project

In Xcode

Select the project at the top of the Project navigator.
Open the File inspector (Option-Command-1).
Under Project Document, set Project Format to JSON.
Confirm the dialog.

project.pbxproj is deleted and project.xcproj takes its place. Commit the change as its own commit, with no other edits, so it's easy to review and revert.

From the command line

This is handy for CI or for converting many projects at once:

xcodebuild -project MyApp.xcodeproj -convert-project "Xcode Project"

This command converts the project, and it does the same thing as choosing JSON in the File inspector.

New tooling: `xcprojformatter` and an open-source library

Apple published the format openly. xcode-project-format is a Swift library for reading, writing, and manipulating the project.xcproj format, so tools like generators, linters, and validators don't each have to reverse-engineer it.

Reading a project takes a few lines:

import XcodeProjectFormat

let data = try Data(contentsOf: projectURL)
let project = try XCSchema.Project(jsonRepresentation: data)
for target in project.targets {
    print(target.name)
}

Xcode 27.2 also includes xcprojformatter in /usr/bin. It validates and reformats files that already use xcproj. It is not a converter from pbxproj. For CI, think of it as swift-format for your project file. Run xcprojformatter --help to see its options, and consider adding a check to CI so hand edits (from people or AI agents) stay in canonical form.

What about Tuist, XcodeGen, CocoaPods, fastlane?

This is the main reason to wait before switching.

Anything that parses project.pbxproj directly needs an update. That includes CocoaPods through the xcodeproj gem, fastlane actions that bump versions or change settings, project generators, and custom scripts. As of the 27.2 release, support is still rolling out.
The Swift XcodeProj library already has experimental support. Version 9.17.0 added it on September 17, 2026. Its maintainers say to expect details to change and to check a converted project before committing it.
Some tools don't support it yet. For example, Capacitor has an open issue because cap sync ios only parses .pbxproj.
Generators keep working. Tuist, XcodeGen, Bazel, SwiftPM, and xcconfig-based workflows continue to work unchanged and can adopt the new format at their own pace.

Why now? (Hint: AI agents)

Apple filed its announcement under Coding Intelligence. Apple says directly that the new format makes it easier for coding agents to work with Xcode projects. When an agent (or a human) can change one setting by editing one readable line, instead of updating several ID cross-references, there are far fewer ways to break the project.

Should you switch?

Your situation	Recommendation
Solo dev or small team, everyone on Xcode 27	Switch now
Hand-maintained `.xcodeproj` with frequent conflicts	Switch, since you gain the most
Someone on the team still uses Xcode 26	Wait
CocoaPods, fastlane project edits, or custom pbxproj scripts	Check each tool first
You generate projects with Tuist or XcodeGen	Nothing urgent, since your manifest is the source of truth

Summary

project.xcproj isn't a new build system or a Swift manifest. It's the same project model written in a form people can actually read. Adding a file is one line, a setting is one line, and a merge conflict becomes something you can resolve by reading it.

Further reading

Apple: Updating your Xcode project configuration file format

Orca: The Agent Development Environment for Running AI Coding Agents in Parallel

ArshTechPro — Sun, 20 Sep 2026 06:00:36 +0000

If you use Claude Code, Codex, or another AI coding agent in your terminal, you have probably hit this wall: the agent is busy on one task, you want to start a second one, and now you are juggling branches, stashing changes, and opening five terminal windows that all look the same.

Orca is a desktop app built to solve exactly that. This article explains what it is, how it differs from Cursor, what it costs, and where it falls short.

What is Orca?

Orca calls itself an ADE, an Agent Development Environment. The idea is simple:

A traditional IDE is built around one human typing code.
An ADE is built around you supervising several AI agents that write code at the same time.

In practice, Orca is a desktop app (macOS, Windows, Linux) where every task you start gets:

Its own git worktree (an isolated copy of your repo on its own branch)
Its own agent terminal (Claude Code, Codex, Gemini, Cursor CLI, and so on)
Its own browser tab for previewing the app

A quick primer on git worktrees

Worktrees are the core idea behind Orca, so it is worth a 30-second refresher.

Normally, one repo folder has one checked-out branch. A worktree lets you check out another branch into a separate folder that shares the same git history:

git worktree add ../fix-login-race -b fix-login-race

Now you have two folders, two branches, one repo. No stashing needed.

Orca automates this. Click "+", name your task, pick an agent, and Orca creates a real git worktree and launches the agent inside it. Because these are standard worktrees, you can always cd into one and use plain git.

What does a typical workflow look like?

The Orca docs describe a "first 3-agent session" that sums up the whole product:

Add a repo. Point Orca at a local checkout. It uses your default branch (for example origin/main) as the base for new worktrees.
Create a worktree. Give the task a name like fix-login-race.
Pick an agent. Choose Claude Code, Codex, Cursor CLI, or another supported agent. Orca launches its CLI in the right directory.
Race agents. Repeat twice more with different agents and paste the same prompt into each:
- fix-login-race with Claude Code
- fix-login-race-2 with Codex
- fix-login-race-3 with Cursor CLI
Split panes so you can watch all three working at once.
Review and ship. Open each diff, leave inline comments to send back to the best agent, then commit and push from inside Orca. Delete the losing worktrees in one click.

That loop (add, worktree, agent, split, diff, ship) is essentially the whole product. Everything else is a deeper version of one of those steps.

Key features

Parallel worktrees. Every task is isolated, so five agents can work on the same repo without overwriting each other.

Bring your own agent. Orca ships preconfigured for a long list of CLI agents, including Claude Code, Codex, Gemini, Cursor CLI, GitHub Copilot, OpenCode, Amp, Goose, Cline, Kiro, and Qwen Code, and any other CLI agent can be added.

Annotate AI diffs. Leave markdown comments on specific diff lines, batch them, and send them back to the agent as feedback. You can also inspect CI, resolve conflicts, and open PRs in the app.

Design Mode. Each worktree gets a real Chromium window. Click a UI element and Orca sends its HTML, CSS, and a cropped screenshot to your agent. Useful for "fix this button" style front-end work.

Terminal. GPU-rendered, with unlimited splits, scrollback that survives restarts, and scrollback search. On first launch it can import your Ghostty settings.

Editor. It includes a VS Code-style (Monaco) editor with autosave, so you can make manual edits without leaving the app.

SSH worktrees. Run agents on a powerful remote machine with full file editing, git, and terminals, plus auto-reconnect and port forwarding.

GitHub, Linear, and Jira integration. Browse PRs and issues, open a worktree straight from a task, and review PRs without switching apps.

Orca CLI. Agents can drive Orca too, for example creating worktrees themselves, which enables orchestration and scheduled automations.

Usage tracking. See Claude and Codex usage and rate-limit reset times, and swap between Codex accounts.

Mobile companion. iOS and Android apps let you check agent status, get notifications, and keep terminal work moving when you are away from your desk.

Is Orca like Cursor?

Short answer: they overlap, but they solve different problems.

Cursor is an AI-first code editor (a fork of VS Code). The AI lives inside the editor: autocomplete as you type, chat in a sidebar, and an agent mode. You are the main author, and the AI assists you in one workspace. You pay Cursor for access to the models.

Orca is an orchestration layer for CLI agents. It does not provide its own model. Instead, it runs the agents you already have (including Cursor's own CLI agent) side by side, each in its own isolated branch, and gives you tools to review and merge their output.

	Orca	Cursor
Core idea	Manage many agents in parallel	AI-assisted editor
Built on	Desktop app wrapping CLI agents, terminals, browser, editor	Fork of VS Code
AI models	Bring your own (Claude Code, Codex, Gemini, etc.)	Cursor's subscription and models
Parallel agents	First-class, one worktree per task	Supported, but not the main workflow
Inline autocomplete while you type	Not a headline feature	Yes, a core feature
Open source	Yes, MIT	No
Platforms	macOS, Windows, Linux	macOS, Windows, Linux
Price of the tool itself	Free	Free tier plus paid plans

A useful way to think about it:

If you mostly write code yourself and want AI help as you type, Cursor (or a similar AI editor) is the more natural fit.
If you mostly delegate tasks to agents and your job is increasingly to review, compare, and merge their output, Orca is designed for that.

Pricing: is Orca free?

Yes. The Orca app is free and open source under the MIT license. There is no paid tier listed on the website.

There are two things to be aware of:

You pay for the agents. Orca is not a model. You need your own Claude, Codex, Gemini, or other subscription or API key. Running three agents in parallel can use your quota roughly three times as fast.
Enterprise is "contact us." There is an Enterprise page covering security reviews, self-hosting, rollout help, and SOC 2 readiness, but no public pricing. You have to email the team.

Installing Orca

Download builds for each platform from the download page or GitHub Releases. On macOS you can also use Homebrew:

brew install --cask stablyai/orca/orca

A few notes:

On first launch, Orca offers to import your ~/.claude, ~/.codex, and Ghostty settings.
On Linux, pick the AppImage if you want automatic updates. The CLI is named orca-ide so it does not clash with the GNOME Orca screen reader.
The app auto-updates on a stable channel, with optional release-candidate builds for early features.

Who should try Orca?

Orca is worth a look if:

You already use one or more CLI coding agents and feel limited by running one task at a time.
You want to compare how different agents handle the same bug.
You want a Claude Code or Codex workflow on Windows or Linux with a proper UI around it.
You like running agents on a remote machine and checking on them from your phone.

You can probably skip it if you rarely use agents, prefer AI autocomplete while you type, or want a single all-in-one subscription that handles the models for you.

Links

GitHub: https://github.com/stablyai/orca

Worktrunk: Git Worktrees Made Simple for Parallel AI Agents

ArshTechPro — Sat, 19 Sep 2026 21:08:11 +0000

AI coding agents like Claude Code and Codex can now work on longer tasks without supervision. That means you can realistically run several of them at once, each on a different feature or bug.

The catch: if they all work in the same folder, they overwrite each other's changes. Git has a built-in answer for this called worktrees. A worktree is a separate working directory attached to the same repository, so each branch can live in its own folder at the same time.

The problem is that git's worktree commands are clunky. Just starting a new one looks like this:

git worktree add -b feat ../repo.feat
cd ../repo.feat

You type the branch name three times. Cleaning up afterward takes another three commands. Do this ten times a day and it gets old fast.

What Worktrunk is

Worktrunk is a command-line tool, written in Rust, that makes worktrees as easy to use as regular branches. You refer to everything by branch name, and Worktrunk works out the folder paths for you.

It's open source (MIT or Apache-2.0), was released at the start of 2026, and already has over 5k stars on GitHub.

The core commands

Here's how Worktrunk compares with plain git:

Task	Worktrunk	Plain git
Switch to a worktree	`wt switch feat`	`cd ../repo.feat`
Create and start an agent	`wt switch -c -x claude feat`	`git worktree add -b feat ../repo.feat && cd ../repo.feat && claude`
Clean up	`wt remove`	`cd ../repo && git worktree remove ../repo.feat && git branch -d feat`
List with status	`wt list`	`git worktree list` (paths only)

Four commands cover most of what you'll do day to day.

Getting started

Install with Homebrew (macOS and Linux):

brew install worktrunk && wt config shell install

Or with Cargo:

cargo install worktrunk && wt config shell install

The wt config shell install step matters. It adds shell integration so wt can actually change your current directory.

Create a worktree for a new feature:

wt switch --create feature-auth

This creates the branch and the worktree, then moves you into it. Check all your worktrees and their status with:

wt list

When you're done, you can open a PR as usual and run wt remove after it merges. Or merge locally with one command:

wt merge main

That commits your changes, rebases onto main, merges, and removes the worktree and branch.

Running agents in parallel

This is where Worktrunk shines. Start three agents on three tasks, each in its own isolated worktree:

wt switch -x claude -c feature-a -- 'Add user authentication'
wt switch -x claude -c feature-b -- 'Fix the pagination bug'
wt switch -x claude -c feature-c -- 'Write tests for the API'

The -x flag runs a command after switching, and everything after -- is passed to that command. No agent touches another agent's files.

Extras worth knowing

Beyond the basics, Worktrunk includes:

Hooks that run commands when a worktree is created or merged, such as installing dependencies or starting a dev server.
LLM-generated commit messages based on your diff.
Build cache copying so a new worktree can reuse node_modules/ or target/ instead of starting cold.
PR checkout with wt switch pr:123.
A unique port per worktree so multiple dev servers can run side by side.

Is it worth a try?

Yes, if you:

Run more than one AI coding agent at a time.
Juggle several branches and hate stashing or re-cloning.
Already use git worktrees and are tired of the long commands.

A few honest caveats. It's a young project, so expect frequent releases and occasional changes. Every worktree is a full copy of your working files, so large repos use more disk space (the cache-copying feature helps, but doesn't remove this). On Windows, wt clashes with the Windows Terminal command, so it installs as git-wt instead unless you disable that alias. And if you only ever work on one branch at a time, plain git switch is all you need.

If parallel agents are part of your workflow, Worktrunk removes most of the friction of worktrees. Install it, spin up two worktrees, and you'll know within ten minutes whether it sticks.

Docling: Turn Messy Documents into Clean Data for Your AI App

ArshTechPro — Sat, 19 Sep 2026 20:57:15 +0000

The problem

If you've built anything with LLMs, you've hit this wall: your data lives in PDFs, Word files, slide decks, and scanned images. You need clean text to feed a model or a RAG pipeline. Basic PDF-to-text tools give you a jumbled mess: tables collapse into random lines, two-column layouts get read in the wrong order, and headers mix with body text.

Docling is an open-source Python library built to solve exactly that.

What Docling is

Docling reads documents and converts them into structured output such as Markdown, HTML, or JSON. It was started by IBM Research Zurich, is now hosted by the LF AI & Data Foundation, and is MIT licensed. It has over 66k stars on GitHub, so it's far from a side project.

What sets it apart from a plain text extractor is that it tries to understand the page. It detects layout and reading order, rebuilds tables, and recognizes code blocks, formulas, and images.

What it supports

Input formats include PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, LaTeX, email files, and even audio and video (transcribed with speech recognition models). Scanned PDFs are handled with OCR.

Everything is converted into one internal format called DoclingDocument, which you can then export as Markdown, HTML, or lossless JSON. That means your downstream code deals with one structure no matter what the input was.

Getting started

You need Python 3.10 or newer.

pip install docling

Convert a document from the command line:

docling https://arxiv.org/pdf/2206.01062

This writes a .md file to your current directory.

Or use it from Python:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("https://arxiv.org/pdf/2408.09869")
print(result.document.export_to_markdown())

That's it. Local file paths work the same way as URLs.

Where it fits in your stack

Docling has ready-made integrations with LangChain, LlamaIndex, CrewAI, and Haystack, so you can drop it into an existing RAG pipeline as the document loader. It also ships an MCP server for connecting it to AI agents, and an API server (docling-serve) if you'd rather run it as a service than import it as a library.

It runs fully locally, which matters if you're handling sensitive documents or working in an air-gapped environment. No data has to leave your machine.

Is it worth a try?

Yes, if any of these describe you:

You're building a RAG system or chatbot over real-world documents.
You have PDFs with tables that other tools mangle.
You need to process many file types without writing a separate parser for each.
You can't send documents to a third-party API.

A few honest caveats. Docling uses machine learning models for layout and table detection, so the install is heavier than a lightweight library like pypdf, and models are downloaded on first run. Processing large PDF batches on CPU can be slow, and a GPU helps a lot. If all you need is raw text from simple, single-column PDFs, a lighter tool will do the job with less overhead.

Open Source Alternative to Claude Code and Cursor: Meet Cline

ArshTechPro — Thu, 17 Sep 2026 08:18:39 +0000

Cline is an open source, autonomous coding agent. Instead of just autocompleting the line you're typing, Cline can read your entire project, plan out a set of changes, edit multiple files, run terminal commands, and check its own work against linter and compiler errors, all with you reviewing and approving each step.

It started as a VS Code extension (previously known as "Claude Dev"), but it has grown into something bigger. Today, Cline ships as four things built on the same underlying engine:

VS Code Extension — the original, most widely used form. Install it from the VS Code Marketplace and it sits right in your editor.
JetBrains Plugin — the same experience inside IntelliJ IDEA, PyCharm, WebStorm, GoLand, and the rest of the JetBrains family.
CLI — run Cline directly in your terminal, either as an interactive chat or fully headless for scripts and CI/CD pipelines.
SDK — a Node.js package (@cline/sdk) for developers who want to build their own agents, custom tools, or integrations on top of Cline's engine.

It's licensed under Apache 2.0, and as of this writing has over 67,000 stars and more than 7,000 forks on GitHub, so it has real traction, not just a novelty project.

What Can It Actually Do?

Here's a breakdown of the core capabilities, in plain terms.

It edits code across your whole project

Cline doesn't just look at the file you have open. It reads your project structure, figures out how files relate to each other, and makes coordinated edits across the codebase. While it works, it watches for linter and compiler errors and tries to fix problems like missing imports or type mismatches before you even notice them. Every edit shows up as a reviewable diff, and changes are tracked with checkpoints so you can undo the agent's work if something goes wrong.

It runs terminal commands

Cline can execute commands directly: installing packages, running build scripts, executing tests, deploying, managing databases. For long-running processes like a dev server, it keeps watching the output in the background and reacts to new errors or crashes as they appear.

Plan mode and Act mode

This is one of Cline's more distinctive features. In Plan mode, Cline explores your code, asks clarifying questions, and proposes a strategy before touching anything. Once you're happy with the plan, you switch to Act mode and it executes. By default, every file edit and command needs your approval — though you can flip on auto-approve if you want it to run more autonomously.

Custom rules and skills

You can define project-specific rules in .clinerules files: coding standards, architecture conventions, deployment steps, testing requirements. These are picked up automatically across the CLI, VS Code extension, and JetBrains plugin, so the agent behaves consistently with your team's conventions rather than guessing.

You're not locked into one AI model

This is a big differentiator. Cline doesn't force you onto a single provider. You can plug in:

Anthropic (Claude Opus, Sonnet, Haiku)
OpenAI (GPT series)
Google (Gemini series)
OpenRouter (200+ models)
AWS Bedrock, Azure, GCP Vertex
Cerebras, Groq (fast inference)
Ollama or LM Studio for local models
Any OpenAI-compatible endpoint

You bring your own API key, and you decide what you're paying for and which model fits the task.

Extensibility: plugins and MCP servers

Using the SDK, you can register custom tools and lifecycle hooks for logging, auditing, policy enforcement, or domain-specific capabilities. Cline also supports MCP (Model Context Protocol) servers, so it can connect to databases, call APIs, manage cloud infrastructure, or use community-built tools. You can even ask Cline to write a new custom tool on the fly.

Multi-agent teams and scheduled agents

Newer additions let you coordinate multiple agents on a single task, with a coordinator agent delegating subtasks to specialists, and state persisting across sessions. You can also schedule agents to run on a cron schedule for recurring work like daily PR summaries or weekly dependency checks.

Chat with it from Slack, Telegram, Discord, and more

Cline can connect to messaging platforms so you can hand it tasks from Slack, Telegram, Discord, Google Chat, WhatsApp, or Linear, with each conversation thread mapped to a full agent session.

Headless mode for CI/CD

For automation, Cline can run with zero interaction: pipe input in, get JSON output back, and chain it into scripts or pipelines. For example:

cline "Run tests and fix any failures"
git diff origin/main | cline "Review these changes for issues"

How Do You Get Started?

For the CLI:

npm i -g cline

For the editor experience, install the VS Code extension or the JetBrains plugin, then connect your API key from whichever model provider you want to use.

Is It Worth Trying?

Short answer: yes, especially if any of the following sound like you.

Try Cline if:

You want an agent that can make autonomous, multi-file changes across a real codebase, not just single-line suggestions.
You want to choose your own model and control your own costs, rather than being locked into one vendor's bundled pricing.
You already live in VS Code or a JetBrains IDE and don't want to switch to a different editor entirely.
You want to inspect, extend, or audit the tool itself, since it's fully open source under Apache 2.0.
You want the same agent core available as a CLI for scripting, a plugin for your editor, and an SDK for building your own tools.

Think twice, or pair it with something else, if:

You want a fully polished, all-in-one AI-native editor experience. Tools like Cursor offer a more integrated, purpose-built interface with fast inline completions, and many developers report an easier on-ramp for beginners.
You'd rather pay a flat monthly fee and not think about token costs. Cline's "bring your own key" model means your spend depends on which model you use and how much you run it, and heavy usage can add up.
You want something with zero setup. Cline requires you to get an API key from a provider and configure it, which is a small extra step compared to tools with built-in, bundled access.

How It Compares to Other Agents

It's worth being clear-eyed about where Cline sits in the current landscape:

Cline vs Cursor: Cursor is a standalone, AI-native editor (a VS Code fork) with a bundled model and a smoother out-of-the-box experience. Cline is a VS Code/JetBrains extension plus CLI and SDK, open source, and model-agnostic. Many developers actually run both: Cursor for fast in-editor completions, an agent like Cline or Claude Code for larger autonomous, multi-file work.
Cline vs Claude Code: Claude Code is Anthropic's own terminal-first agent, tightly built around Claude models. Cline offers a similar terminal and autonomous-agent experience but lets you swap in any model provider, and it also gives you a full IDE extension and SDK, which Claude Code doesn't offer in the same way.

Neither of these makes Cline "better" or "worse" outright. It's a different set of trade-offs: openness and model flexibility versus the tighter polish of a closed, single-vendor product.

Repository: github.com/cline/cline

BrewUI: A First Look at Homebrew's Official macOS GUI

ArshTechPro — Wed, 16 Sep 2026 13:44:53 +0000

If you use a Mac for development, you almost certainly have Homebrew installed. You type brew install something, wait a few seconds, and move on with your day.

But not everyone who needs Homebrew is comfortable in a terminal. Designers, data folks, students, and plenty of developers early in their careers often get told "just install it with brew" and then get stuck.

The Homebrew team is working on an answer to that: BrewUI, an official, native macOS app for managing Homebrew packages. The project lives at github.com/Homebrew/BrewUI.

This article walks through what BrewUI is, the ideas behind it, and how its architecture works, in plain terms.

Heads up: BrewUI is in early development. The team describes the current phase as building the app foundation. Treat everything here as a look at a project in progress, not a finished product you can download today.

What is BrewUI?

BrewUI is a graphical front end for Homebrew. Instead of typing commands, you can search for packages, install them, update them, and remove them through a regular Mac app window.

The key word is official. There have been third-party Homebrew GUIs over the years, but this one is maintained under the Homebrew organization itself.

The stated goal is to let people who avoid the command line safely discover and manage packages, without the app ever hiding what Homebrew is actually doing.

The core idea: transparency

Most GUIs wrap a tool and try to make you forget the tool exists. BrewUI takes the opposite approach.

The design rules say the app should always show the exact command it is running. If you click "Install" on a package, you should be able to see the real brew command behind that button, along with its output.

Homebrew stays the source of truth

BrewUI does not reimplement Homebrew or reach into its internals. It gets data in two ways:

The brew command line tool, run as a subprocess (the same way you would run it yourself).
The Homebrew JSON API at formulae.brew.sh, which provides package metadata.

It also does not bundle Homebrew. If Homebrew is not installed, the app is meant to detect that and degrade gracefully rather than crash. To find brew, it checks the two standard locations:

/opt/homebrew/bin/brew   # Apple Silicon
/usr/local/bin/brew      # Intel

This keeps the app simple: Homebrew does the real work, and BrewUI presents it.

Tech stack at a glance

Area	Choice
Language	Swift 6.0 with strict concurrency
UI	SwiftUI (AppKit only when SwiftUI cannot do the job)
State	`@Observable`
Concurrency	`async`/`await`, actors for shared mutable state
Dependencies	Swift Package Manager
Platform	macOS only, with macOS Tahoe 26 as the main target
License	AGPL-3.0

If you have been meaning to see what a modern, "all in" Swift 6 macOS project looks like, this repository is a good real-world example.

How the architecture works

Here is the part that is most interesting for developers. BrewUI follows a layered design. A user action flows down through the layers like this:

View  ->  ViewModel  ->  Repository or Interactor  ->  Service  ->  brew CLI / JSON API

Let's break that down with a simple example: showing a list of installed packages and letting you upgrade one.

Views

SwiftUI views are kept thin. They display state and forward user actions. A view knows that a button was tapped; it does not know how to upgrade a package.

ViewModels

The ViewModel holds presentation state, such as "is this list loading?" or "what text should this label show?". It turns domain data into something the UI can display, and passes real work further down.

Repositories

A Repository is about reading data from a source. For example, getting the list of installed packages from brew list output, or package details from the JSON API.

The benefit: the rest of the app does not care where the data came from. You could swap in a mock repository for tests and nothing above it would change.

Interactors

An Interactor represents one specific use case, such as running brew doctor. It is not a generic "fetch everything" layer; it is a single, focused action.

Services

Services are the infrastructure at the edge of the app: actually launching the brew process, making HTTP requests, and so on.

Models

Plain domain types (like a package) shared across layers. They intentionally stay free of UI details, so the same model works for a list row, a detail page, or a test.

If you know MVVM and Clean Architecture, this will feel familiar. The project describes it as a lightweight MVVM with a coordinator style, guided by Clean Architecture ideas, and it explicitly prefers the smallest pattern that solves the current problem rather than building everything up front.

The command center: why brew commands run one at a time

One detail worth calling out is the command center, an actor named BrewCommandCenter.

Homebrew does not like it when you run multiple commands that change your system at the same time. Picture a user clicking "Upgrade" on three packages in quick succession. In a terminal you would naturally run them one after another. A GUI needs to enforce that on your behalf.

The command center:

Serializes any command that changes the system, so they run in order.
Tracks the state of each operation (in progress, failed, and so on), so every part of the UI can show accurate status.
Runs small, dedicated command types for each mutating action.

Reading data, like parsing brew list or brew info, is not its job. That stays in the repositories. This separation keeps "things that change your machine" in one controlled place.

Using a Swift actor here is a nice fit: actors guarantee only one task touches their state at a time, which is exactly the property you want.

Designing for tools that change

BrewUI depends on two things it does not control: the text output of brew and the shape of the JSON API. Both can change between Homebrew releases.

The project handles that with a defensive mindset:

CLI output is treated as unstable. Parsers are expected to be tolerant and have fallbacks.
JSON decoding is resilient. Unknown or missing fields should never crash the app.
Commands are async and cancellable, with output streamed or preserved for logs.

This is good advice for any app that wraps a command line tool, not just this one.

Check it out here: github.com/Homebrew/BrewUI

What 100+ Leaked System Prompts Teach You About Prompt Engineering

ArshTechPro — Tue, 15 Sep 2026 22:39:31 +0000

Every time you open ChatGPT, Claude, Gemini, or an AI coding tool like Cursor, the model has already read a long set of instructions before your first message arrives. You never see those instructions, but they shape almost everything about how the assistant behaves: its tone, its formatting habits, which tools it reaches for, and what it refuses to do.

The GitHub repository asgeirtj/system_prompts_leaks collects those hidden instructions in one place.

This article explains what the repo is, how it is organized, and, most importantly, what you as a developer can take away from it.

First, what is a system prompt?

If you have used an LLM API, you have already written one. A chat request is usually split into roles. The system message sets the rules, and the user messages are the conversation.

Here is a minimal example using the OpenAI-style message format:

const messages = [
  {
    role: "system",
    content: "You are a support bot for Acme Inc. Answer only questions about Acme products. Keep answers under 100 words."
  },
  {
    role: "user",
    content: "How do I reset my password?"
  }
];

The end user only sees the second message and the reply. The first message is invisible to them, but it steers the whole response.

Commercial products do exactly the same thing, just at a much bigger scale. Instead of two sentences, their system prompts can run to thousands of words covering personality, formatting rules, tool definitions, safety policies, and product-specific behavior.

What the repo contains

The repo is a large, organized collection of these production system prompts, captured from real products. Each prompt is stored as a Markdown file, grouped into folders by company.

The main folders include:

Anthropic: Claude.ai chat prompts for several model versions, Claude Code (including subagents, slash commands, and injected reminders), and integrations such as Claude in Chrome, Excel, Word, and PowerPoint.
OpenAI: ChatGPT prompts across model versions, Codex (including plan mode and computer use), voice modes, memory, and older tool prompts like Canvas and the Python tool.
Google: Gemini app prompts, Gemini CLI, NotebookLM, Jules, AI Studio, and Google Search AI Mode.
xAI: Grok versions, personas, and safety instructions.
Microsoft: GitHub Copilot, the VS Code Copilot agent, and Copilot CLI.
Others: Cursor, Perplexity, Meta AI, Mistral, DeepSeek, Kimi, Qwen, Notion AI, and a "Misc" folder with tools like Warp, Zed, Docker's Gordon, Raycast, and Kagi.

There is also an interesting note in the GLM folder: the maintainer documents that GLM appears to serve no system prompt at all, which is a useful data point in itself.

The README has a "Recently Updated" table at the top, so it is easy to see which products have fresh captures. The repo is released under the CC0-1.0 license.

It has also been picked up outside the developer world. The README points to a Washington Post interactive piece (May 2026) and a data dashboard from CEPS' AI World project (July 2026), both built on files from the repo.

How are these prompts obtained?

Mostly through prompt extraction: asking the model, in one way or another, to repeat the text it was given before the conversation started. The banner image on the repo shows exactly this kind of request.

This works because a system prompt is just text sitting in the model's context window. The model can read it, so with the right phrasing it can often be convinced to write it back out.

A few caveats worth keeping in mind:

Captures are not official. These are not documents published by the vendors, so treat them as snapshots rather than a guaranteed source of truth.
Prompts change constantly. Vendors update them frequently, sometimes weekly. A file might describe last month's behavior.
Some text is dynamic. Dates, user locations, enabled tools, and feature flags are often injected at runtime, so two users can receive slightly different prompts.
Models can hallucinate. An extraction can include invented or garbled sections, which is why cross-checking multiple captures matters.

Why developers should care

You do not need to be building a chatbot to get value from this repo. Here are the practical lessons.

1. It is a free masterclass in production prompt engineering

Most prompt engineering tutorials show short, toy examples. These files show how teams with large budgets actually structure instructions that serve millions of users.

When you read through a few of them, patterns jump out:

Structure with tags or headers. Many prompts group rules into clearly labeled sections (formatting, tools, safety, product info) instead of one long paragraph. This makes them easier for the model to follow and easier for humans to maintain.
Explain the why, not only the rule. Good prompts often give a short reason behind an instruction. Models generalize better when they understand the intent.
Use examples. Prompts frequently include sample requests with good and bad responses, which is one of the most reliable ways to pin down behavior.
Be explicit about edge cases. A lot of text is spent on situations that go wrong in practice: ambiguous requests, conflicting instructions, stale information.

If your own system prompt is three lines long and your app behaves inconsistently, comparing it against these files is a quick way to see what you are missing.

2. It shows how tools and agents are wired up

The coding agent prompts (Claude Code, Codex, Copilot agent, Cursor, Gemini CLI) are especially useful if you are building agentic workflows. They show how vendors:

Describe each tool and when to use it
Tell the model to plan before acting
Handle file edits, terminal commands, and verification steps
Split work across subagents

Reading two or three of these side by side gives you a good mental model of how modern AI agents are designed, without having to reverse-engineer them yourself.

3. It explains "weird" model behavior

Ever wondered why an assistant keeps avoiding bullet points, insists on searching the web for a simple question, or refuses to reproduce song lyrics? The answer is often sitting right in the system prompt.

Knowing this helps you debug your own integrations. If you use a consumer app and the API and notice they behave differently, the system prompt is usually the reason. The API gives you a much cleaner slate.

4. It is a security lesson: your system prompt is not a secret

This is the most important takeaway. If the largest AI companies in the world cannot keep their system prompts private, your app will not be able to either.

Treat your system prompt as public by default. That means:

Do NOT put in a system prompt:
- API keys, tokens, or passwords
- Internal URLs or database connection strings
- Private customer data
- Business logic you would be embarrassed to see on GitHub

And do not rely on the prompt as your only security boundary:

// Bad: trusting the prompt to enforce access control
const systemPrompt = "Never reveal other users' orders.";

// Better: enforce it in your backend before data reaches the model
const orders = await db.orders.findMany({
  where: { userId: session.user.id } // the model never sees other users' data
});

The rule of thumb: the model should only ever have access to data the current user is already allowed to see. If a clever user extracts or bypasses the prompt, nothing sensitive should leak.

5. It helps you compare vendors

Because so many products are in one place, you can compare how different companies approach the same problem, such as how they format answers, how cautious they are, or how they describe web search. That is useful context when choosing a model or provider for your project.

How to explore it efficiently

The repo is large, so here is a practical way in:

Start with the product you use most. If you live in Cursor or Copilot, open that file first. It will immediately explain some behavior you have noticed.
Read one chat prompt and one agent prompt. For example, a ChatGPT or Claude chat prompt, then a coding agent prompt. The contrast is instructive.
Clone it and search locally. Grep across vendors to see how each one handles a topic.

git clone https://github.com/asgeirtj/system_prompts_leaks.git
cd system_prompts_leaks

# See how different products talk about tool usage
grep -ril "tool" --include="*.md" . | head -20

# Compare formatting rules across vendors
grep -ri "markdown" --include="*.md" . | less

Borrow patterns, not text. Use the structure and techniques in your own prompts, but write instructions that fit your product rather than copying a vendor's prompt wholesale.

Repo: github.com/asgeirtj/system_prompts_leaks

iPhone Duo for iOS Developers: What Actually Changes in Your Swift Code

ArshTechPro — Wed, 09 Sep 2026 21:16:11 +0000

Apple announced the iPhone Duo today — its first foldable iPhone. A 5.4-inch outer display, a 7.6-inch inner display when you open it, ships with iOS 27.x.

The marketing story is the hardware. The developer story is that a lot of assumptions baked into iPhone apps since 2007 just stopped being true. There is now more than one screen. The screen can change shape while your app is running. The safe area is no longer symmetric. And "portrait only" doesn't mean what you think it means anymore.

The good news: if you've been doing adaptive layout properly for iPad, most of this is a short afternoon. If your app hardcodes screen sizes and branches on orientation, you have some work to do.

Here's the practical version.

First: what happens if you do nothing?

Your app still runs. It doesn't crash, it doesn't get pulled. But how much of the screen you get depends on which SDK you last built against:

Built with	Inner display behavior
Older SDK (no rebuild)	Runs, but letterboxed — your app keeps its old aspect ratio, with black bars either side
iOS 27 SDK	Extends left of the status bar, avoiding the camera area
iOS 27.1 SDK	Full edge-to-edge, and standard nav/toolbar buttons lay out vertically

So step zero is genuinely just: rebuild with Xcode 27.1. That alone moves you from "obviously not updated" to "fine." Everything below is the difference between "fine" and "good."

The four poses you now have to support

This is the mental model shift. It's not portrait vs landscape anymore. It's:

Closed, portrait — behaves like a normal iPhone
Closed, landscape
Open, vertical (tall, near-square)
Open, horizontal (wide)

Plus the in-between states: partially folded like a book, or propped up in a tent on a table. Your layout has to survive all of them, and it has to survive transitions between them while state is live.

Change #1: Size classes, not orientation

This is the single most important line in Apple's guidance, and it will break the most apps.

The inner display doesn't honor your supported interface orientations. If your app branches layout on UIDevice.orientation or supportedInterfaceOrientations, that logic is now lying to you.

Use size classes instead — they describe the space you have, which is the thing you actually care about:

// SwiftUI
struct ContentView: View {
    @Environment(\.horizontalSizeClass) private var hSize
    @Environment(\.verticalSizeClass) private var vSize

    var body: some View {
        if hSize == .regular {
            WideLayout()
        } else {
            CompactLayout()
        }
    }
}

// UIKit
override func traitCollectionDidChange(_ previous: UITraitCollection?) {
    super.traitCollectionDidChange(previous)
    let isWide = traitCollection.horizontalSizeClass == .regular
    // reconfigure
}

What to expect on device:

Outer display → same size classes as any other iPhone
Inner display → regular in both dimensions, which is what leaves room for sidebars and two-column layouts

That second row is the one worth internalizing. The inner display is, as far as your layout code is concerned, iPad-shaped.

Change #2: Stop referencing the main screen

UIScreen.main is ambiguous on a two-display device, and Apple has said it's heading for deprecation. There is no longer one screen.

// ❌ Which screen? Nobody knows.
let scale = UIScreen.main.scale
let bounds = UIScreen.main.bounds

// ✅ Ask the trait collection
let scale = traitCollection.displayScale

// ✅ Or get the screen dynamically from the window scene
let screen = view.window?.windowScene?.screen

For layout size, prefer the scene's bounds or the environment over anything screen-derived. Do a project-wide search for UIScreen.main right now — it's usually a five-minute fix and it's the most likely source of weird bugs.

While you're in there, ConcentricRectangle (SwiftUI) and UICornerConfiguration (UIKit), introduced in iOS 26, will match the actual screen corner radius instead of your hardcoded cornerRadius: 12.

Change #3: Safe areas are now asymmetric

On a normal iPhone, the left and right insets match, so a lot of code does this:

// ❌ Assumes both sides are equal
let usableWidth = view.bounds.width - view.safeAreaInsets.left * 2

On iPhone Duo, safe areas and layout margins are frequently asymmetric — the camera is on one side, and in Split View your app occupies half the display with different insets on each edge. Handle each side independently:

// ✅
let usableWidth = view.bounds.inset(by: view.safeAreaInsets).width

The general rule Apple repeats: interactive foreground content stays inside the safe area; background artwork extends past it.

// SwiftUI
ZStack {
    BackgroundArtwork()
        .ignoresSafeArea()   // background: bleed
    ControlsView()           // foreground: respects safe area by default
}

Change #4: Reserved regions (the hinge and the cameras)

This is a genuinely new concept. The device has physical features that carve up the display: the hinge and the cameras. Apple calls these reserved regions, and you can query them.

Two kinds:

.division — the fold. It splits a larger area into smaller ones. It's only active when the device is actually folded; when flat it has zero width and is inactive.
.occlusion — something sitting on top of your content. This is the under-display FaceTime camera.

// SwiftUI
GeometryReader { proxy in
    let folds = proxy.reservedRegions(kind: .division)
    let frames = folds.map(\.frame)
    MyLayout(avoiding: frames)
}

// UIKit
let folds = view.reservedRegions(kind: .division)
let frames = folds.map(\.frame)

Inactive regions are excluded by default. Ask for them when you want to make a structural decision that shouldn't flip-flop as the user opens and closes the device — like "always use an even number of grid columns so nothing lands on the fold":

let folds = proxy.reservedRegions(kind: .division, options: .includeInactive)

When to reach for this: custom, manually laid-out controls. Standard containers — NavigationStack, NavigationSplitView, TabView, List, ScrollView — already adapt to the fold for free, and the system automatically repositions alerts, action sheets, menus and popovers around reserved regions. Don't reimplement that.

Design note that's easy to miss: continuously scrolling content (articles, feeds) should not jump around to avoid the fold. Displacement is for discrete elements — a button, a control cluster, a container — not for a reading surface.

Change #5: Arrangements — a new layout container

New in iOS 27.1. An ArrangementView sits between your navigation container and your content, takes a primary and secondary view, and decides how to place them based on size classes, aspect ratio, and any active division regions.

Think Podcasts: now-playing view plus transcript.

var body: some View {
    NavigationStack {
        ArrangementView {
            PlayerView()
        } secondary: {
            UpNextView()
        }
        .arrangementViewStyle(.split)
    }
}

Two styles:

.split — divides the available bounds between the two views. Horizontally when wider than tall, vertically when taller. Constrain it if you only want one axis:

.arrangementViewStyle(.split.axes(.horizontal))

.overlay — prefers stacking content above/below, and moves to side-by-side as the device folds. Read the Z index to adapt the overlaid view:

struct UpNextView: View {
    @Environment(\.overlayArrangementZIndex) private var zIndex

    var body: some View {
        UpNextList(minimized: zIndex > 0)
    }
}

UIKit equivalent:

let arrangement = UIArrangementViewController()
arrangement.setViewController(playerVC, for: .primary)
arrangement.setViewController(upNextVC, for: .secondary)
arrangement.updateArrangement(.split.axes(.horizontal))

let nav = UINavigationController(rootViewController: arrangement)

Picking one: if your existing layout is an HStack/VStack, that's split. If it's a ZStack, that's overlay. Otherwise — overlay when there's a clear foreground/background relationship and partially obscuring the background is acceptable; split when it's main/detail and neither side should be covered.

Two gotchas: ArrangementView provides no navigation infrastructure, so don't nest a NavigationSplitView inside one. And don't put one inside a List or ScrollView.

Change #6: The hinge API

You can read the hinge directly. onHingeChange in SwiftUI, UIHingeInteraction in UIKit. Both give you a coarse status (closed / partially open / fully open) and a continuous angle.

struct InstrumentView: View {
    @State private var pitchBend: Double = 0

    var body: some View {
        GuitarView(pitchBend: pitchBend)
            .onHingeChange { _, context in
                // nil hinge == device doesn't have one. Always check.
                guard let hinge = context.hinge,
                      hinge.status == .partiallyOpen else {
                    pitchBend = 0
                    return
                }
                pitchBend = bend(for: hinge.angle)
            }
    }
}

That guard is not optional politeness — your app runs on every other iPhone too, where context.hinge is nil.

Important boundary: the hinge API is for interactions and effects — a whammy bar, a parallax, a camera shutter that responds to the fold. It is not for layout. Use arrangements and reserved regions for layout. If you find yourself computing frames from hinge.angle, you're on the wrong API.

Change #7: Multiple scenes and Split View

Two apps side by side on iPhone, for the first time. Every app participates whether it opts in or not.

If you already support resizing on iPad or iPhone mirroring, you're most of the way there — same tools, size classes and scene geometry.

For multiple windows of your own app, iPhone Duo is the first iPhone to support it, and apps that already do this on iPad get it automatically. One rule to know: new windows can only be created on the inner display, never the outer one. So handle the failure case:

// Hides itself automatically when new windows aren't available
UIWindowSceneActivation(...)

And actually handle the error path when requesting a scene, rather than assuming it succeeds.

Change #8: Scene accessories (the fun one)

Scene accessories let your app put content on both displays at once. Main UI inside, supplementary content outside.

The headline case is CameraCaptureAccessory, available when your app is full screen on the inner display with an active camera session. The obvious use: showing your subject their own framing on the outer display while you shoot. Or a teleprompter:

struct CameraRootView: View {
    @State private var model = TeleprompterModel()

    var body: some View {
        CameraView(model: model)
            .sceneAccessory {
                CameraCaptureAccessory(isEnabled: $model.isEnabled) {
                    TeleprompterView(model: model)
                }
                .onAvailabilityChange { model.isAvailable = $0 }
            }
            .toolbar {
                TeleprompterToggle(isEnabled: $model.isEnabled)
                    .disabled(!model.isAvailable)
            }
    }
}

The system controls availability dynamically — closing the device takes it away — so wire up onAvailabilityChange and disable your UI accordingly instead of letting users tap into nothing.

Testing this without a $1,999 device

Xcode 27.1 is out now.

iPhone Duo simulator via Device Hub, with on-screen controls to open, close, rotate and fold. This is how you'll actually verify the four poses.
App Resizability — the app modernization skill from "Modernize your UIKit app" at WWDC26, renamed in Xcode 27.1, now covering SwiftUI and iPhone Duo.
Test Split View explicitly. Half-width plus asymmetric insets is where most layout bugs show up.

The checklist

Rough order of effort-to-payoff:

[ ] Rebuild with the iOS 27.1 SDK
[ ] Grep for UIScreen.main and replace it
[ ] Replace orientation checks with size class checks
[ ] Fix any safeAreaInsets.left * 2 style symmetry assumptions
[ ] Move custom navigation to NavigationSplitView / TabView; consider .defaultTabBarPlacement(.sidebar) on the inner display
[ ] Run every screen through all four poses in the simulator
[ ] Audit centered layouts — would a two-column layout be better?
[ ] Adopt ArrangementView for custom split/overlay layouts
[ ] Adopt reserved regions for your highest-priority hand-laid-out controls
[ ] Consider the hinge API and scene accessories if your app has a reason to use them

The first four are cheap and prevent embarrassment. The rest are where the actual opportunity is — the Duo is going to make it extremely obvious to users which apps got attention and which didn't.

FreeLLMAPI: One OpenAI-Compatible Endpoint for 34 Free LLM Providers

ArshTechPro — Fri, 04 Sep 2026 09:01:45 +0000

Almost every AI lab now hands out a free tier. Google, Groq, Cerebras, Mistral, Cohere, NVIDIA, Cloudflare, OpenRouter, and a couple dozen more. Each one on its own is small. A few million tokens a month, a few thousand requests a day. Stacked together, they turn into something you can actually prototype against.

The problem is stacking them by hand. Thirty-four SDKs, thirty-four sets of rate limits, thirty-four places your request can fail at 2 AM.

FreeLLMAPI is an open-source router that collapses all of that into a single /v1 endpoint. You point any OpenAI client at your own machine, and it routes across whatever providers you've added keys for.

First, the question everyone asks: is it actually free?

Short answer: yes, the software is free and stays free. There is a paid tier, but it does not gate the router.

Here is the honest breakdown.

What is free, permanently

The router itself is MIT-licensed. Self-host it with Docker, npm, or the desktop app. No account with the project required to run it.
Every feature works: routing, failover, rate tracking, the dashboard, analytics, the playground, all the API surfaces.
The inference is free because you bring your own free-tier provider keys. FreeLLMAPI does not resell tokens. It never sees your prompts on a remote server.

What costs money

One thing only: the live model catalog feed. $19/year or $49 once for lifetime.
Free installs get the same signed catalog, but from a monthly snapshot. A new model reaches free installs about 30 days after it hits the live feed. The project says free builds currently sit roughly 303 models behind.
Nothing expires, nothing gets crippled, no request caps are added. Updates just arrive later.

So the mental model is: the software is free, the tokens are free (they're your own free tiers), and the $19/yr is a convenience subscription for same-day model catalog updates. If you're fine being a month behind on newly-launched free models, you never pay anything.

The catch that isn't about money

The repo is blunt about this, and so am I: this is for personal experimentation and learning. Not production. No frontier models, variable latency, no SLA, and the effective quality of the endpoint drops late in the day as the best free models hit their daily caps (they reset at UTC midnight). Your relationship with each upstream provider is still governed by the terms you agreed to when you signed up for them. Ship something real, swap in a paid API first.

So how does the "aggregator" actually work? Do I get an API key?

Yes, but probably not the way you're imagining. There is no signup page where FreeLLMAPI hands you a key to a hosted service. It is local-first and single-user by design.

The flow is two layers of keys:

Layer 1: your provider keys (inbound). You go and get free-tier API keys yourself from Google AI Studio, Groq, Cerebras, Mistral, and so on. You paste them into the FreeLLMAPI dashboard on the Keys page. They get AES-256-GCM encrypted and stored in a local SQLite database, then decrypted in memory only for the duration of a request.

Layer 2: your unified key (outbound). The router generates a single bearer token that looks like freellmapi-.... That is the only credential your applications ever see. Your app never touches the provider keys.

Your app  ──[freellmapi-xxx]──►  Local router  ──[real provider keys]──►  Groq
                                      │                                   Google
                                      │                                   Cerebras
                                      └─ picks, tracks limits, fails over  ...

What the router does per request:

Looks at your fallback chain and picks the highest-priority model that has a healthy key and is currently under all of its rate limits.
Decrypts that provider key in memory and calls the provider.
On a 429 or 5xx, it puts that key on cooldown and immediately retries the next model in your chain.
Tracks RPM/RPD/TPM/TPD per (provider, model, key) so it stays under every free-tier cap instead of discovering the cap by getting rejected.
Returns an X-Routed-Via: <provider>/<model> header so you can see who actually served the request.

There is also sticky sessions (a conversation stays on one model for 30 minutes so replies stay coherent), unified model entries when the same model exists on several providers, and named routing profiles you can switch per request with auto:<profile>.

Simple steps to get running

Step 1: Install

The one-liner needs Docker. It creates ~/freellmapi, generates an encryption key, pulls the image, and starts the container.

curl -fsSL https://freellmapi.co/install.sh | bash

If piping to bash makes you uncomfortable, the script is readable at the same URL first. Re-running it is safe: it keeps your existing .env and encryption key.

On Windows or macOS you can skip Docker entirely and grab the desktop installer from the GitHub Releases page. It runs the whole router and dashboard from your tray, and there is no password to set up.

Step 2: Open the dashboard

http://localhost:3001

Step 3: Add your free provider keys

Go to the Keys page and paste in whatever free-tier keys you have. Start with two or three, you don't need all thirty-four. Good ones to begin with:

Google AI Studio for Gemini models
Groq for very fast inference
Cerebras for very fast inference
Mistral

Each key shows a status dot and when it was last health-checked, so you'll know immediately if you pasted a bad one.

Step 4: Set your fallback chain

On the Models page, drag your preferred models into order. That order is literally the routing priority. Top of the list gets tried first, and everything below it is your automatic failover.

Step 5: Copy your unified key

It's in the header of the Keys page, starting with freellmapi-. This is the key your code uses.

Step 6: Point your code at it

Nothing new to learn. It's the OpenAI SDK with a different base_url.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:3001/v1",
    api_key="freellmapi-your-unified-key",
)

resp = client.chat.completions.create(
    model="auto",   # let the router choose
    messages=[{"role": "user", "content": "Explain database indexes in two sentences."}],
)

print(resp.choices[0].message.content)

Node is the same idea:

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://localhost:3001/v1",
  apiKey: "freellmapi-your-unified-key",
});

const resp = await client.chat.completions.create({
  model: "auto",
  messages: [{ role: "user", content: "Explain database indexes in two sentences." }],
});

console.log(resp.choices[0].message.content);

And plain curl:

curl http://localhost:3001/v1/chat/completions \
  -H "Authorization: Bearer freellmapi-your-unified-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hello"}]}'

For the model field you can pass:

"auto" — router picks the best available
"auto:fast" or "auto:smart" — bias toward speed or capability
"auto:<your-profile>" — a named chain you built in the dashboard
an explicit model id — pin it to one model
"fusion" — fan the prompt out to several free models in parallel and have a judge model synthesize one answer

Step 7 (optional): Wire up your coding agent

This is where it gets genuinely useful. Most CLI agents configure themselves with one command:

npx freellmapi setup-claude --url http://localhost:3001 --api-key <unified-key>

There are generators for Codex CLI, Cline, Continue, Aider, OpenCode, Goose, Qwen Code, Roo, Kilo, Crush, DeepSeek Harness, and more. Every one supports --dry-run and backs up your existing config before touching it.

What surfaces you get

Beyond /v1/chat/completions, the router implements:

/v1/responses (what Codex CLI needs), /v1/completions for editor ghost-text
/v1/embeddings, /v1/models
/v1/images/generations, /v1/videos/generations, /v1/audio/speech, /v1/audio/transcriptions
/v1/messages — Anthropic's wire format, so Claude Code and the Anthropic SDKs work against your free pool
/v1beta — Gemini's native surface for Gemini CLI
Optional Ollama emulation for Zed and JetBrains AI
/mcp — an MCP server so agents can introspect available models and provider health mid-session

Tool calling and structured outputs round-trip across providers, including a nice touch where plain-text tool calls from weaker models get rescued into proper tool_calls.

You can also add a custom provider pointing at any OpenAI-compatible endpoint: llama.cpp, LM Studio, vLLM, a local Ollama, or a remote gateway. So your local models sit in the same fallback chain as the cloud free tiers.

Should you use it?

Use it if you are: prototyping, building side projects, running a coding agent on your own machine, learning how routing and failover work, or just tired of managing eleven different .env variables.

Do not use it if you are: shipping to customers, need an SLA, need frontier-model quality, or need predictable latency.

It runs on anything with Node 20+, including a Raspberry Pi, at around 40 MB RSS idle.

Repo: github.com/tashfeenahmed/freellmapi

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

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

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

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

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

It is a Markdown file

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

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

How it works

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

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

The patterns fall into five groups:

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

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

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

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

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

A quick illustration of the shape of the fix:

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

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

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

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

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

Does it work with Claude?

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

Claude Code, via the skills CLI:

npx skills add blader/humanizer --global

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

Claude Code as a plugin (2.1.142 or newer):

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

Invoke it with /humanizer:humanizer.

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

Once installed, either invocation style works:

/humanizer

[paste your text here]

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

Does it work with other agents?

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

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

Common targets and where the files land:

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

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

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

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

What it does not do

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

Some patterns are opinions, not rules.

It cannot add substance.

Overcorrection is real.

Worth using?

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

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

Repo: github.com/blader/humanizer

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

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

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

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

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

The mental model: patches are tokens

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

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

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

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

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

Getting started

Installation is a one-liner:

pip install timesfm[torch]

Or from source with uv:

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

The 2.5 API

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

import torch
import numpy as np
import timesfm

torch.set_float32_matmul_precision("high")

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

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

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

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

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

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

import pandas as pd

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

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

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

What changed in 3.0

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

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

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

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

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

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

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

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

import numpy as np
from timesfm3 import TimesFM3Evaluator, ModelConfig

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

context_len, horizon = 128, 24

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

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

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

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

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

The catch nobody mentions in the benchmark charts

Read this part before you plan a sprint around it.

The 3.0 weights are not open for commercial use.

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

So the practical situation right now is:

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

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

Is it worth a try?

Yes, if any of these describe you:

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

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

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

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

Be skeptical if:

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

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

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

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

Where to go next

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

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

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

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

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

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

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

What it actually is

Strip the branding and Omarchy is three things stacked:

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

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

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

Installation

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

Three things to know before you start:

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

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

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

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

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

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

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

The keyboard-first part

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

A representative slice:

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

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

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

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

The AI-workstation angle

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

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

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

The maintenance question

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

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

Where I'd push back

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

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

Is it worth a try?

It depends almost entirely on which of these you are.

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

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

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

Repo: github.com/basecamp/omarchy

DEV Community: ArshTechPro

Goodbye pbxproj: A Friendly Guide to Xcode 27.2's New JSON Project Format

TL;DR

First, what is an .xcodeproj?

Why the old format hurt

What the new file looks like

1. It's a tree, not a flat list

2. Files say which target they belong to

3. Build settings are written once

Bonus: IDs are mostly gone

Gotcha: it's "JSON", but with trailing commas

How to switch an existing project

In Xcode

From the command line

New tooling: xcprojformatter and an open-source library

What about Tuist, XcodeGen, CocoaPods, fastlane?

Why now? (Hint: AI agents)

Should you switch?

Summary

Orca: The Agent Development Environment for Running AI Coding Agents in Parallel

What is Orca?

A quick primer on git worktrees

What does a typical workflow look like?

Key features

Is Orca like Cursor?

Pricing: is Orca free?

Installing Orca

Who should try Orca?

Worktrunk: Git Worktrees Made Simple for Parallel AI Agents

What Worktrunk is

The core commands

Getting started

Running agents in parallel

Extras worth knowing

Is it worth a try?

Links

Docling: Turn Messy Documents into Clean Data for Your AI App

The problem

What Docling is

What it supports

Getting started

Where it fits in your stack

Is it worth a try?

Links

Open Source Alternative to Claude Code and Cursor: Meet Cline

What Can It Actually Do?

It edits code across your whole project

It runs terminal commands

Plan mode and Act mode

Custom rules and skills

You're not locked into one AI model

Extensibility: plugins and MCP servers

Multi-agent teams and scheduled agents

Chat with it from Slack, Telegram, Discord, and more

Headless mode for CI/CD

How Do You Get Started?

Is It Worth Trying?

How It Compares to Other Agents

BrewUI: A First Look at Homebrew's Official macOS GUI

What is BrewUI?

The core idea: transparency

Homebrew stays the source of truth

Tech stack at a glance

How the architecture works

Views

ViewModels

Repositories

Interactors

Services

Models

The command center: why brew commands run one at a time

Designing for tools that change

What 100+ Leaked System Prompts Teach You About Prompt Engineering

First, what is a system prompt?

What the repo contains

How are these prompts obtained?

Why developers should care

1. It is a free masterclass in production prompt engineering

2. It shows how tools and agents are wired up

3. It explains "weird" model behavior

First, what is an `.xcodeproj`?

New tooling: `xcprojformatter` and an open-source library