Tower of Kubes

OpenCode: The Agentic Tool That Anthropic and Google Don't Want You To Use

2026-05-05T00:00:00Z

For the past four months, OpenCode has been my primary agent tool. A piece of AI industry drama is what brought it to my attention.

Background

In January 2026, I started seeing drama online: Anthropic blocks third-party use of Claude subscriptions. The most surprising part to me wasn’t that Anthropic decided to block this type of usage, that’s unfortunate but expected. What surprised me was that I hadn’t known this was even possible in the first place.

I had briefly read about OpenCode and Crush during my Agentic CLI Tools Comparison, but hadn’t used them due to their BYO (Bring Your Own) API key requirement, which in most cases is significantly more expensive than subscription tiers. As it turns out, people had found ways to use those subscriptions anyway. OpenCode had implemented an OAuth flow that spoofed Claude Code’s HTTP headers to authenticate against Anthropic’s API with a Claude Pro or Max subscription. This gave OpenCode users access to Claude models at subscription pricing, a significant cost advantage.

The Crackdown

Anthropic’s response came in several phases. Active enforcement began on January 9, 2026, when Anthropic deployed server-side protections blocking all unofficial OAuth access. On February 19, Anthropic updated its legal compliance page to make the OAuth restriction explicit: OAuth tokens obtained from Claude subscription accounts are only permitted for use with official Claude tools.

Legal requests followed, and in mid-March OpenCode’s maintainers merged a PR removing the Anthropic OAuth plugin from the project. By early April, Anthropic extended restrictions to OpenClaw and other third-party harnesses. Google ran the same playbook with Gemini around the same period, banning third-party OAuth access and issuing account-level suspensions.

The Community Reaction

The Hacker News thread filled with genuine disappointment. Many users felt OpenCode was a significantly better tool than Claude Code. The main advantages cited were its open-source MIT license, an optional web UI and client/server architecture, and the absence of flickering, a complaint about Claude Code that hasn’t gone away. OpenCode had also grown remarkably fast, reaching over 150,000 GitHub stars.

OpenAI and GitHub went the other direction. Tibo, OpenAI’s Codex lead, announced on X that Codex subscribers could use their subscription directly within OpenCode, and GitHub formally announced support for OpenCode across all GitHub Copilot subscriptions. That’s what originally got me to give OpenCode a real try, paired with GitHub Copilot and ChatGPT subscriptions, and I’ve been using it regularly since.

My Impressions of OpenCode

OpenCode immediately seemed appealing when I started using it. Until that point, Claude Code had remained my preferred agentic CLI tool. In the months since I wrote Agentic CLI Tools Comparison, I had continued experimenting with different CLI tools and models, notably Claude Code 2.0, Codex CLI, Gemini CLI, and GitHub Copilot CLI. Claude Code consistently remained the best tool in my opinion, both in terms of UI design and features, and in terms of Anthropic’s models feeling the strongest at coding and agentic tool usage based on my experience. The other tools felt like UI imitations of Claude Code running different models, with no meaningful improvements. OpenCode is genuinely different, though. It runs on a client/server model with an HTTP API, supports 75+ AI providers including local models, and has native multi-session support.

When opening OpenCode in a terminal, it feels familiar but different. The starting screen looks a lot like a classic search engine, with the prompt box centered on the screen, rather than being off to the bottom like in most other agentic CLI tools.

However, once you enter an initial prompt, the prompt box moves to the bottom of the terminal, making for a more familiar look. In my opinion, OpenCode strikes a good balance: it will feel familiar to users who have used Claude Code (and similar tools) before, but at the same time it does not feel like a clone of other tools. OpenCode does a lot of unique things that other tools don’t do. For example, OpenCode has a useful sidebar that displays information about active MCPs, LSPs (language servers) and token usage for the current session.

The look of OpenCode becomes even more unique when using its web UI or the OpenCode desktop app.

Image source: Web | OpenCode

Models and Providers

When first using OpenCode, it defaults to using the OpenCode Zen models. As of today, OpenCode Zen offers several free models, as well as paid models.

When using OpenCode Zen, it’s recommended to read about the privacy for each model.

These paid models can either be used by paying for credits (similar to OpenRouter) or using the OpenCode Go subscription. However, OpenCode does not limit to only using their offering. One of the best features of OpenCode is its wide provider support. LLM models can be used from practically any provider (that hasn’t outright blocked OpenCode), or even use local models. This provides users a lot of flexibility to use the same tool across many different models, with one unified agent harness. It also means users are not “locked-in” to one provider if they want to continue using OpenCode. When providers change the terms, such as Claude and Gemini limiting usage of OpenCode, or GitHub Copilot changing the terms of their subscriptions, OpenCode users can just move to other providers and continue their existing workflow.

Agentic Tool Usage

