OleksandrC

It looks like the Torment Nexus is already here. The design is very human.

Typical coding agents of today consume hundreds of MBs of RAM. Once you add GUI into the mix, that could easily slip into GBs. You might feel the difference, when you're trying to fit a capable local model into small amount of local RAM.

Even on 64 GB RAM machines you could easily get memory pressure on the system when trying to work with a chonky local model. Consider also resource-constrained cases like small VPS servers or SBC computers (like Raspberry Pi).

Ergonomics and features are included too here. The point is that these can coexist with small resource footprint.

I am the author of hax, yes.

If you are familiar with pi, then some of the key features listed on the GitHub page (and website) already illustrate substantial differences: hax is much smaller in footprint (I wouldn't even call pi "light-weight", really - heavy js runtime with a lot of dependencies), hax preserves native terminal scrollback (pi uses alt-screen fullscreen, or clears in some cases in differential mode), hax uses normal XDG dirs (pi uses ~/.pi), hax is extended out-of-process (pi suggests in-process plugins).

There are other differences in presentation, and in features (for example, hax has background bash invocation out-of-the-box). Not practical to list all of them.

If you're looking for an agent implementation that is light on resources, but prefer to work in a terminal, consider also hax (https://usehax.dev/). Less than 2 MB fully static Linux binary, few MBs of RAM use in runtime. Works great with local models also (auto-detects config from running llama-server), besides the usual cloud providers.

I've been having weird troubles with MediaTek MT7922 chip on Linux also, where sometimes Bluetooth would just die and will not recover until reboot. After researching the situation with agents, the conclusion seems to be that the firmware is buggy (which is a proprietary blob, so only MediaTek can fix it). There was a workaround - disable low-power/sleep state for this adapter - which helps, but is not great for a laptop (since it increases power drain).

And generally, if you check online, you'll see plenty of reports about problems with MediaTek. I've learned my lesson - just avoid MediaTek in general. Intel adapters seem much less problematic and better supported overall.

Looking forward to the eventual full jailbreak. Maybe sooner rather than later with all of the advanced AIs of today.

Nintendo recently banned my Switch 2 from accessing online services. This effectively turns it into a fancy brick, since you can't install any digital games or updates - only games on physical cartridges will work (without possibility of installing updates). This is despite both the console and all games being purchased legitimately. The only weird part is me being in Ukraine where there is no official Nintendo presence, and so I had to use US eShop (with PayPal and prepaid digital codes). Nintendo support is extremely unhelpful, they just say that "unauthorized transaction detected" or something like that, without offering any human review/appeal path.

It's one thing to reject a transaction in the eShop, it's another thing to permanently ban console for that. What a shit company with shit business practices. 0/10, would not recommend, would not touch anything Nintendo-related ever again without a jailbreak.

(author passing by) Could you please report the issues you've experienced on the repo? I did quite a bit of testing myself on local models (Qwen, Ornith, Gemma, Muse Glimmer) with llama.cpp, and they all worked fine. Details would be helpful.

Also one brief note for Codex users specifically. hax can work out-of-the-box as codex-cli drop-in replacement (since it can use the already authenticated codex token), so it's super easy to try it - basically it will be a zero-config experience.

For people who find interest in weird web applications, I have been working on a game project, in C++, where the client is compiled to WebAssembly with Emscripten, and the application server is also implemented in C++ (behind nginx).

This is from pre-AI era also. The game is Civ-like. Custom engine from scratch (including both the 3D stuff, and all the web handling also).

Take a look: https://statebuilder.com/

Honestly, the provided argument for it is rather weak. They are basically adding a way of running scripts that are contained within harness to execute harness's own tools (that's the Codemode). A coding agent can already compose any arbitrary logic by invoking shell scripts (or python scripts, or node scripts), etc - so this is just entirely unnecessary in the core, from my perspective.

