DEV Community: ArshTechPro

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

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

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

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

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

What problem is it solving?

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

A typical agent session has:

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

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

How it works (the short version)

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

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

Getting started

What you need

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

Option 1: Docker (recommended)

The project ships a runner image with everything preinstalled:

docker pull lightseekorg/tokenspeed-runner:latest

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

Mounting your cache directory means model weights survive container restarts.

Option 2: pip (nightly wheels)

On a CUDA 13 machine:

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

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

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

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

Check that everything is in place:

tokenspeed env
tokenspeed serve --help

Launch your first model

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

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

Call it like OpenAI

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

from openai import OpenAI

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

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

Or with curl:

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

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

Going bigger

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

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

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

What about performance?

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

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

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

Is it worth a try?

Yes, if:

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

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

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

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

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

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

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

What is REA?

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

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

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

The mental model: Decompile, Understand, Recreate

REA frames every investigation in three stages:

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

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

What a real investigation looks like

Say you ask your agent:

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

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

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

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

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

How it works under the hood

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

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

A few design choices stand out:

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

What it can analyze today

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

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

Getting started

Requirements

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

Install and run setup

The quickest path:

npx --yes rea-agents@latest setup

Or install the CLI globally:

npm install --global rea-agents
rea setup

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

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

Check your environment

rea doctor

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

Try it from the terminal

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

Or just ask your agent

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

Manual MCP configuration

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

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

Pin to the latest published version from npm.

Safety and permissions

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

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

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

Is it worth a try?

Yes, if:

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

Maybe hold off if:

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

A few practical notes:

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

Summary

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

GitHub: github.com/morluto/rea

Trying e2e: Write End-to-End Tests with Plain English and Real Assertions

ArshTechPro — Tue, 06 Oct 2026 13:27:49 +0000

End-to-end tests are valuable and painful in equal measure. Selectors break when someone renames a class. Mobile tests need their own tooling. A flow that takes one sentence to describe takes fifty lines to script.

e2e is an open source framework that tries to fix this by mixing two styles in one test: plain-English steps run by an agent, and normal locators and assertions you already know. Here is what it does and whether it deserves a spot in your stack.

What is e2e?

e2e is an end-to-end testing framework for web and mobile apps. You describe a goal in natural language, and an agent interacts with the app to complete it. When you need exact checks, you use regular locators and assertions in the same test.

It is built by the TesterArmy team and released under the Apache-2.0 license.

A first look

This is what a test looks like:

// tests/checkout.e2e.ts
import { test, expect } from 'e2e';

test('a member upgrades to Pro', async ({ app, agent, screen }) => {
  await app.open('/settings/billing');

  await agent.act('upgrade the workspace to the Pro plan');
  await agent.assert('the invoice preview shows a prorated amount');

  await expect(screen.getByRole('status')).toContainText('Pro');
});

There are three kinds of steps here:

app.open navigates to a page.
agent.act and agent.assert take plain-English instructions and checks.
expect(screen.getByRole(...)) is a precise, deterministic assertion.

The agent handles the part that is tedious to script, such as clicking through a billing flow. Your own assertion verifies the result. The test reads like a description of the feature, and you still get an exact check at the end.

Getting started

Setup is one command:

npx e2e init

From there, the docs at e2e.tester.army/docs cover the quickstart, writing tests, mobile, and the full reference. The e2e package also ships every docs page in node_modules/e2e/docs, so coding agents can read them offline.

The part that matters: replay

The obvious worry with AI-driven tests is cost and flakiness. Calling a model on every run is slow and expensive, and results can vary.

e2e's answer is replay. According to the README, when an agent step is verified by a later assertion, the framework records the actions it took. The next run replays them with no model calls, until the app changes. Tests without agent steps need no model at all.

In practice this means you pay for the model when a flow is new or has changed, not on every CI run. You can also bring your own subscription, API key, or local model.

Packages

e2e is split into small packages, so you only install what you need:

Package	Purpose
`e2e`	SDK, runner, and CLI
`@e2e-dev/web`	Browser engine
`@e2e-dev/mobile`	iOS and Android engine
`@e2e-dev/github`	Pull request comment reporter
`@e2e-dev/kernel`	Hosted browsers for the web engine
`@e2e-dev/eas`	Hosted iOS simulators and Android emulators

If you are coming from another tool, the docs include migration guides for Playwright, Cypress, Selenium, Detox, and Maestro.

Is it worth trying?

It is a good fit if:

You have a critical flow (checkout, onboarding, billing) that is expensive to script and easy to break.
You test mobile and want something simpler than a separate toolchain.
You like the idea of readable tests but still want exact assertions.

Be aware of a few things:

The project is young, so expect rough edges and changes. Start with one or two flows rather than migrating a whole suite.
It comes from a company that also sells a testing platform. The framework is open source, but keep that context in mind.
Agent steps depend on a model, so check how replay behaves on your own app before trusting it in CI.

