Show HN: TERMy – A fast terminal assistant that does not use LLMs

Posted by gioscarab 4 days ago

22045Original

I love research and development, you may have heard of me because of PJON (Padded Jittering Operative Network). It is a network protocol I started developing in 2010, which was recently implemented in silicon by the ETH Zurich university thanks to the research of Pius Sieber.

I am excited to share with you TERMy, a terminal assistant built on top of the NPC-Forge framework. Unlike everything else being built today, TERMy does not use embeddings, machine-learning or LLMs. It runs on the CPU (even on a Raspberry Pi Zero) both in the terminal or client-side in a browser tab and responds in milliseconds. It is a cynical but very knowledgeable Linux terminal assistant that translates your natural language into shell commands without relying on a single artificial neuron.

I had a chance to focus for 2 months on my personal projects since early July, during the strange times of AI price hikes and the end of subsidized tokenmaxing. I was curious to see if I could develop from scratch a terminal assistant capable of handling simple natural language requests. I have a bad memory and got used to ask to copilot "activate the virtual environment" or similar trivial operations spending a non negligible sum every month. I started thinking, maybe I can do something to make my workflow more efficient? Do I really need trillions of parameters to accomplish those tasks?

How it Works

When you type a prompt, it goes through a lightweight NLU pipeline written in ~1000 lines of Python that implement the following steps:

1. Strip expletives, interjections, encouraging, discouraging and thanking words (remove noise)

2. Sentiment analysis

3. Exact Match (very fast)

4. Template Match (slower)

5. Probabilistic Match (even slower)

Step 5 relies on:

1. IDF (Inverse Document Frequency) to identify rare words.

2. BOW (Bag Of Words) to accommodate word inversions.

3. IDF weighted Levenshtein to safely handle typos.

Permission gating is hardcoded into the dataset and enforced for all potentially destructive commands, so it's inherently safer than letting an unpredictable LLM run wild on your machine.

- TERMy in operation: https://www.youtube.com/watch?v=qeIp0xePLBg

- Variance and typo tolerance: https://www.youtube.com/watch?v=tQvGDk6fkk0

- Copilot integration: https://www.youtube.com/watch?v=Wzzouhq2a8A

- Advanced features: https://www.youtube.com/watch?v=qeIp0xePLBg

- Source Code: https://github.com/gioblu/NPC-Forge

Comments

Comment by publlus_enigma 4 days ago

This is a cool project; I think it's wonderful that traditional NLP methods are being used, rather than reaching straight for an LLM.

One significant advantage of not using a local LLM is the significantly simplified dependency stack.

Comment by nateb2022 4 days ago

cf. https://github.com/TellinaTool/nl2bash

paper: https://arxiv.org/abs/1802.08979

Comment by gioscarab 4 days ago

Thank you very much for the link.

WOW! With that dataset the capabilities of TERMy could be vastly extended!

Thank you.

Comment by stefanka 3 days ago

Any similar data sets for coding?

Comment by mbil 4 days ago

It's kind of antithetical to the tool's deterministic positioning, but have you considered making TERMy leverage an LLM for unseen or low-confidence queries, and then generate the config and update itself to make future similar queries deterministic?

Comment by gioscarab 4 days ago

This is such a nice idea! I could add a fallback towards LLMs, it was present but I removed it. Would you be interested to help me implement the auto-update? I must admit, the LLMs are very useful for this kind of work. I think that TERMY's design is now feasible BECAUSE OF the availability of LLMs. They make the dataset development feasible.

Comment by dmos62 4 days ago

It would make sense to have this integrate with a self-learning routine for an agent: e.g. at night it looks through what it did and writes NPC-Forge recipes. Tomorrow it can answer queries (which he turned added to NPC-Forge) without an LLM. Of course this implies a branching where a query is either processed by NPC-Forge or an LLM, depending on some measure of confidence that NPC-Forge can answer it well.

Comment by gioscarab 4 days ago

Yeah would be a nice experiment, if you are interested to contribute to NPC-Forge please open an issue, I would be happy to discuss about that.

Comment by vegnus 4 days ago

If you could get Termy to code, you'd be a rich man

Comment by stefanka 3 days ago

