Show HN: qqqa – A fast, stateless LLM-powered assistant for your shell
github.comI personally use "claude -p" for this
I have no interest in adding too many complex features. It is supposed to be fast and get out of your way.
Different philosophies.
https://github.com/github/gh-copilot/commit/c69ed6bf954986a0...
Why is there a flag to not upload my terminal history and why is that the default?
It does not support chaining multiple tool calls - if it did, it would not be a lightweight assistant anymore, I guess.
The history is there to allow referencing previous commands - but now that I think about it, it should clearly not be on by default.
Going to roll out a new version soon. Thanks for the feedback!
So feature suggestions:
* Pipe data into qq ("cat /tmp/stacktrace | qq What is wrong with this: "),
* Profiles (qq -profile legal-analysis Please checkout document X and give feedback)
* Conversations (this is simply appending a new message to a previous query)
[0]: https://github.com/baalimago/clai/blob/main/EXAMPLES.md
A little anecdote: a few years ago I published an open source library that for many years would go completely underappreciated. For a few years I did not even check it - and then one day I realized it had over 500 stars on GH (+700 today). Good things take time.
Appreciate the ideas!
Also, groq + gpt-oss is so much faster than Claude.
https://github.com/pchalasani/claude-code-tools?tab=readme-o...
It’s pretty basic, and could be improved a lot. E.g make it use Haiku or codex-CLI with low thinking etc. Another thing is have it bypass reading CLAUDE.md or AGENTS.md. (PRs anyone? ;)
Oh genius, that's the best UX idea for the situation of asking an LLM to flesh out the CLI command without relying entirely on blind faith.
Even better if we can have that kind of behavior in the shell itself. For example if we started typing "cat list | grep foo | " and then suddenly realized we want help with the awk command so that it drops the first column.
https://github.com/pmarreck/dotfiles/blob/master/bin/ask
I have a local version of ask that works with ollama: https://github.com/pmarreck/dotfiles/blob/master/bin/ask_loc...
And here is "please" as in "please rename blahblahblah in this directory to blahblah": https://github.com/pmarreck/dotfiles/blob/master/bin/please
https://gist.github.com/rbitr/bfbc43b806ac62a5230555582d63d4...
Is it possible to use an OpenAI-compatible API locally, or how does that work?
- it puts the command in the shell editor line so you can edit it (for example to specify filenames using the line editor after the fact and make use of the shell tools like glob expansion etc.)
- it goes into the history.
- It can use a binding so you can start writing something without remembering to prefix it with a command and invoke the cmd completion at any place in the line editor.
- It also allows you to refine the command interactively.
qqqa uses history - although in a very limited fashion for privacy reasons.
I am taking note of these ideas though, never say never!
Copying and pasting tends to be a very tedious operation in the shell, which usually requires moving your hands away from the keyboard to the mouse (there are terminals which allow you to quick-select and insert lines but they are still more tedious than simply pressing enter to have the command on the line editor). Maybe try using llm-cmd-comp for a while.
> I do not see how editing the command is a good tradeoff here in terms of complexity+UI.
I don't find it a tradeoff, I think it's strictly superior in every way including complexity. llm-cmd-comp is probably the way I most often interface with llms (maybe second to basic search-engine-replacement) and I almost always either 1. don't have the file glob or the file names themselves ready (they may not exist yet!) at the time when I want to start writing the command or they are easier to enter using a fuzzy selector like fzf 2. don't want the llm to do weird things with globs when I pass them directly and having the shell expand them is usually difficult because the prompt is not a command (so the completion system won't do the right thing).
But even in your own demo it is faster to use llm-cmd-comp and you also get the benefit that the command goes into the history and you can optionally edit it if you want or further revise the prompt! It does require pressing enter twice instead of "y" but I don't find that a huge inconvenience especially since I almost always edit the command anyway.
Again, try installing llm-cmd-comp and try out your demo case.
OpenAI-compatible endpoint: https://ch.at/v1/chat/completions (supports streamed responses)
Also accessible via HTTP/SSH/DNS for quick tests: curl ch.at/?q=… , ssh ch.at Privacy note: we don’t log anything, but upstream LLM providers might...
How do you guys pay for this? I guess the potential for abuse is huge.
https://github.com/sigoden/aichat
Nevertheless it’s good to see more tools with the Unix philosophy!
it's inspired on F.R.I.D.A.Y. from the Marvel Cinematic Universe, a digital assistant with access to all of the (fictional) hardware.
It's a simple shell script of 204 lines.
Since I launched it yesterday, I added a few new features - check out the latest version on Github!
Here is what we have now:
* added support for OpenRouter
* added support for local LLMs (Ollama)
* qqqa can be installed via Homebrew, to avoid signing issues on MacOS
* qq/qa can ingest piped input from stdin
* qa now preserves ANSI colors and TTY behavior
* hardened the agent sandbox - execute_command can't escape the working directory anymore
* history is disabled by default - can be enabled at --init, via config or flag
* qq --init refuses to override an existing .qq/config.json
I believe the best “worker” agents of the future are going to be great at following instructions, have a fantastic intuition but not so much knowledge. They’ll be very fast but will need to retain their learnings so they can build on it, rather than relearning everything in every request - which is slow and a complete waste a resources. Much like what Claude is trying to achieve with skills.
I’m not suggesting that every tool reinvent this paradigm in its own unique way. Perhaps we a single system that can do all the necessary state keeping so each tool can focus on doing its job really well.
Unfortunately, this is more art than science - for example, asking each model to carry out handoff in the expected way will be a challenge. Especially on current gen small models. But many people are using frontier models, that are slowly converging in their intuition and ability to comprehend instructions. So it might still be worth the effort.
That said, I rather use claude in headless mode https://code.claude.com/docs/en/headless
26 more comments available on Hacker News