Verdict

e2e is a practical take on AI in testing: use the agent for the tedious parts, use real assertions for the checks that matter, and replay recorded runs so you are not paying for a model on every build.

Try it on one flow this week. If it saves you from maintaining a brittle script, expand from there.

Repo: github.com/tester-army/e2e

Caveman: Make Your AI Coding Agent Talk Less (and Save Tokens)

ArshTechPro — Fri, 02 Oct 2026 14:22:14 +0000

If you use an AI coding agent every day, you have probably noticed how much of its output is padding. Phrases like "The reason this is happening is likely because..." or "I'd recommend that you consider..." appear before the useful part of the answer. You pay for those tokens, and you spend time reading them.

Caveman is an open source project that fixes this. Its tagline is "why use many token when few do trick", and it does what it says: your agent answers in short, blunt sentences without the filler.

What it does

Here is the example from the README. The question is why a React component keeps re-rendering.

Normal agent (69 tokens):

The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object.

Caveman agent (19 tokens):

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.

The diagnosis and the fix are the same. Only the throat-clearing is gone.

Code, commands, file paths, and exact error messages are never rewritten. Only the prose around them gets shortened, so the answers stay accurate and copy-pasteable.

Install in one command

The simplest version is a skill, which is a rule file your agent loads:

npx skills add JuliusBrussee/caveman

It works with 30+ agents, including Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Cline, and Copilot. If your agent does not pick it up automatically, type /caveman in the chat.

Intensity levels and commands

You control how terse the agent gets:

/caveman lite
/caveman full
/caveman ultra
/caveman off

The skill also adds a few useful commands:

/caveman-commit writes short Conventional Commit messages.
/caveman-review gives one-line, actionable code review comments.
/caveman-compress <file> shrinks Markdown memory files and keeps a backup of the original.
/caveman-stats shows local token usage and estimated savings in Claude Code.

The numbers

The author ran ten ordinary coding prompts through the Claude API, with and without the skill. Output tokens dropped by 65% on average. The range is wide, though:

Task	Normal	Caveman	Saved
Implement React error boundary	3454	456	87%
Set up PostgreSQL connection pool	2347	380	84%
Explain git rebase vs merge	702	292	58%
Refactor callback to async/await	387	301	22%

The pattern is simple. When the agent would have written an essay, you save a lot. When the answer was mostly code, you save very little.

Read this before quoting the 65%

The project is unusually honest about its limits, and you should be too:

The skill only shortens output. Input and reasoning tokens do not change.
The skill's own rules add roughly 1 to 1.5k input tokens on every turn.
Whole-session savings will be lower than the benchmark table, and on work that was already terse you can end up paying more.

The README says speed and readability are the real product, and the discount is a bonus. Measure your own setup before promising anyone a 65% cut on the bill.

The optional proxy

There is also a second, bigger piece: a local proxy that sits between your agent and the AI provider. It shrinks what the agent reads, such as logs, diffs, and test output, before each call, and it keeps a backup of every original on your machine.

npm install -g @caveman-ai/cli && caveman setup --install
caveman claude

In a 54-run Claude Code benchmark, total input tokens dropped by about 33%. One case, an HTML dashboard, actually got 9.9% worse, and the README leaves that row in the table. It is a bigger commitment than the skill, so start with the skill.

Things to know before you install

Telemetry: the caveman CLI sends anonymous usage stats by default (commands run and token counts, never prompts or code). Turn it off with caveman telemetry off or DO_NOT_TRACK=1. The skill itself runs entirely on your machine.
Licensing: the skill and CLI are MIT. The engine and proxy are BSL-1.1, which is source-available but not OSI open source. Self-hosting for your own use is fine.

Is it worth trying?

Yes, with realistic expectations. The skill is a one-line install, easy to turn off, and does not touch your code. If your agent is wordy, you get faster, easier-to-scan answers right away. Treat any token savings as a bonus and check them with /caveman-stats.

Repo: github.com/JuliusBrussee/caveman

Impeccable: Stop Your AI Coding Agent From Building the Same Ugly UI

ArshTechPro — Fri, 02 Oct 2026 06:45:50 +0000

Impeccable is a design skill for AI coding agents. It started from Anthropic's frontend-design skill and extends it with three things:

A single setup step. /impeccable init inspects your project and writes a PRODUCT.md file with your audience, purpose, constraints, and voice. Later commands use it as context.
24 commands that give you and the agent a shared design vocabulary.
61 deterministic detector rules that flag common AI design mistakes. They run without an LLM or an API key.

It works with Claude Code, Cursor, Codex CLI, Gemini CLI, GitHub Copilot, and a long list of other tools.

Install in two commands

From your project root:

npx impeccable install

The installer detects which AI tools you use and asks whether to install for the project or globally. Reload your tool, then run:

/impeccable init

If you use Claude Code, you can also install it as a plugin with /plugin marketplace add pbakaus/impeccable.

The commands worth knowing

You do not need all 24. These cover most daily use:

Command	What it does
`/impeccable craft`	Plan, then build a new surface with visual iteration
`/impeccable critique`	UX review of hierarchy, clarity, and tone
`/impeccable audit`	Technical checks for accessibility, performance, and responsiveness
`/impeccable polish`	Final pass before shipping
`/impeccable distill`	Strip a design down to what matters
`/impeccable harden`	Error states, text overflow, i18n, edge cases

Each command takes a target, so you stay in control of scope:

/impeccable audit the header
/impeccable polish the checkout form
/impeccable harden checkout

You can also describe what you want in plain language, for example /impeccable redo this hero section. If you use one command a lot, /impeccable pin audit turns it into a standalone /audit.

The part that works without AI: the detector

This is the feature I would try first. The CLI can scan your code, or a live URL, for design problems with no model involved:

npx impeccable detect src/
npx impeccable detect https://example.com
npx impeccable detect --json .

It catches things like purple gradients, bounce easing, tiny touch targets, skipped headings, and cramped padding. The --json flag and exit codes make it easy to add to CI. Because the rules are deterministic, the results are repeatable, which is hard to get from asking an AI to review the design.

The README is honest about the limits too: a clean run is evidence, not proof, and it does not replace looking at the page on real viewports.

The design hook

On Claude Code, Cursor, Codex, GitHub Copilot, and Grok Build, the installer can add a hook that runs the detector whenever the agent edits a UI file. The agent sees the findings and can fix them in the same session. On Cursor it can block a bad write before it lands. This catches problems while the code is being written, instead of in review.

Things to check before adopting

Hooks run on their own. In Claude Code, installed hooks run independently of tool approval, and the first run may download a binary into ~/.impeccable/bin/. Review the hook before using it in unattended runs.
Live mode is for local development only. Do not inject it into a deployed production site.
Ignore the right files. The repo provides a .gitignore block for the .impeccable/ folder, so screenshots and caches do not get committed. Keep the shared config and design files tracked.
Opinionated by design. It discourages fonts like Inter and Arial and warns against nested cards. If your brand uses Inter, you can add an ignore rule with a reason:

npx impeccable ignores add-value overused-font Inter --reason "Brand font"

Is it worth trying?

Yes, for most developers who build UI with AI tools. The setup takes a couple of minutes, nothing locks you in, and you can try the detector alone without letting an AI touch your code.

It is most useful if you:

ship side projects or MVPs and do not have a designer
are tired of every AI-generated page looking the same
want automated design checks in CI

Repo: github.com/pbakaus/impeccable

NVIDIA OpenShell Explained: A Safer Runtime for AI Agents

ArshTechPro — Wed, 30 Sep 2026 11:53:47 +0000

AI agents are getting genuinely useful. They can read your files, install packages, call APIs, and run shell commands. That is exactly what makes them risky.

If you have ever pasted an API key into an agent's environment and then held your breath while it ran, this article is for you. NVIDIA has an open source project called OpenShell that tries to solve this problem. Let's look at what it is, how it works, and whether it is worth your time.

The problem in one paragraph

An agent is only useful if it can do things. But every capability you give it is also a capability that can go wrong: a prompt injection in a web page, a hallucinated rm -rf, a dependency that phones home, or a leaked token in a log. Most of us handle this today by running the agent in a Docker container and hoping for the best. That helps, but a container by default does not know the difference between "download a package from PyPI" and "send your credentials to a random server."

What OpenShell is

According to the project, OpenShell is "the safe, private runtime for autonomous AI agents." In practical terms, it is:

A CLI you use to create and manage sandboxes.
A gateway that acts as the control plane for sandboxes, policies, and access.
A sandbox where the agent actually runs, isolated from your host.
A policy system where you declare what the agent can access.

You write the rules. OpenShell enforces them. The agent does not get to negotiate.

How it works

The README describes two main ideas.

1. Enforcement at the kernel level

Each agent runs in its own isolated sandbox. Kernel-level controls restrict which files the agent can open and which system calls it can make. Every network connection goes through a policy check before it leaves the sandbox.

2. Formally verified policy changes

Agents often need new access as they work. Maybe your agent suddenly wants to reach a new host. Normally you would either approve everything (unsafe) or approve each request by hand (exhausting).

A mental model that helps

Think of it like a building with a security desk.

The sandbox is the room the agent works in.
The policy is the visitor list and the set of doors the agent's badge opens.
The provider is a mail clerk who attaches the real stamp (your credential) to an approved letter, so the agent never holds the stamp itself.
The gateway is the security office that manages all of it.