Using one tool for all providers also means that I can have a unified place to configure my MCP servers, Skills and AGENTS.md files. While there have been attempts to standardize the agents world, including the Agentic AI Foundation (AAIF), the reality is that agentic tools still have different ways to configure. For example, Anthropic to date has refused to adopt the usage of the AGENTS.md file, instead referring only to the CLAUDE.md file.

OpenCode supports these emerging agent standards, as well as LSP servers (Language Server Protocol, which has been around before agents, to give code editors better support for programming languages). At the same time, OpenCode also has its own config file.

As an example, if you want to configure Chrome DevTools MCP server, add the following to your OpenCode config:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "chrome-devtools": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
    }
  }
}

OpenCode also supports a range of built-in tools, including web searches. One of my personal favorite tools is the question tool. It allows the model to ask you questions mid-task: for gathering preferences, clarifying instructions, or getting decisions on implementation choices. Each question includes a header, question text, and a list of options, with the ability to type a custom answer. When there are multiple questions, you can navigate between them before submitting.

It’s Dangerous: Permissions and Safety

OpenCode is a powerful tool, and with great power comes great responsibility. By default, it will happily edit anything, run anything, and delete anything without asking, which can feel great for vibe-coding but can also wreak havoc on your machine and codebases if left unchecked. For users that are coming from Claude Code, the default permissions feel similar to the claude --dangerously-skip-permissions flag. By default, OpenCode does not ask permission for anything. It edits files freely and can run any command. Even when using “Plan” mode (instead of “Build” mode), OpenCode can still run commands (by default the “Plan” mode only disallows file edits). Fortunately, this is fairly easy to fix. To get a locked-down OpenCode, add this to your OpenCode config:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask"
  }
}

OpenCode Permissions can be customized further.

It is also worth running OpenCode in a sandboxed environment. Refer to my previous article on Claude Code Sandboxing for examples on how to achieve this.

Final Verdict: Is OpenCode Better Than Claude Code?

Overall, OpenCode is a very compelling agent tool, with wide model support and lots of features. It is certainly among the best AI tools I have ever used.

On the question of “OpenCode vs. Claude Code”, I would say both tools are honestly equally strong. OpenCode felt like a breath of fresh air after months of using Claude Code, with many unique features. For example, mouse support, which Claude Code has only recently gained and is currently still a preview feature. At the same time, going back to Claude Code after several months of only using OpenCode, I have noticed Anthropic have not been resting and have been frantically adding new features to Claude Code, including plugins and a plugin marketplace, Agent Teams for multi-agent orchestration, the /btw command for lightweight side questions, and Auto mode, a new permission tier that sits between manual approval and skipping permissions entirely.

Overall, OpenCode feels surprisingly more polished (despite being developed by a much smaller team), while Claude Code has the edge in raw features. Nevertheless, the tools feel very close in quality. The choice between them ultimately comes down to one question: do you have a Claude subscription?

As I explained at the opening of this article, Anthropic has made their stance clear that Claude subscriptions are only for use within official Claude tools, and third-party tool usage is blocked for subscribers. Claude Code also locks you into Claude models exclusively, with no support for other providers.

If you’re already paying for a Claude subscription, Claude Code is the natural fit, as it’s the only tool where Anthropic’s subscriptions are officially supported. If you’re not, OpenCode’s model flexibility and open-source nature make it a compelling alternative that gives you full control over both your models and your costs.

Featured image by Viktor Forgacs on Unsplash.

Chrome DevTools MCP server

2025-11-16T00:00:00Z

I have recently been using Chrome DevTools MCP server (which I tend to call Chrome MCP) to work on personal projects, notably CALMe. In my first day of using MCP, I added Playwright MCP server to my .mcp.json. Both Playwright MCP and Chrome DevTools are MCP servers that work in similar ways, they give MCP clients (agentic CLI tools) various tools that give the ability to browse web pages, click on buttons, read console logs and even “see” how the web page looks by allowing the client to take screenshots/snapshots. Playwright MCP is based on the Playwright framework for Web Testing and Automation, and is developed by Microsoft. Chrome DevTools MCP is based on the world’s most popular browser, and specifically its DevTools, and is developed by Google. Two big tech giants, which means these MCPs are well developed.

The comment that prompted me to try Chrome DevTools MCP

While Playwright MCP was working okay for me, I saw that Chrome DevTools was released after and wondered if it’s any better.

A comment from this thread (which I also linked in Cool MCP Servers) prompted me to try it: What MCPs are you using with Claude Code right now? : r/ClaudeCode

Question

What’s the advantage of chrome devtools vs playwright mcp?

Conclusion

Faster, more capable. Reads the console logs, and can execute scripts. The long screenshots are great too

I used to use playwright but Chrome dev tools blew me away

Guide: Using Chrome DevTools MCP

Claude Code

At the project level, run:

claude mcp add --scope project chrome-devtools npx chrome-devtools-mcp@latest

This configures the following in the .mcp.json file:

{
  "mcpServers": {
    "chrome-devtools": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest"
      ],
      "env": {}
    }
  }
}

Then simply open a new instance of claude and confirm that you trust the folder and MCP server. Run the /mcp slash command to verify that the MCP server appears as “✔ connected”.

To use the MCP server, I simply tell Claude something like “use chrome mcp to test and troubleshoot website x”. I would add more context depending on the specific task, but in general this is enough to let Claude know that it can use this MCP server.

Codex CLI

The Codex CLI sandbox makes working with Chrome DevTools MCP more challenging, though I managed to make it work (Source: Connecting to a running Chrome instance | ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents).

Run the following command:

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --browser-url="http://127.0.0.1:9222"

In addition, if live websites need to be tested, allow network access by adding the following lines to the global Codex config:

[mcp_servers.chrome-devtools] 
command = "npx" 
args = ["chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"]

[sandbox_workspace_write] 
network_access = true 

Now, every time we want to use Codex CLI with Chrome DevTools MCP, we must first run this command in the background:

nohup /usr/bin/google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug-headful --no-first-run --disable-gpu about:blank >/tmp/chrome-launch.log 2>&1

Gemini CLI

At the project level, run:

gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest

This configures the following project settings:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest"
      ]
    }
  }
}

Other MCP clients

Follow the instructions in MCP Client configuration | ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents.

Featured image by Growtika on Unsplash.

Oxc Workflow

2025-11-10T00:00:00Z

Here’s how I like to setup new Node.js projects, with linting and formatting using Oxc.

Oxc

I wrote about Oxc (The JavaScript Oxidation Compiler) in Next Generation Tooling for Developers. When I first wrote this article, Oxc already included a linter (oxlint, which can replace ESLint), but the formatter was not available yet. Since then, VoidZero has continued the development of Oxc, not only launching Vite+ but also launching a formatter (oxfmt, which can replace Prettier). With the combination of oxlint and oxfmt, I now have a modern-alternative to ESLint + Prettier. Note that this might not work as a replacement in all existing projects that rely on specific configurations of ESLint and/or Prettier. However, for new Node.js projects, I will strive to go with the Oxc stack.

Why Oxc instead of ESLint + Prettier?

The two main reasons I prefer Oxc is speed and ease of configuration; as I have explained in Next Generation Tooling for Developers, the Rust-based tools are noticeably faster. In addition, they have a more modern design with more intutive configuration. In particular, ESLint has become a nightmare to configure after the breaking changes in ESLint v9.

Guide

One-time run

These tools can be run in a project without being installed or added to package.json using npx commands:

npx oxlint@latest

npx oxfmt@latest

Install Oxc tools in NPM project

For consistent usage in an npm project, Oxc packages can be added as devDependencies.

npm install --save-dev oxlint@latest oxlint-tsgolint@latest oxfmt@latest

Initialize configuration for oxlint

Quote

Configuration files for Oxlint are written in JSON, with support for comments (JSONC). Oxlint will automatically search for files named .oxlintrc.json and automatically use those. But you can name the file anything when you are using the --config CLI option.

Configuring Oxlint | The JavaScript Oxidation Compiler

Use the --init option to initialize a .oxlintrc.json file:

## If installed
./node_modules/.bin/oxlint --init

## If not installed
npx oxlint@latest --init

Initialize configuration for oxfmt

Quote

By default, oxfmt automatically tries to find the nearest .oxfmtrc.json or .oxfmtrc.jsonc file from current working directory. If not found, default configuration is used.

Also you can specify your config file by -c yourconfig.jsonc flag.

Almost all format options are compatible with Prettier’s options. So you may finish your setup by just renaming .prettierrc.json to .oxfmtrc.jsonc.

Formatter | The JavaScript Oxidation Compiler

Use the --init option to initialize a .oxfmtrc.json file:

## If installed
./node_modules/.bin/oxfmt --init

## If not installed
npx oxfmt@latest --init

A previous version of this article, suggested to use prettier-init (before oxfmt had the --init option).

Lima and Colima

2025-10-16T00:00:00Z

Today I learned about Lima and Colima, which help run Linux VMs and containers on macOS.

I learned about these tools while writing How To Install Docker. Although I’ve heard about them in the past, I kept forgetting what they were called, which is one reason I am writing about them now.

Lima

Lima launches Linux virtual machines with automatic file sharing and port forwarding (similar to WSL2).

Lima: Linux Machines | Lima

As this description states, Lima is similar to WSL. When using Windows, I have gotten used to a workflow based around WSL, both for Docker and with Git. I have not used macOS yet but expect to one day get a MacBook as a work laptop, and will have to learn an effective workflow for macOS.

Colima

Colima - container runtimes on macOS (and Linux) with minimal setup.

GitHub - abiosoft/colima: Container runtimes on macOS (and Linux) with minimal setup

