michaelanckaert

I'm interested to learn more, do you have link?

Well I am using this release process myself (and a couple of friends), along with the auto update feature. So it is still self centered.

While I agree with you on the unsafe practices, let’s say this is closed source: what is different then? People download and run closed source apps all the time.

You’re absolutely right. I merely wanted to share my own story / tool and listed the link to be complete.

I didn’t release the source yet but plan on doing so.

Thanks for your feedback, I’ll fix that copy. I didn’t release the source yet but I plan on doing do.

I created my own “terminal multiplexer for AI agents” after trying out herdr.

For me (like for many others) tmux didn’t suit the multi agent workflow. Herdr then was too buggy in my experience.

My own tool, Jai, connects to multiple machines, handles multiple agents and enables agent to agent communication.

For those interested: https://michael.sinax.be/jai/index.html

There is still a "community" on platforms such as Mastodon, reddit, various repo's. But I don't think there is a single community that can be pointed to as "The Emacs community". This would also be "wrong" from a Libre Software point of view.

I understand your point of view, but as far as the Emacs community is concerned there is no problem.

Emacs is not an editor. Emacs is not an IDE. Emacs is a platform to develop your own tooling. Text is the main interface Emacs offers.

I don't speak for the Emacs community, there isn't even such a thing except maybe semi related groups that share viewpoints, usage and interests. But on the whole, I don't think the "Emacs community" is looking for users or is looking to attract users. At least not users who are looking for "text editor experiences" that mimic or take inspiration from VS Code and the likes.

Working on improving AI Nexus - my custom LLM frontend that exposes all AI Models in a single interface: https://getainexus.com/

I generally try to avoid adding external links as I found that those resources tend to get lost very fast. Of course, this is not always feasible, but whenever I can try to copy over the contents into my notes.

This is great! We need more ASCII games/simulations and it's only a bonus if it's in Emacs :-)

Do you mind sharing your contact / shop? Email in profile if you don't want to share publicly.

I often use DuckDuckGo in HTML mode (https://html.duckduckgo.com/html/) when I'm using EWW in Emacs.

I agree that there is a steep learning curve compared to Github pull requests or Gitlab merge requests, but like many things the steep learning curve actually hides a very powerful tool. A famous example is the Linux Kernel, a project of such a size that simply can not work with the Github/Gitlab model.

Personally I find the information density of text to be the "killer feature". I've tried voice interaction (even built some AI Voice Agents) and while they are very powerful, easy to use and just plain cool, they are also slow. Nothing beats skimming over a generated text response and just picking out chunks of text, going back and forth, rereading, etc. Text is also universal, I can't copy-paste a voice response to another application/interface or iterate over it.

My personal view is that the search for a better AI User Interface is just the further dumbing down of the humans who use these interface. Another comment mentioned that the most popular platforms are people pointing fingers at pictures and without a similar UI/UX AI would never reach such adoption rates, but is that what we want? Monkeys pointing at colorful picture blobs?

Sure to protect your machine, but what about data security? Do I want to allow unknown code to be run on my private/corporate data?

Sandbox all you want but sooner or later your data can be exfiltrated. My point is giving an LLM unrestricted access to random code that can be run is a bad idea. Curate carefully is my approach.

Correct, I wouldn't use it myself as it's a trivial addition to your implementation. Personally I keep all my work in this space as provider agnostic as I can. When the bubble eventually pops there will be victims, and you don't want a stack that's hard coded to one of the casualties.

I was referring to letting LLM's search github and run tools from there. That's like randomly searching the internet for code snippets and blindly running them on your production machine.

^ this. Careful design of what tools are passed when is key to good agent design.

Security nightmare inbound...

The example given by Anthropic of tools filling valuable context space is a result of bad design.

If you pass the tools below to your agent, you don't need "search tool" tool, you need good old fashion architecture: limit your tools based on the state of your agent, custom tool wrappers to limit MCP tools, routing to sub-agents, etc.

Ref: GitHub: 35 tools (~26K tokens) Slack: 11 tools (~21K tokens) Sentry: 5 tools (~3K tokens) Grafana: 5 tools (~3K tokens) Splunk: 2 tools (~2K tokens)

The "Tool Search Tool" is like a clever addition that could easily be added yourself to other models / providers. I did something similar with a couple of agents I wrote.

First LLM Call: only pass the "search tool" tool. The output of that tool is a list of suitable tools the LLM searched for. Second LLM Call: pass the additional tools that were returned by the "search tool" tool.

Don't give anyone any ideas. We now have SEO, GEO, AEO and now TEO? :-p

And Emacs. Sure Elisp isn't the best lisp around (Personally I would give that title to Common Lisp), Emacs is a good Lisp environment.

Sending the whole context on each user message is essentially what the model remembers of this conversation. ie: it is entirely stateless.

I've written some agents that have their context altered by another llm to get it back on track. Let's say the agent is going off rails, then a supervisor agent will spot this and remove messages from the context where it went off rails, or alter those with correct information. Really fun stuff but yeah, we're essentially still inventing this as we go along.

I didn't glace at it, I read it :-) The architecture is a 'unified memory bus', so yes the GPU has access to that memory.

My comment was a bit unfortunate as it implied I didn't agree with yours, sorry for that. I simply want to clarify that there's a difference between 'GPU memory' and 'system memory'.

The Frame.work desktop is a nice deal. I wouldn't buy the Ryzen AI+ myself, from what I read it maxes out at about 60 tokens / sec which is low for my use cases.

Qwen has some really great models. I recently used qwen/qwen3-next-80b-a3b-thinking as a drop-in replacement for GPT-4.1-mini in an agent workflow. Cost 4 times less for input tokens and half for output, instant cost savings. As far as I can measure, system output has kept the same quality.

You need memory on the GPU, not in the system itself (unless you have unified memory such as the M-architecture). So we're talking about cards like the H200 that have 141GB of memory and cost between 25 to 40k.

oooh, nice burn ^^

Is working than 60 hours a week necessary to have a good team? Sure, having FU$ as you put it removes the necessity to keep the scale of your work life balance tipped to the benefit if your employer. But again, a good work life balance should not imply erosion the team.

Virtual Staging with AI for real estate!