Getting started

Requirements from the README: Linux, macOS on Apple Silicon, or Windows with WSL 2 (marked experimental). You also need Docker, Podman, or host virtualization.

Install and create a sandbox:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

The installer sets up the CLI and a local gateway. The default sandbox image is a minimal Ubuntu with no agent installed, so you are starting with a clean, locked-down box.

As always with a curl | sh installer, read the script before running it on a machine you care about.

To run a real agent, the docs have a "Run Your First Agent" walkthrough. It runs OpenCode against a free OpenRouter model and shows how to approve new access as the agent asks for it. That walkthrough is the best way to see the policy loop in action.

Talking to it from code

If you want to integrate OpenShell into your own application, there are SDKs that connect to a gateway:

Language	Install
Python	`uv add openshell`
TypeScript	`npm install @nvidia/openshell-sdk`
Go	`go get github.com/NVIDIA/OpenShell/sdk/go@latest`
Rust	`cargo add openshell-sdk --git ... --tag <release-tag>`

Note that the SDKs do not install the CLI. You still need a gateway running, and the project recommends using the same release for both.

There is also a set of "agent skills" you can install so your coding agent learns how to drive the OpenShell CLI and write policies for you:

npx skills add NVIDIA/OpenShell

Other things worth knowing

Kubernetes support. You can deploy the gateway with Helm. Your CNI must enforce NetworkPolicy.
Extensibility. The docs mention middleware, interceptors, and compute drivers.
GPU support. The sandbox docs cover GPUs, which matters if your agents run local models.
License. Apache 2.0.
Telemetry. Anonymous telemetry is on by default and limited to operational categories and counts. The README says it does not collect prompts, file paths, credentials, or model names. You can turn it off with OPENSHELL_TELEMETRY_ENABLED=false on the gateway.

Reasons to try it

It targets a real problem. Credential leakage and over-permissioned agents are the most common ways agent setups go wrong. Keeping real secrets out of the agent's reach is a strong design choice.

Policy as configuration. Being able to declare "this agent can read this folder and call these two APIs" and have it enforced is far better than relying on prompt instructions like "please do not touch anything else."

Good signs of a serious project. The repository has around 10k stars, 1.4k forks, and over 1,500 commits. It ships SDKs in four languages, has an RFC process, a governance document, and a security policy. This is not a weekend demo.

It comes from NVIDIA. That is not a guarantee of quality, but it does suggest ongoing investment and attention to GPU-heavy agent workloads.

If you are...	Should you try it?
Running autonomous agents with real credentials or access to sensitive data	Yes. This is the target use case.
Building an agent platform or internal tooling for a team	Yes. The policy and gateway model fits well.
Experimenting with agents on your laptop, mostly for fun	Maybe. A plain container may be enough for now.
Building a simple chatbot with no tool access	No. You do not need it.
Needing production stability today with no tolerance for change	Wait a bit. Watch the releases and let it mature.

My short answer: yes, it is worth an afternoon of your time, especially if you are giving agents access to anything you would be upset to lose. Follow the "Run Your First Agent" guide, watch how the policy approvals work, and then decide whether the extra structure pays for itself in your setup. Just go in knowing it is a young project.

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

DEV Community: ArshTechPro

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

What problem is it solving?

How it works (the short version)

Getting started

What you need

Option 1: Docker (recommended)

Option 2: pip (nightly wheels)

Launch your first model

Call it like OpenAI

Going bigger

What about performance?

Is it worth a try?

Links

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

What is REA?

The mental model: Decompile, Understand, Recreate

What a real investigation looks like

How it works under the hood

What it can analyze today

Getting started

Requirements

Install and run setup

Check your environment

Try it from the terminal

Or just ask your agent

Manual MCP configuration

Safety and permissions

Is it worth a try?

Summary

Trying e2e: Write End-to-End Tests with Plain English and Real Assertions

What is e2e?

A first look

Getting started

The part that matters: replay

Packages

Is it worth trying?

Verdict

Caveman: Make Your AI Coding Agent Talk Less (and Save Tokens)

What it does

Install in one command

Intensity levels and commands

The numbers

Read this before quoting the 65%

The optional proxy

Things to know before you install

Is it worth trying?

Impeccable: Stop Your AI Coding Agent From Building the Same Ugly UI

Install in two commands

The commands worth knowing

The part that works without AI: the detector

The design hook

Things to check before adopting

Is it worth trying?

NVIDIA OpenShell Explained: A Safer Runtime for AI Agents

The problem in one paragraph

What OpenShell is

How it works

1. Enforcement at the kernel level

2. Formally verified policy changes

A mental model that helps

Getting started

Talking to it from code

Other things worth knowing

Reasons to try it

Links

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

First, what is an `.xcodeproj`?

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