Differences between Lima and Colima

How does Colima compare to Lima?

Colima is basically a higher level usage of Lima and utilises Lima to provide Docker, Containerd and/or Kubernetes.

colima/docs/FAQ.md at main · abiosoft/colima · GitHub

“How does Lima relate to Colima?”

Colima is a third-party project that wraps Lima to provide an alternative user experience for launching containers.

The key difference is that Colima launches Docker by default, while Lima launches containerd by default.

Colima (third-party project) | Lima

It’s worth noting that current versions of Lima also support using Docker as a container runtime, and the same is true the other way: Colima supports using containerd as a container runtime.

Installation

Install Lima

Installation | Lima

Example

# Homebrew
brew install lima

# MacPorts
sudo port install lima

# Nix
nix-env -i lima

Install Colima

Colima is available on Homebrew, MacPorts, and Nix. Check here for other installation options.

Example

# Homebrew
brew install colima

# MacPorts
sudo port install colima

# Nix
nix-env -iA nixpkgs.colima

Using Docker with Lima and Colima

Docker with Lima

Documentation / Examples / Containers / Docker | Lima

Lima Docker Rootless

limactl start template://docker
export DOCKER_HOST=$(limactl list docker --format 'unix://{{.Dir}}/sock/docker.sock')
docker run -d --name nginx -p 127.0.0.1:8080:80 nginx:alpine

Lima Docker Rootful

limactl start template://docker-rootful
export DOCKER_HOST=$(limactl list docker-rootful --format 'unix://{{.Dir}}/sock/docker.sock')
docker run -d --name nginx -p 127.0.0.1:8080:80 nginx:alpine

Docker with Colima

Docker client is required for Docker runtime. Installable with brew brew install docker.

You can use the docker client on macOS after colima start with no additional setup.

brew install docker
colima start

Linux Support

Both run on Linux hosts. Lima also supports non-macOS hosts (Linux, NetBSD, etc.) and Colima’s README lists Linux as supported.

There’s less reason to use Lima/Colima on Linux than on macOS, but it may still be useful in certain cases, since it is another way to run VMs on Linux.

Apple Container

After years of mac users using projects such as Lima, Colima and others in order to run containers on macOS, Apple released their own solution a few months ago: Container. This seems like a good solution that likely has good performance. Notably, this solution is not based on Docker, but can nevertheless run OCI containers.

Featured image by Aarom Ore on Unsplash.

Next Generation Tooling for Developers

2025-10-12T00:00:00Z

In recent months I have been learning about Astral: High-performance Python tooling. I first learned about Astral’s tools from this article: I’m Switching to Python and Actually Liking It and have started using uv and ruff. This led me to try to find similar tools for other languages.

What makes a tool “next generation”?

Note

I am not focusing on AI tools in this article. I have other articles on this subject (such as Agentic CLI Tools Comparison).

The projects below have a few things in common. The projects are led by companies which have similar missions to develop modern tooling for developers. All of the tools below are open-source under the MIT License.

Most of the tools are written in modern compiled languages such as Rust or Go. Many of the tools boast significant performance improvements compared to previous tools, as well as a more modern design with better Developer Experience (DX or DevEx).

As a result, these tools tend to feel both faster and easier to use than the tools that they aim to replace.

Toolsets

Python

Astral: High-performance Python tooling

Astrals’s Mission

Quote

Astral’s Mission

We build high-performance developer tools for the Python ecosystem.

Our mission is to make the Python ecosystem more productive.

By building tools that enable developers to ship great software, faster.

Tools that change how we work.

About | Astral

Astral’s Projects

uv (Docs | GitHub): An extremely fast Python package and project manager, written in Rust.
ruff (Docs | GitHub): An extremely fast Python linter and code formatter, written in Rust.
ty (Docs | GitHub): An extremely fast Python type checker and language server, written in Rust.
python-build-standalone (Docs | GitHub): This project produces standalone, highly-redistributable builds of Python. Used in uv.

Note

Rye is another tool that was maintained by Astral, however it is no longer developed and uv is considered “the successor project from the same maintainers”.

JavaScript/TypeScript

VoidZero | Next Generation Tooling for the Web

VoidZero’s Mission

Quote

The Mission

We are building a unified high-performance toolchain for JavaScript: including parser, transformer, resolver, linter, formatter, minifier, bundler, test runner, and meta framework support. Our mission is to make the next generation of JavaScript developers more productive than ever before.

VoidZero | Next Generation Tooling for the Web

VoidZero’s Projects

Vite (Website | GitHub): The build tool for the web.
Vitest (Website | GitHub): Next generation testing framework powered by Vite.
Rolldown (Website | GitHub): Fast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.
The JavaScript Oxidation Compiler (Oxc) (Website | GitHub): A collection of JavaScript tools written in Rust.

ByteDance Web Infra Team

Web Infra’s Mission