If you feel that Pi has been drifting away from its original vision, try hax (https://usehax.dev/) - you might like it.

If you're looking for a coding agent that would fit nicely into resource-constrained environments (such as laptops, or tiny VPS servers, or tiny single-board computers, etc), and would also work great with local models - you might also like hax (https://usehax.dev/). 0.7 MB dynamically linked native C binary, few MBs of RAM usage when running, auto-discovers config from running local llama-server, and uses minimalist system prompt and tools for lean context usage.

Technically, this would be straightforward. The problem is that Anthropic seems to be really against using Claude subscriptions with anything other than Claude Code - you might even risk your account getting banned for doing so. You could search online for the "openclaw claude banned" for more details on that story.

The obvious reason is that they would prefer to have CLAUDE.md files in every repo (even if it's just a symlink to AGENTS.md). It serves as a free advertisement for them. Same reason as for auto-adding attribution text in commit messages, etc. It's the "Sent from my iPhone" of our time.

If you like this list of "why?", you might also like this: https://usehax.dev/ (I am the author). Most of the list applies, similar minimalist Unix tool approach, with some differences. Hax is written in C, the dynamically linked binary is even smaller (0.6 MB), MIT-licensed. No wasm though.

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.

I am working on my own agent implementation (https://usehax.dev/), and I can praise OpenRouter for being seemingly the only provider endpoint that actually gives proper API for gathering available models and their capabilities (context length, image support, pricing, etc), reports exact routing details and total cost in the response, and provides an endpoint for obtaining current available credits (for "/usage"-like command). So for OpenRouter specifically I could deliver a really good experience out-of-the-box (always fresh models and metadata, exact pricing, etc).

You would think that these things would be standard fare, but they really are not. Other providers need metadata from a separate catalog, don't report pricing, don't really report available credits / usage either.

So yes, OpenRouter does have a good DevEx.

As usual, I suppose :) - by filing bug reports, and opening pull requests.

Generally, the models seem to adapt really well. I am using GPT models in hax a lot, and they have no trouble whatsoever using hax tools instead of their "native" codex tools.

Also since hax tools are just "read", "edit", "write", "bash" and "task_wait", it would be expected that the models would use one-off scripts to achieve their goals (either shell scripts, or python scripts, etc).

The main reason to use C is that it's the easiest way to achieve minimal resource footprint. Also it's the language I know really well already.

The demo was recorded with asciinema.

I will leave this here: https://usehax.dev/ GitHub repo: https://github.com/OleksandrChekhovskyi/hax

This is a coding agent implementation I am working on, which delivers what this promises (at least on the "lean" part), except it's actually fully open source, and even more lean (few MBs of runtime memory usage).

MIT-licensed, written in C, multi-provider / multi-model, minimalist approach to system prompt and tools (think kinda like pi, but with a bit more "batteries included", like subagents and background tasks out of the box), polished presentation, inspectable (usable transcript view), etc.

I am working on an agent implementation that you might like: https://github.com/OleksandrChekhovskyi/hax

Written in C, tiny footprint, minimalist approach to system prompt and tools (yet essential batteries are included, for example - it has subagents with presets, and background bash tasks out of the box), high quality polished presentation, inspectable (usable transcript view), does not mess with terminal scrollback, respects XDG directory spec, etc.

Open source, MIT-licensed, no commercial agenda. A tool that I myself wanted, so I built it.

This would be an interesting use case. But it seems API access is not included in the subscription? The value proposition would have been higher if it was (so one subscription for both human and agent use).

They could, for example: 1. Rely on users flagging suspected repos (with human moderators reviewing afterwards). 2. Deploying AI agents to evaluate repos against known AI-generated-code patterns (also with human moderators afterwards). Of course, the irony of the situation - using slop machines to fight slop.

Claude-written code is quite easy to spot - because it has this particular style of overly verbose "walls of text" comments, that 1. repeat verbatim what the code just below does, 2. include "list of things" that quickly go stale, 3. talk about "how things used to be before we changed it here" (useless to anyone reading the code now), 4. "talk to reviewer" in comments. And many other comment sins.

And even if you tell it to make it leaner, it'll maybe trim a little, but it'll still be a wall of text. Claude really likes to write its opuses and fables in comments.

And commit messages suffer from the same verbose prose.

And all of that happens even if you explicitly instruct in CLAUDE.md to keep things lean/concise. It's a disease.

Recent Kimi K3 release is supposedly frontier-grade, so would be interesting to see what it really costs to run inference for models of this class, when the weights get released and other independent providers pick it up (then we could reasonably expect competitive pricing with low-ish margins).

One significant advantage of Codex subscription over Claude is that you can use any agent harness with it. Meanwhile Anthropic insists that Claude subscription must only be used with Claude Code itself - and I have significant gripes with the quality of Claude Code in general.

Also, Fable access was now removed from small 20$ Claude plan, while Codex includes access to comparable model (gpt-5.6-sol) even on small subscription.

The article makes a point about agent harnesses being sticky (the supposed moat). I have been building my own agent harness for a while, and I can tell with confidence that the harness almost does not matter, the entirety of the AI magic is the model itself. The harness can be almost barebones (like, for example, mini-swe-agent used for benchmarks), and yet the model still does the task just fine.

So from my perspective, it's doubtful that this is the moat. Besides, for example, Claude Code in particular is so buggy (and always has been).

The article is rather light on "what to actually do about it". Even the basic "run it in isolated container without access to anything it does not need for the task" would have already improved the situation considerably (from the article it really seems like they didn't do that) - then the model would have to find local privilege exploits to actually escape (much cleaner misaligned behavior).

Also for typical normal use case for these smart models, you'd probably want an actual "max turns" limit to AVOID the pathological persistence (which in itself would be misaligned for "normal" tasks).

The code written by agents generally seems to reflect what you (the human driver) asked for. If you discuss the approach and architecture first, asking the right questions in the process, and then let it implement - the result is quite on point with the frontier models. Might need some minor touch-ups if agent missed some common conventions or guessed the expectations wrong (but again, salvageable with follow-up prompts). And when it comes to line-by-line logic within functions, I would argue that today's models are LESS likely to make a mistake in there than humans - especially if you cross-review with another model (e.g. "write with Claude, review with GPT").

Humans write slop too, you know. Just saying.