PicoClaw: Tiny, Fast, and Deployable Anywhere

PicoClaw is a 3MB command-line HTTP client (a tool for making web requests from your terminal) that I have been using for about two months, and I want to tell you about it. If you have ever wished curl (the classic command-line tool for fetching web content) had a few more modern conveniences without losing its soul, PicoClaw is the closest thing I have found. It is also written in Zig, which is a language I had not used before, and which I now think more people should know about.

Let me be clear about my bias. I have been using curl for 20 years. I do not have a problem with curl. I am writing this article because PicoClaw is genuinely different in a way that matters, not because I have a grudge against the original.

What it actually is

PicoClaw is a single binary that handles HTTP requests with a focus on being small, fast, and scriptable. The whole project fits in a 3MB download. It starts in under 50 milliseconds. It has a colorized, well-formatted output mode that is easier to read than curl -v. It supports HTTP/2 and HTTP/3 out of the box. It has a configuration file format that does not make me want to throw my laptop.

The project kicked off in late 2025 as a “what if I rewrote curl with modern defaults” experiment by a developer named Theo, who was frustrated with how much configuration curl requires for common tasks. The first version was a few hundred lines of Zig. The current version, 0.7.2, has matured into something I would use in production scripts.

The killer feature for me, the one that made me switch, is the request chain. You can define a sequence of requests in a YAML file, with the response of each one feeding into the next. This is something you can do with curl and a shell loop, but PicoClaw makes it declarative and inspectable.

The features I use every day

Here is what I have come to rely on:

• Colorized output by default. Responses are formatted with syntax highlighting (a JSON formatter, a YAML formatter, an HTML preview). No flags required.
• Request chaining. I have a pico.yaml file for my most common API workflows. One command runs the whole sequence.
• A real configuration file. You can save defaults, headers, and authentication in a config that is plain text and well documented. No more --header lines that scroll off the screen.
• Profile support. I have separate profiles for work, personal, and the staging environment for the project I help maintain. The right credentials show up automatically.
• Built-in JSON path queries. You can extract a value from a JSON response without piping to jq (a separate tool for processing JSON from the command line). For simple cases, this saves a step.
• WebSocket support. I have been using this to test a real-time notification system. No need for a separate tool.

Where it shines

I have used PicoClaw in three contexts that I want to describe.

API debugging was the first context I want to describe. When a webhook (a URL that receives data automatically when something happens in another system) is misbehaving, I need to see exactly what is arriving. PicoClaw’s request inspection shows the headers, the body, the timing, and the response in a single view. I can copy any of those to a file with one keystroke. This has saved me probably ten hours over the last two months.

Local development was the second context. I run a small set of local services, and I have a PicoClaw config that calls each of them in sequence and reports the response. If something is broken, the output tells me which step failed. Before PicoClaw, I had a Makefile (a file of build and run commands) for the same purpose, but the output was hard to read and the error messages were terrible.

Shell scripting is the third context. I have rewritten about six of my shell scripts to use PicoClaw instead of curl + jq + a few helpers. The scripts are shorter, the error handling is better, and I can read them six months later without re-learning what I was thinking.

What it does not do well

I have complaints, and I want to be honest about them:

• The Windows version is rough. I have not tested it personally, but several users in the Discord report issues with path handling and terminal color. If you live in Windows, you are better off with curl for now.
• The plugin system is not there yet. The roadmap mentions plugins, but the current version is what it ships with. If you need a feature that is not in the core, you have to write a wrapper script.
• Streaming downloads are not as memory-efficient as curl. PicoClaw buffers the response in memory before writing it. For very large files, this matters. For my use cases (mostly API responses under 10MB), it does not.
• The documentation is good but assumes you know HTTP well. There is no gentle “what is a header” tutorial. If you are new to this, the docs will not hold your hand.
• The YAML config format has a few quirks. Comments are not supported, and the syntax for environment variable substitution is not obvious. I have a cheat sheet taped to my monitor.

Trade-offs

Every tool has trade-offs, and PicoClaw is no exception:

• It is a one-maintainer project, again. Theo is the only full-time maintainer, and the project is funded by donations. If something happens to Theo or the donations dry up, the project could stall.
• The Zig library landscape is small. If you want to extend PicoClaw, you are working in Zig, and the available libraries are not as deep as Rust’s or Go’s. This is improving but it is a real factor.
• Some HTTP edge cases are not handled. I have hit two bugs in production, both related to specific header combinations. The fixes are in the issue tracker, but the release cadence is slow.
• The default output is colorized, which can break scripts that pipe to other tools. There is a --no-color flag, but I have forgotten it often enough to be annoyed.
• It is not as battle-tested as curl. curl has been around for 28 years. PicoClaw has been around for 8 months. The probability of hitting an obscure bug is higher.

Should you try it

If you are a developer who lives in the terminal and you have ever felt that curl was doing its job but you wished it was a little nicer, yes. PicoClaw will not change your life, but it will make your daily work feel slightly less friction-y, and that compounds over time.

System administrators running production scripts that need to work in five years should stay with curl. The maturity and the universality of curl are not things PicoClaw can match yet.

Beginners might find PicoClaw’s defaults more pleasant than curl‘s, but the documentation is not aimed at you. You might find it frustrating.

My honest summary: PicoClaw is a small, fast, well-designed tool that solves real problems for the kind of work I do. I have not uninstalled curl from my system, and I do not plan to. But PicoClaw is the first thing I reach for now, and that is a real shift.