[OC] I was tired of AI tools breaking my terminal workflow, so I built a pipe-friendly CLI that acts like a standard Unix filter (with .git-like state isolation). It's brand new and I need your harsh feedback.

Posted by CatTwoYes@reddit | linux | View on Reddit | 9 comments

Hi r/linux,

I know this sub is generally (and rightfully) exhausted by the endless wave of "AI wrappers" that try to take over your entire system, force you into clunky web UIs, or dump massive global configs in your home directory.

I felt the same way. I wanted to use LLMs for daily dev tasks, but I didn't want a heavy "co-pilot". I wanted a standard, dumb pipe that I could chain with grep, awk, and jq.

So I built Huko.

It’s an open-source CLI tool designed strictly around the Unix philosophy: do one thing, take stdin, and spit out stdout (or JSON).

Here is what makes it fit for a proper Linux environment:

Pipes all the way down: It just reads and writes text. You can drop it into any bash script. cat /var/log/syslog | grep "error" | huko "summarize the root cause" > report.txt
State isolation via .huko/: Context bleed is terrible. Instead of a global daemon, Huko scopes its memory and sessions to the current working directory using a hidden .huko/ folder (exactly like how .git/ works). You cd in, it remembers the project context. You cd out, it's a clean slate.
Controlling the blast radius: Giving an LLM access to bash is a security nightmare. Huko has built-in regex gating (huko safety deny bash 're:^rm -rf'), scrubs secrets before they leave your machine, and can execute destructive commands inside an isolated Docker container (huko docker run).
Two Gears (Lean vs. Full) & Algorithmic Compression:
Lean Mode: For quick, one-off pipeline filtering, it runs with a tiny \~400 token overhead. Zero ceremony.
Full Mode: For complex, multi-step execution, it brings in robust task planning and full tool orchestration. To prevent massive context bloat during long sessions, it uses a pure-algorithmic compression strategy (inspired by Manus) to prune the context tree locally. No slow, expensive LLM summarization loops—just fast, zero-overhead algorithmic pruning.
Proof of concept: Full mode's planning is solid enough that a significant portion of Huko's own codebase was actually written, debugged, and refactored by Huko itself.

The Reality Check (Why I'm posting here):

Huko is a brand-new release (v0.x).

Even though it successfully bootstrapped part of its own codebase, let's be real: running in my solitary environment is different from surviving the wild. It has rough edges, the architecture might have blind spots I haven't considered, and there are almost certainly edge cases in local file handling or standard I/O streams that will break it.

I'm posting here because I want raw, unfiltered feedback from Linux power users.

Does this approach to state management actually make sense to you?
Are there glaring security holes in how I handle regex gating?
Tear the architecture apart.

If this sounds mildly useful, I’d be honored if you tried to break it. Contributions, issues, or just telling me why this is a terrible idea are all highly welcomed.

Repo:https://github.com/alexzhaosheng/huko
Site:https://huko.dev(It’s just NPM install and go).

Thanks for your time.

[-]

archontwo@reddit

Skimming the code there seems to be a lot of focus on setting up external sites like deepseek, openai, and claude as api services. Less emphasis, or even documentation how to set it up with a local LLM instance, not necessarily on the same machine but certainly on a host the machine can reach locally.

The whole point of leveraging models the right way is to bring as much of the context down to your level which is where trained models will thrive on user generated data sets.

Consider adding documentation and a clearer path how to do that, please.

Otherwise, interesting, but personally not my jam.

[-]

CatTwoYes@reddit (OP)

thanks for your suggestion

Fair point, and honestly? That’s on us. Our docs definitely lean too hard into the "cloud-first" vibe, and we totally missed the mark there.

For the record, huko plays nice with anything OpenAI-compatible. If it’s got a /v1 endpoint (Ollama, LM Studio, vLLM), it works right now:

Bash

# Quick Ollama setup
huko provider add ollama --base-url http://localhost:11434/v1 --protocol openai --api-key ollama
huko model add my-local-model --provider ollama --api-model-id qwen2.5-coder:32b
huko model current my-local-model

You’re right that this is invisible in the README. I'll fix that this week—I'm adding a "Local LLM" section with quickstarts and a breakdown of which local models actually have the chops for agentic tool-calling.

[-]

archontwo@reddit

Fairy nuff. I know sometimes edge cases are overlooked but as a long time Linux user part of its appeal is to do what you see on the internet but for yourself respecting not only privacy but sovereignty as well. It is my data, my rules.

Thanks for taking time to reply. I've book marked the project and will investigate it more when I have time.

[-]

SoilMassive6850@reddit

This is not OC as you call it, rather it is entirely generated based on existing work. Go away.

[-]

CatTwoYes@reddit (OP)

"That’s a bold claim. If you think this is 'entirely generated based on existing work,' show the source. I'm happy to discuss specific evidence."

[-]

never_inline@reddit

Your AI sloap wall of text aside;

simon willison's (django creator) llm CLI does this since long time and supports multiple providers, image input, custom tools written as python scripts, etc...

[-]

CatTwoYes@reddit (OP)

Haha, fair point on the wall of text. But look, you're listing features that both have. That’s not the real difference.

llm is basically: send prompt, get response, log to SQLite. You are the loop. You decide when to call it again.

huko is the loop. You give it the goal, and the agent decides what tools to hit and when it’s actually done. One’s a CLI wrapper; the other’s an agent runtime. Even Simon’s readme says it’s for "interacting with LLMs," not building agents. Different tools for different jobs.

[-]

SevSECKSY@reddit

note: you messed up the link for the site link.

[-]

CatTwoYes@reddit (OP)

thanks & fixed