Quote

Web Infra

We are from ByteDance, our goal is to build an open technical ecosystem to promote the development of frontend technology.

Web Infra · GitHub

Web Infras’s Projects

Rspack (Website | GitHub): Fast Rust-based web bundler with webpack-compatible API.
Rsbuild (Website | GitHub): Zero-config build tool powered by Rspack.
Rspress (Website | GitHub): A fast Rsbuild-based static site generator.
Rsdoctor (Website | GitHub): A one-stop build analyzer for Rspack and webpack.
Rslib (Website | GitHub): Create JavaScript libraries in a simple and intuitive way.
Rstest (Website | GitHub): The testing framework powered by Rspack.
Rslint (Website | GitHub): High-performance JavaScript and TypeScript linter written in Go.
Midscene.js (Website | GitHub): AI Operator for Web, Android, Automation & Testing.
Modern.js (Website | GitHub): Progressive web framework based on React and Rsbuild.
Garfish (Website | GitHub): Powerful micro front-end framework.

Business Model

All of the tools mentioned above are primarily developed and maintained by companies. This raises the question, if the tools are FOSS (Free and Open Source), what are their business models?

ByteDance of course owns TikTok. They make enough money already and can afford contributing to open-source if they so chose. My theory is that ByteDance likely wants to continue contributing to open-source to put them in the same positive light as Western tech companies (for example Meta, who developed many open-source projects including React, Docusaurus and Llama).

On the other hand, Astral and VoidZero are both venture-backed. While they can afford to lose money for a period while gaining users, eventually they will want to find a way to extract value. In the past, when the founders of the companies were asked about this, they gave somewhat vague statements.

However, more recently, Astral introduced pyx (a Python-native package registry):

Quote

Beyond the product itself, pyx is also an instantiation of our strategy: our tools (uv, Ruff, ty, etc.) remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we’ll offer paid, hosted services like pyx that represent the “natural next thing you need” when you’re already using our tools: the Astral platform.

pyx: a Python-native package registry, now in Beta

It is likely that VoidZero will go for a similar strategy in the future, by introducing paid services that go alongside the free tools.

The tools themselves are still FOSS, and all are licensed under the permissive MIT License. These companies know that if they ever attempt to change the license or terms for these tools, the community will immediately fork the projects (as has happened many times in the past with other open-source projects).

Note

UPDATE: VoidZero has launched Vite+.

My Experience

I have listed a lot of tools from these companies, of course I have not tried all of the tools mentioned above.
I have been using Astral’s projects, uv and Ruff, and had good experience with both, and I want to try ty as well. As I’m getting more into TypeScript development with React, Docusaurus and Cloud Development Kit (CDK), I have been trying out some of the TypeScript tools as well.
In the case of Docusaurus, I tried Docusaurus Faster which uses Rspack (by Web Infra), as well as SWC and Lightning CSS. This makes it almost as fast as Rspress (another project by Web Infra). The difference in build times is immediately noticeable compared to building Docusaurus with Webpack.
The speed difference is also felt in uv; compared to pip, uv downloads the same packages noticeably faster. I have further explained my love for uv in uv is incredible.
Ruff works well as both a Linter and Formatter. Ty does the same for type checking in Python.
Besides the speed, I have also noticed these tools tend to be easier to use than the older, less modern tools that the aim to replace. The focus on Developer Experience (DX or DevEx) is apparent.
Recently, I have been trying out TypeScript Linters and Formatters and wrote about the Rust Alternatives. Oxc looks promising, it currently has a Linter, while the Prettier-compatible Formatter is still under development. Once the Formatter is ready, I will try using Oxc (instead of ESLint + Prettier), at least for projects that don’t require specific ESLint plugins that aren’t yet supported by Oxc.

Note

UPDATE: oxfmt is now available and I have been using it in my projects alongside oxlint.

I wrote more about using Oxc in Oxc Workflow).

Vite

Out of all the projects I listed here, Vite is probably the most widely used. It’s popular enough to have gotten its own documentary: Vite: The Documentary - YouTube
I have been using Vite for React apps, notably CALMe. Ever since create-react-app has been deprecated, I have been consistently seeing Vite as one of the top recommendations, including in the React Documentation: Creating a React App and Build a React app from Scratch.
Vite is being integrated with Rolldown: Rolldown Integration | Vite

Featured image by Anton Savinov on Unsplash.

uv is incredible

2025-09-30T00:00:00Z

I have recently learned about uv and the uv workflow. Since then, I’ve been using uv a lot more, both for personal projects and at work!

uv is the best

Quote

My conclusion is: if your situation allows it, always try uv first. Then fall back on something else if that doesn’t work out.

A year of uv: pros, cons, and should you migrate

While reading more about uv, I found these two articles:

Production-ready Python Docker Containers with uv (Hynek Schlawack)
A year of uv: pros, cons, and should you migrate (Bite code! | Substack)