That would be so amazing. Even if it just helped with repetitive or hard to remember patterns.

Comment by gioscarab 4 days ago

Hi, I am the creator, feel free to ask any questions :)

What do you think about it?

Comment by gurjeet 4 days ago

I haven't evaluated it yet, but I love the fact that the output is (at least claimed to be) deterministic. I can't trust an LLM to do the right thing after I deploy it to production, because their output is non-deterministic by design.

TERMy (or is it the NPC-forge) seems to be worth a try.

Comment by piterrro 4 days ago

You can get determinostic output (mostly) by setting the temperature to zero. Using couple of other tricks you can get close to 100% of determinism with LLMs.

Comment by jdiff 4 days ago

That's reproducible, I wouldn't call it deterministic. Small, semantically meaningless changes in the input can still result in wildly different output.

Comment by asQuirreL 4 days ago

That's the definition of a chaotic system (small change in initial conditions results in large, seemingly -- but not actually -- random changes in output), but it's still deterministic (same input results in same output).

Comment by kzrdude 3 days ago

I've long observed that kind of behaviour in google translate (which makes sense, they have been using ML for a long time.)

Comment by kouteiheika 4 days ago

> because their output is non-deterministic by design.

It isn't. At least not by design, even though in practice it often can be. If you do greedy decoding (or use a preset seed) and deterministically compute everything (e.g. only use integer math) then it will be 100% always deterministic.

Comment by kennywinker 4 days ago

That’s true, but not true-true. Sure, every time you prompt “what is the weather in kansas” you’ll get the same output, but if you prompt “what is the weather in kansas right now” you’ll get a different output, and then “what is the weather in kansas today” gets a different output. Language being language, there are infinite ways to say things, so there are infinite variations in what the llm can output in response to very similar prompts.

This tool has a finite amount of outputs for an infinite amount of inputs. Which is different from an llm based tool.

Comment by skeledrew 4 days ago

I think the point being made is that given a particular input string, you can get a deterministic output string back from the LLM.

Comment by kennywinker 4 days ago

Yes i think I acknowledged that, but is that useful for making a tool that can be trusted to safely run shell commands when asked arbitrary questions? No. It’s not.

Comment by tgv 3 days ago

Cool, but system and user should probably stick to short, clear commands. E.g., I see you do some anaphora resolution (in particular: find what "it" refers to), but in a complex dialog, the human intention can differ from the machine's understanding. That will give problems when you end your dialog with "delete it".

Adding more sentences to your data set will slowly degrade performance. It's a delicate system.

Source: I have written software with similar functionality (NLP search) in SaaS form, a long time ago. It required quite a bit of work to configure.

Comment by lna_stub 2 days ago

[flagged]

Comment by mpalmer 4 days ago

At first blush, it is a really persuasive compromise between full-on LLM inference and boring old fuzzy history search!

I really like it, this flavor of specialization gives the user a win on privacy and speed. Seems like the right idea for such a tool.

Comment by kouteiheika 4 days ago

> Models like ornith:9b, mistral:7b or cogito:14b can get the job done sometimes, but they are not fast and reliable enough for general use, specially if you have only 4GB of VRAM.

Have you considered/tried using a model that's, well, more appropriate size-wise for an use case like this? These are relatively big. Something like FunctionGemma [1] finetuned for a given set of tasks would be a lot more speedy.

[1] https://blog.google/innovation-and-ai/technology/developers-...

Comment by coder543 4 days ago

FunctionGemma never worked well for me (without fine tuning). Liquid has released 230M and 350M models that work far, far better in my testing: https://huggingface.co/LiquidAI/LFM2.5-230M

I really look forward to a hypothetical LFM3-230M, because LFM2.5-230M is so close to being usable, while FunctionGemma is miles away from being usable.

But, yes, still tangential to TERMy.

Comment by gioscarab 4 days ago

I tried functiongemma, it is for sure faster than those models, the problem is that is not reliable enough for a terminal assistant. I would say that no LLM is good for a terminal assistant, if you take into account the operational cost and the risk of damage. Even if it fails only 1 time out of 10 becomes useless. That's why I developed FlintParser!

