- fx is a coding agent harness and CLI written in Zig, optimized for research and embeddability as part of larger systems.
- It focuses on minimalism and performance across the board, from system prompt design, to its tools, feature set, and 6.39mib binary.
- For end users, its CLI output style and form factor aims to be closer to a Unix shell than a heavy "IDE in the terminal" TUI.
- It's open source (Apache-2.0), model-agnostic, and suitable for both local and cloud inference.
- Designed for instant installation and embedding in resource constrained environments and agent sandboxes.
- fx cold starts in 10µs and does no unnecessary work or I/O prior to accepting user input, making it ideal for programmatic use.
- Optimal fx.wasm builds produced by the Zig toolchain, which further reduce fx's size, making the network stack pluggable.
- fx contributes single-digit megabytes of memory baseline, allowing you to pack many instances in one machine.
- fx preserves scroll history by default, produces minimal output, and makes sparing use of complex TUI or paints
- Minimal system prompt and tools, to save on token costs and to yield optimal time-to-first-token performance (TTFT).
- Small core, extended via skills, plugins, MCPs, with a Unix-like philosophy to extensibility.
- Designed to work with local models, gateways, direct provider API access or subscriptions.
Important difference - fx is currently Vercel AI Gateway only - while hax does support multiple providers already (OpenAI API, ChatGPT/Codex subscription, Anthropic API, OpenRouter, OpenCode Zen/Go), and integrates well out of the box with local llama-server.
Naturally meaningless when people carry around USB sticks that might even hold a 1 TB, but alas.
I don’t know if I am ready to use a new tool written in C and using libcurl but I will give it a shot.
I'm making something like Paseo and hax is very interesting as a Pi replacement.
OpenCode is the best behaved TUI i've seen by far (they invented OpenTUI to make it so good, also in Zig), so it feels less crucial. But it's nice to have there!
The "small core" model is very popular all of a sudden. DeepSeek's new harness is famously like that. https://news.ycombinator.com/item?id=49285244
OpenCode isn't quite as small, but there's very much been a deliberate attempt to drive much more into a plugin-based system. I enjoyed Dax talking about the new constitution of opencode, and the results of his agent comparing OpenCode & the new DeepSeek. https://bsky.app/profile/thdxr.com/post/3msy4gjttoc2f https://bsky.app/profile/thdxr.com/post/3msygiqyg6v2y
> an architectural change we made in opencode2 is nearly everything is an internal plugin / there's 68 of them that cover our built in agents, integrations, config loading, etc
i also think this is such a brilliant fun architectural twist too:
> OpenCode is the first time i could justify event sourcing in a real system / everything that happens is an event which gets projected into the sqlite db
https://bsky.app/profile/thdxr.com/post/3mt2qx3ktib2c
it's so fun seeing new malleable software cores emerge, try to figure out how to augment agency. agentic software striving itself to extend the agency it itself offers. it's been way too long since we've had ambitions to build general system, architectures that serve more than the user. this has held computing back for far too long. this is such an excellent interesting field, of such a more ambitious computing, opening up.
It is a branded "mee too" coding agent that we have seen hundreds of them already.
In particular, aiming to be embeddable into other projects seems rather notable. At least, not something I've remembered of other projects that have made there way across the HN front page.
This was written in zig and built by vercel. That’s the only notable characteristics about this project.
All code agents look the same and this one is no different.
I don't think Zig is that great of a language for this, but it's better than typescript. I don't want to use Vercel software so will pass, but would love to see a more community driven effort.
https://learn.chatgpt.com/docs/codex-sdk
https://code.claude.com/docs/en/agent-sdk/overview
https://pi.dev/docs/latest/sdk
or if you want SDK first, my recommendation is https://adk.dev/
I've actually been wondering lately why coding agent functionality isn't just... part of my shell already. Just another kind of interaction modality with an existing shell. Could probably even be an extension to fish or nu-shell even.
Please stop me from forking off on yet another project though.
With some ... intensive ... security/sandboxing/containerizing of some kind though, I guess.
Everything else in the harness is largely the same just Vercel-flavoured.
The portability benefit is also a bit over-sold imho. I wrote a harness in Go and it is as portable as this ... in fact it deploys straight into Vercel's own sandbox environment on demand without any issues.
That being said, did you say GLM 5.2 free? I need to look into that. GLM is remarkably capable model and that alone is worth using the harness in my books.
- written in rust, super fast startup and rendering
- implements token saving techniques
- plugins written in lua
No affiliation, just think it's a really well made piece of software.
I really love maki, its awesome!
I wonder why it's so large for a program written in Zig. It's basically just a loop that accepts user input, prepares the context, sends it to the LLM, parses the output, invokes the tools, and presents it all in the terminal. Add the built-in prompts and a few checks here and there (like blocking a write tool call before the file has been read first), and I'd expect a truly tiny native agent to be around 200-300 KB max.
In my own experiments to build a tiny zig agent it came out to under 800kb.
Given another commenter's mention of a similar project written in Nim that yielded a 1.6 MB binary, my first guess is that the 6 MB Zig binary simply isn't optimized for size - it might be a debug build. If not that, then I'm not sure what's happening, but yeah, in the context of Zig, 6mb for a CLI app is a bit strange.
I'm not sure harness is the right word either, but that seems to be what the industry has settled on so I'll concede on that, but surely the agent is the thing doing the work (which I guess is the model, or an instance of the model which is why agent is different?), whereas the harness is how the user interacts with the agent. We've had ways to describe that relationship before; client and server, frontend and backend, but again, I'll concede that the shiny new thing doesn't want to use boring old terminology, but I think some consistency and logic in the shiny new terminology is pretty important
That isn't specifically about fx of course, more of a general industry complaint
So its like, "GTA 6" as the disc vs. the specific game you're in the middle of being chased by cops, harness vs agent.
In practice they're intertwined and it becomes hard not to use the terms somewhat interchangeably, but "you ask the agent how the harness works" vs. the other way around, clearly.
And the virtual world of GTA 6 is actually your codebase/env, the cops chasing are the bugs/angry customers, etc. The harness is providing an accurate/efficient ability for the model to understand/interact with the virtual world, flee the cops, etc. Decomposed at various architectural boundaries per your taste, but that's like loading a skin on the engine.
Regardless though, this is what I mean, we now have 3 definitions for an agent; an instance of a model (which is how I think of it), a model configuration for a given task (from another commenter) and your definition which appears to be somewhere between the two, though it seems we agree with what a harness is.
- model
- harness (tools/config)
- agent (live/running)
https://googlecloudplatform.github.io/scion/concepts/
Scion allows for multiple configurations of a harness, allowing you to configure the same tool differently based on what you are doing, particularly important when you want to restrict permissions.
https://googlecloudplatform.github.io/scion/supported-harnes...
for the unfamiliar, Scion is an OpenClaw like platform from a Google dev, not supported or sponsored by the company
So you get a Cambrian explosion of weird little projects. Ultimately, one of them will probably become the "market" leader... or at least the market default.
Right now there's a lot of agent harnesses and sandbox projects floating about.
Fun examples from the past: text editors, window managers, IRC clients, blogging engines (first static, then dynamic, then static again), Twitter clients... every programming language community has weird clusters of library/framework duplication in their history...
Sometimes these projects take on a rite of passage flavour... like, as every Jedi builds their own lightsaber, every developer builds their own... blog? That used to be the obvious one. Less so these days.
The discussion around coding agents nowadays is steering towards harnesses (which is probably a better description of what this is). "Agent" here is doing a lot of heavy lifting and has become a bit of a catch-all term to describe a model + harness + tooling + prompt + some other things that I've probably not thought about. The harness is a part that's being explored more as many believe it's where we can get some better performance out of the models.
This one in particular is from Vercel who provide a service to use models, so they have a vested interest in providing a harness.
We haven't quite hit on the right formula yet, but people are very excited by the possibility.
Some models are just better at using tools than others.
It is widely known that upvote rings happen on this site.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
This submission has barely 50 votes.
To get started, sign in with Vercel:
fx login
in the README on Github.import json,sys;from subprocess import getoutput as sh;from urllib.request import Request as R,urlopen url=sys.argv[1];h=[];b=dict(model="gpt-5.6",input=h,tools=[dict(type="custom",name="sh")]) while p:=input("> "): h+=[dict(role="user",content=p)];H={"Content-Type":"application/json"} while True: o=(r:=json.load(urlopen(R(url,json.dumps(b).encode(),H))))["output"] h+=o;c=[i for i in o if i["type"]=="custom_tool_call"];z=r["usage"]["total_tokens"]/10500 if not c:print(o[-1]["content"][0]["text"],f'\n[{z:06.3f}%]');break h+=[dict(type="custom_tool_call_output",call_id=i["call_id"],output=sh(i["input"])) for i in c]
GLM 5.2 totally free even with a free Vercel account.
Make business sense too - fx is the entry point to bring more user to Vercel AI.
And every says it is the one :)
This binary is ~40kb and uses much less ram than fx.
The person who built this obviously has little understanding of harnesses.
You should have significantly less tools today with how good LLMs have become.
The start up time and binary size are quite literally the most useless stats to base a harness off of lol
Man what with Cloudflare, Vercel and all these tech companies just releasing pure slop.
Just use Pi. It's actually minimal and well thought out by people who actually understand agents.
I thought my `disc.sh` was good but this is better.
Zig is totally cool to do this in-- no shade intended by this.
1. Why do we need yet another coding agent over the rest of them?
2. Is this going to be another Vercel Labs slop project that they will abandon like the others since this is super experimental?