What’s interesting, is that these both of these articles each link to older articles where they each extensively compared tools for Python dependency management.

Python Application Dependency Management (Hynek Schlawack)
Why not tell people to “simply” use pyenv, poetry, pipx or anaconda (Bite code! | Substack)

The articles reach similar conclusions, in that the existing tools can be useful but have limitations. However, both articles have been updated to have disclaimers at the top:

Quote

This article is really old.

If you want to see how I manage my dependencies since 2024, the short answer is uv, and the long answers are:

Spoiler: Everything got pretty good.

Python Application Dependency Management (Hynek Schlawack)

Quote

THIS ARTICLE HAS BEEN WRITTEN BEFORE UV EXISTED. UV SOLVES MOST OF THOSE PROBLEMS. YOU CAN TELL PEOPLE TO “SIMPLY” USE UV.

Why not tell people to “simply” use pyenv, poetry, pipx or anaconda (Bite code! | Substack)

As far as I am aware, the authors were not inspired by each other. They both tried to solve the problems of Python dependency management, found the previous tools lacking, and now love uv.

My Opinion

I have personally not compared every single Python dependency management tool, but do give weight to the opinion of those who have. In the past, I have heard about tools like virtualenv, pyenev, poetry and others, and decided to simply stick with pip and venv. However, after hearing increasingly good things about uv, I decided to try it myself. I have now used it for several projects, both work and personal projects. My conclusion: it’s good.

I don’t know if I will be using uv for every project. As good as uv is, I am still sometimes hesitant to add a new build dependency. I also had some concerns about the venture-backed nature of uv (which I addressed in when writing about the Business Model in Next Generation Tooling for Developers).

At the same time, uv works really well and is even fun to use, so I’ll probably trend towards using it more often than not. The fact that the tool is open source and strives to conform to Python PEP standards also makes me feel comfortable using it. For example, uv works with pyproject.toml. In theory, I could replace uv with another tool in the future but still use the same file. I looked at what it takes to use pyproject.toml on its own and found this article: Python packages with pyproject.toml and nothing else | Simon Willison’s TILs. This shows me that it’s possible to work this way without using a tool like uv, however using uv makes things much easier!

Featured image by Point Blanq on Unsplash.

Agentic CLI Tools Comparison

2025-09-28T00:00:00Z

GitHub Copilot CLI is the latest Agentic CLI tool. Yet another Agentic CLI tool in the same style of Claude Code, Cursor CLI, Gemini CLI, Codex CLI and Qwen Code (and probably others that I am forgetting). So far I have tried all of these except for Qwen, and am now trying GitHub Copilot CLI as well.

All Agentic CLI tools look the same

All of these tools are superficially similar. Claude Code, GPT-5, Cursor CLI, Gemini CLI, Qwen Code and now GitHub Copilot CLI all have a TUI design that looks almost exactly the same, not even trying to hide that they’re copying each other. The notable exception is Codex CLI, which has its own TUI design. Honestly though I find Codex’s TUI to be inferior and kind of wish it also copied the others. I think the common design works well and don’t mind it, it’s just funny that all of these companies copy each other.

Another thing that is similar is that all these tools have npm as their primary installation option. While most tools can also be installed in other ways (such as Homebrew), npm is usually recommended first in their respective README files. Of course, npm has been widely-used for years and many developers already have it installed (these tools are primarily for developers, though they can do more than coding); however, I’ve personally never before seen npm recommended as the primary installation method before this wave of Agentic CLI tools started. Some of the tools are written in TypeScript so it makes sense. On the other hand, there’s Codex CLI, which has its own design and is written in Rust, but nevertheless adapted to work with npm (TIL Rust binaries can be distributed on npm).

Agentic CLI tools have differences

I mentioned these tools are superficially similar, however that doesn’t mean they all work the same. Outside of design and installation method, there’s the matter of functionality and how well these tools actually work. Differences include:

Model

Some tools are designed to work with one companie’s models. Claude Code of course uses Claude Sonnet and Claude Opus. OpenAI’s Codex CLI uses GPT-5 models (including GPT‑5-Codex). Gemini CLI uses Gemini 2.5 and 3 (Pro with a fallback to Fast). Other tools support a variety of different models through one service, for example Cursor CLI and GitHub Copilot CLI (the same is true for their non-CLI offerings). Others allow you to BYO (Bring Your Own) API keys (notably OpenCode).

Tools & Agentic Abilities

Even when two tools use the same AI model, that doesn’t necessarily mean they will work the same. These tools have agentic abilities, enhanced with tools and prompts. Tools can built-in or provided with MCP. As an example, Claude Code has a wide variety of built-in tools that allows it to read and write locals files, browse the web (Search and Fetch websites) and more. On the other hand, while Codex Is Improving, it still does not have as many built-in tools as Claude Code. When tools are missing or limited, the gap can be bridged either with other CLI programs (that these agentic tools know how to run directly) or MCP servers. Most if not all of these tools support both running CLI commands and interacting with MCP servers. Notably, Cursor CLI now supports MCP as well (when I first tried it, Cursor CLI was missing MCP support).