Comment by kennywinker 4 days ago

https://github.com/ThorOdinson246/whatisit-nl2sh uses a finetune of Qwen2.5-Coder-1.5B-Instruct. It works pretty well, tho it will misunderstand things from time to time

Comment by utopiah 4 days ago

What dataset does step 5 rely on? Is it from your own terminal history, man pages, scrapped dataset from e.g. StackOverflow, sth else?

Comment by gioscarab 4 days ago

The dataset is here: https://github.com/gioblu/NPC-Forge/tree/main/npcs/termy/dat...

I hope the community will help me to enhance it :) it is just a proof of concept for now

Comment by 4 days ago

Comment by registereduser1 4 days ago

Cool project! How does it differ from warp terminals ai mode where you can ask it questions and it responds back

Comment by gioscarab 4 days ago

Warp uses LLMs so it is slow and prone to hallucination. Using very colloquial terms TERMy is more or less a calculator that knows english :) so it can run on your CPU and respond instantly! The difference is that it can only answer predetermined responses (with optional arguments) this makes it useless if you need to generate text, but makes it safe and predictable for a use case like a terminal assistant.

Comment by cyberclimb 3 days ago

is it supported to have it propose a command for approval rather than running autmatically? in the YT video it looks likw it ran the cpu temp command on its own

love the idea/simplicity of this tool!

Comment by gioscarab 3 days ago

Yep he runs on its own when the command is non-destructive, like checking the CPU temperature, it does ask for permission if the command is potentially destructive. I agree it is so cool, it looks sci-fi :)

Comment by Alpha3031 3 days ago

Very interesting project, I like it. Just wanted to clarify though the sentiment analysis is just the count of stripped words and used to tag things with the emoji? I was initially expecting it to be a part of the actual command construction process (even though I couldn't figure out how that would be relevant) given how it was listed.

Comment by gioscarab 3 days ago

Ciao, yes for now the sentiment analysis is used only to provide an emoji related to the response. In the future I would like also to influence the choices of adjectives and interjections according to the sentiment.

For now it is a bit of a gimmick I agree :)

Comment by _superposition_ 3 days ago

I'll be the first to admit I burn too many tokens on the command line. Some form of LLM harness has been my new shell for the past 3+ years, they are much better at *sh then me, and I prefer not context switching from my terminal when I don't have to. In a way the rise of agent harnesses and their shell expertise has opened up apis and command line tools which have always been pain points for a terminal user.

Great, simple idea applied in a novel way. Peak engineering if I ever seen it and I don't even have to look at the code. Nice work!

Comment by paguasmar 3 days ago

I like the project. I see a lot of potential integrating it with LLM providers in an effort to lower token usage for repetitive tasks. Your solution becomes the "main model" and the LLM the fallback

Comment by zserge 3 days ago

That's impressive! Seems like we're back to ELIZA again, only with a more versatile dataset format and better NLP/search

Comment by dsemakin 2 days ago

Just at the right time, will be trying this out. I see it as an addition to local LLM, where on a job cycle it can learn from the LLMs contexts and free it up and help it in the more complex work.

Comment by indigodaddy 4 days ago

So is this kind of like a super-powered tealdeer ?

Comment by gioscarab 4 days ago

tealdeer just shows you a cheatsheet, termy can effectively take a prompt and execute a command, example:

$ termy create file test.txt and write Hello

TERMy | template match | Confidence: 100.00%

Thinking: Ok, I am asked to create the file test.txt.

echo 'Hello' > 'test.txt' && termy_set_context 'active_file' 'test.txt'

Description: Writes Hello in file test.txt.

Response: Affirmative

Now that I think about it, I should let TERMy use tldr...

Comment by indigodaddy 3 days ago

Yes I think that would be a great idea!

Comment by analog_daddy 3 days ago

Yes tldr, navi cheatsheets are essentially a great set of how to do X using Y for terminal utilities. Pretty well curated set of commands for majority of the tasks, so are great training material. And great work! Love it

Comment by zem 3 days ago

what I would love to see along those lines is something that can answer "what packages do I have installed to do task $foo"; I keep installing things that I use for one thing and then forget about when I need to do the same task some months or years later.