License

Not all of these tools are open source. In a way that is somewhat deceiving, several of these tools have a GitHub repo that is little more than a closed-source LICENSE and README, but does not actually include any code. At present, this even includes GitHub Copilot CLI, which is marked as Public Preview and has Pre-release License Terms (it is not clear to me what the license terms would be after release). Claude Code and Cursor CLI are also closed source (others may have copied CC’s design, but not its code). Gemini CLI is open source and was later forked to Qwen Code, which is also open source (both Apache-2.0). OpenCode is also open source (as its name implies), under MIT. charmbracelet/crush (from the same people who created some of my favorite Go CLI and TUI Frameworks) uses this weird license: Functional Source License, Version 1.1, MIT Future License.

Pricing & Usage Limits

These tools have different limits.

Claude Code

Out of all of these tools I have (so far) used Claude Code the most and am most fimilar with their pricing and usage limits. I am using Claude Pro on the $20 a month plan. Claude Code also has the crazy expensive Max plans ($100 or $200 a month). I have mentioned previously in my Claude Code notes about my experience using the Claude Code $20 plan. My experience honestly haven’t changed much. While there was some drama about Claude Code changing usage limits, I still rarely run into usage limits. When I do, I have to wait at most a few hours for the usage limits to reset. In that time I can either use other tools or take a break. Other than not having access to the Opus model on CC, I don’t feel like I’m missing anything by not being on Max and am still baffled at how people justify the price of those Max plans. ccusage implies I use more than $100 a month, significantly more than what I pay. Anthropic either operates at a loss or can somehow afford to do that since it’s their own models.

Gemini CLI

Gemini CLI has a generous free tier and is what I currently recommend for people wanting to try an agentic tool for free. I’m not sure whether my Google AI Pro trial increases my Gemini CLI usage limits or if it’s unrelated, I’m honestly kind of confused with Google’s various AI plans (in typical Google fashion).

Note

UPDATE: Google AI Pro and Ultra subscribers now get Gemini CLI and Gemini Code Assist with higher limits.

Codex

Included with paid ChatGPT plans including Plus, Pro and Team.

BYO (Bring Your Own) API keys

Ironically, the FOSS tools such as opencode and crush might actually be more expensive in this case. When using an API key you have to pay the “real” cost of running the AI model which can end up significantly more expensive than a set plan. The same is true when using Claude Code with an API key instead of a plan; in all but very moderate use a plan would make more sense. Even the expensive Max plans often end up cheaper than what equivalent API use would cost.

My Opinion

Claude Code remains my most used agentic CLI tool. Neverthelss, I am still actively experimenting with other tools, I have used Gemini CLI increasingly more in recent weeks (Gemini’s free tier is really good), and am also trying Codex due to its improvements. However, while these tools feel similar in many ways and the competition is closer than ever, I still feel that Claude Code with Claude Sonnet 4.5 is noticeably better than all other tools that I have used. This may change in the near future as all of these tools are actively developed and new ones are introduced all the time.

This is in addition to other AI tools which I am also actively using. Right now I am mainly using the web and app versions of ChatGPT, Gemini, Claude and Perplexity Pro (I also use Microsoft Copilot at work, but it’s not very good).

Featured image by Steve Johnson on Unsplash.

GPT-5

2025-08-16T00:00:00Z

This Week I Learned about GPT-5

At the announcement post, OpenAI made some bold claims about GPT-5. Including:

The best response, every time

KYAML

2025-08-11T00:00:00Z

Today I learned, in Kubernetes v1.34, kubectl will also support a new strict subset of YAML called KYAML.

Resources

Shell Script

I coded a simple script to convert all Kubernetes manifests in a directory from YAML to KYAML.

Initially, I wanted to code my own converter, but then found out that the upstream Kubernetes project already has a new yamlfmt tool (different from google/yamlfmt).

#!/bin/sh
# kyamlify.sh — Rename *.yaml -> *.kyaml then format to KYAML (POSIX)
# Usage: ./kyamlify.sh [ROOT_DIR]
# Env: YAMLFMT_VERSION (default: master)

set -eu

ROOT_DIR="${1:-kubernetes}"
YAMLFMT_VERSION="${YAMLFMT_VERSION:-master}"

# Require Go
command -v go >/dev/null 2>&1 || { echo "error: Go not found in PATH" >&2; exit 1; }

echo "→ Installing yamlfmt @ $YAMLFMT_VERSION"
go install "sigs.k8s.io/yaml/yamlfmt@${YAMLFMT_VERSION}"


echo "→ Formatting all YAML files under ${ROOT_DIR} as KYAML"
find "${ROOT_DIR}" -type f -name '*.yaml' -print0 \
  | xargs -0 -n1 "$(go env GOPATH)/bin/yamlfmt" -o kyaml -w

KYAML Rules

Quote

KEP-5295 introduces KYAML, which tries to address the most significant problems by:

Always double-quoting value strings
Leaving keys unquoted unless they are potentially ambiguous
Always using {} for mappings (associative arrays)
Always using [] for lists

Support for KYAML: a Kubernetes dialect of YAML | Kubernetes v1.34 Sneak Peek | Kubernetes

These rules are similar in practice to JSON5. However, while JSON5 is a superset of JSON (as well as a subset of ES5), KYAML is a subset of YAML.

In fact, I suspect that by adding --- to the first line of a JSON5 file, it would be valid KYAML.

By the way, starting the file with --- is required for KYAML (while it’s optional in YAML).

Experimentation and Additional Observations

I was initially excited about converting all my Kubernetes manifests to the “safer” KYAML format.
I ran my script then followed it by running yamllint, which introduced a few warnings post-conversion.
After fixing all yamllint warnings, I had well-formatted KYAML files.
I considered whether to rename all converted manifest files to use a *.kyaml suffix. I decided against this since I couldn’t find any evidence of this file extension.
KYAML files are 100% valid YAML files, and work with existing tooling. This includes existing Kubernetes versions and tooling.
The main thing introduced with Kubernetes v1.34 is a kubectl get -o kyaml option.
Keeping the *.yaml file extension makes sense since KYAML is still valid YAML and existing tools expect *.yaml or *.yml file extensions, not *.kyaml
After running the script, fixing formatting, and deciding to keep the filenames the same, I could add all modified files in homelab-as-code to a new kyaml branch and make a commit.
I considered opening a Pull Request, however, am still undecided.
My main consideration is whether the KYAML format would impact usability, making it harder for me to write and edit manifests.
I am not sure whether KYAML solves any real problems for me.
I understand YAML limitations but know how to avoid them by quoting values when needed, using linting and formatting tools (manually, with pre-commitand in CI).

My Opinion on the Format

In a way, KYAML is itself “yet another markup language” (despite using existing YAML rules). It is far from the first solution to problems with existing markup languages.

One notable limitation of standarad JSON is no comments. Both JSON5 and Microsoft’s JSONC (JSON with comments, primarily used in VS Code’s setttings.json file) previously addressed this. KYAML has the benefit of being a subset of YAML and designed to work with all existing YAML tooling.

In theory, KYAML could be a “safer” way to write production-grade manifests. However, this was already possible to do with JSON files. Kubernetes manifests can all be written in JSON, but there is a reason that this is rarely done in practice.

JSON files are arguably less readable and harder to work with (for humans, not machines) than YAML. At the same time, JSON files are very much machine-parsable with a lot of existing tooling like jq (though YAML tooling exists as well).

In imitating JSON but staying YAML, KYAML can feel like the worst of both, rather than the best of both world. Not as clean as JSON, and not as “human-readable” as YAML.

Featured image by Marvin Meyer on Unsplash.

OpenAI o3 Review

2025-05-28T00:00:00Z

I’ve used o3 extensively, and I think it’s a really strong model compared to earlier ChatGPT models.

It doesn’t just “think”; it also does web research and cross-checks sources to reach a conclusion. Other ChatGPT models can browse too, but o3 digs deeper and pulls more sources (when I read its “thoughts,” it said it tries to fetch at least 10 sources).

This is similar to what Deep Research does, which makes sense because ChatGPT’s DR used the o3 model even before it launched. However, DR returns essay-length answers (and is limited to 10 uses per month on ChatGPT Plus), which isn’t always practical. o3 gives answers closer in length to the other ChatGPT models. There are Plus usage limits, but I had to use it quite a lot before hitting them.

The model “thinks” for several minutes before responding. Usually it’s worth the wait, except for simple questions another model could answer faster. For complex questions, o3 is often noticeably better. I tried tough coding prompts that 4o struggled with (confident answers with hallucinations), then asked o3 and got much better results. For bigger tasks I sometimes had to tweak the prompt a few times, but in most cases o3 eventually delivered (unlike 4o).

The model isn’t perfect. There are still hallucinations and mistakes. Neverthless, in my experience fewer than other models I’ve tried.

AI moves so fast that it’s hard to keep up. Last month o3 was probably the best model around, and now people say Gemini 2.5 has overtaken it. It takes time to use a new model enough to really understand its strengths and weaknesses.

I also played a bit with ChatGPT 4.5 and 4.1. I haven’t used them much yet and so far I’m less impressed.

I haven’t tried o4 or o4-mini-high yet. Assuming o3 is better, I’d rather wait a few minutes for deeper reasoning. For simpler questions I still default to 4o.

Featured image by Levart_Photographer on Unsplash.