Oh, exciting. Ob-gptel https://github.com/jwiegley/ob-gptel

Agentic LLM use in Emacs using Model Context
Protocol (MCP) in org-mode with gptel
https://youtu.be/Hkih7jaqOnE?si=czWDmYqsT4NBYnNA

I like the .aider.prompt.org file. Sort of like a gptel chat buffer. I wish that it would post a summary of the interaction inside some kind of special summary block or drawer. Also I guess it would be neat to have aider as a model target in gptel.

Played around with a gptel chat buffer using a prompt to generate aider src blocks that I can execute to drive an active aider session. Fun stuff. Would be cooler if the block would return a summary of the charge instead of a direction to view the aider session.
#emacs #orgmode #gptel #aider #aidermacs
https://github.com/karthink/gptel
https://github.com/localredhead/ob-aider.el

gptel-org-tools

https://codeberg.org/bajsicki/gptel-org-tools

Small update. Largest change: added a per-file regexp option.

Conceptualizing flows that are missing.

One of the key problems that I run into consistently is that the #LLM will run tools that would blow up its context window, and then refuse to attempt to get to the entries other ways.

I need two things:
1. Find a way to get less irrelevant stuff from the query results.
2. Find a way to somehow get the results of the same query in chunks, if there's in fact many many results for a query.

Given that we're dealing with anything from a few words to an entire chapter of a book, it makes getting the relevant parts of each matching entry rather tricky.

Maybe I'd be able to use a regexp to pull out the paragraphs that contain the matches? I think that may work, possibly?

The second one... I'm not sure it's possible. The way things are, I'd have to get part of the query, have the LLM summarize it in a subroutine, and then do the second part, summarize, and only then feed it back to the "main" LLM to process it for whatever my request is.

I don't have the VRAM to do that, and I'm not sure if it's possible to make this happen using the hooks exposed by #gptel, since they'd need to be ran based on a tool result which then would prompt the LLM to run a tool which would then not return results until after it called an LLM (with intermediary tool calls happening) returned results and it processed them.

Man, English makes it difficult to express ideas. But basically, recursion.

In any case, yeah. Bit of a roadblock on this, will need thinking time.

Big hopes for Qwen3. IF the 30A3B model works well, gptel-org-tools will be very close to what I envision as a good foundation for the package.

It's surprisingly accurate, especially with reasoning enabled.

At the same time, I'm finding that #gptel struggles a lot with handling LLM output that contains reasoning, content and tool calls at once.

I'm stumped. These new models are about as good as it's ever been for local inference, and they work great in both the llama-server and LM Studio UI's.

Changing the way I prompt doesn't work. I tried taking an axe to gptel-openai.el, but I frankly don't understand the code nearly well enough to get a working version going.

So... yeah. Kinda stuck.

Not sure what next. Having seen Qwen3, I'm not particularly happy to go back to older models.

#emacs #gptelorgtools #llamacpp

gptel-org-tools update.

1. Cloned to https://codeberg.org/bajsicki/gptel-org-tools, and all future work will be happening on Codeberg.
2. Added gptel-org-tools-result-limit and a helper function for it. This sets a hard limit on the number of characters a tool can return. If it's over that, the LLM is prompted to be more specific in its query. Not applied to all tools, just the ones that are likely to blow up the context window.
3. Added docstrings for the functions called by the tools, so LLMs can look up their definitions.
4. Improved the precision of some tool descriptions so instructions are easier to follow.
5. Some minor improvements w/r/t function names and calls, logic, etc. Basic QA.

Now, as a user:
1. I'm finding it increasingly frustrating that Gemma 3 refuses to follow instructions. So here's a PSA: Gemma 3 doesn't respect the system prompt. It treats it just the same as any other user input.
2. Mistral 24B is a mixed bag. I'm not sure if it's my settings or something else, but it fairly consistently ends up looping; it'll call the same tool over and over again with the exact same arguments. This happens with other models as well, but not nearly as frequently.
3. Qwen 2.5 14B: pretty dang good, I'd say. The Cogito fine-tune is also surprisingly usable.
4. Prompting: I have found that a good, detailed system prompt tends to /somewhat/ improve results, especially if it contains clear directions on where to look for things related to specific topics. I'm still in the middle of writing one that's accurate to my Emacs set-up, but when I do finish it, it'll be in the repository as an example.
5. One issue that I still struggle with is that the LLMs don't take any time to process the user request. Often they'll find some relevant information in one file, and then decide that's enough and just refuse to look any further. Often devolving into traversing directories /as if/ they're looking for something... and they get stuck doing that without end.

It all boils down to the fact that LLMs aren't intelligent, so while I have a reasonable foundation for the data collection, the major focus is on creating guardrails, processes and inescapable sequences. These will (ideally) railroad LLMs into doing actual research and processing before they deliver a summary/ report based on the org-mode notes I have.

Tags:
#Emacs #gptel #codeberg #forgejo #orgmode #orgql #llm #informationmanagement #gptelorgtools

PS. Links should work now, apparently profile visibility affects repo visibility on Codeberg. I would not have expected that.

PPS. Deleted and reposted because of strong anti-bridge sentiment on my part. Screw Bluesky and bots that repost to it. Defederated: newsmast.*

So currently I'm hosting gptel-org-tools on my own forge...

https://git.bajsicki.com/phil/gptel-org-tools

I can't seem to find a good way for people to create issues.

I thought that creating issues via email was a thing with Forgejo, but it appears not.

So here's a poll. Despite my hatred of Microsoft, is it for the best to move the repo to GitHub?

Or is there some way to federate with GitHub users so I don't need to open public sign-ups on my git?

I'm not exactly clear on what the move is here.

#Emacs #gptel #gitforge #forgejo #github #microsoft #foss

@karthink can I define a chat with my own prompt? Like specify a file where to get it from, or provide it as text? Couldn't find it in the docs, only the crowd sourced prompts.

Update:
- Fixed up a number of functions. Abstracted some, improved descriptions for better comprehension by LLMs.
- Tried to disable org-ql caching, but it's tricky so caching is still on.
- Fixed up list-buffers and open-file tools (on @karthink@fosstodon.org's advice)
- Disabled a few tools (notably org-ql-select) by default (now you'll have to manually add it to your config), as getting correct query syntax out of an LLM is a losing gamble.
- Updated some documentation.
- Changed some function names.
- Playing around with adding some additional markers for LLMs to use as reference (e.g. to treat pieces of data they get as actually separate.)

It appears to be working, if not better, then at least more reliably now. Some prompting is necessary to avoid it falling back to bad habits (using "X OR Y" in queries, for instance.

Note: reasoning/ thinking interferes very badly with calling tools. I'm not sure why that is, but at the moment I recommend against it.

So far, it works reasonably well for general queries, but I still find that org-ql-select-agenda-rifle (which does what it sounds like) pulls way too much into context.

I want to develop a way in which queries can be more precise without going keyword by keyword, but also without letting the LLM screw up the syntax.

https://git.bajsicki.com/phil/gptel-org-tools

#emacs #gptel #orgmode

And just a day later, here's a git repo with more philosophy than good code.

I think the philosophy part is more important personally, the code we can fix later.

https://git.bajsicki.com/phil/gptel-org-tools

TL;DR: Emacs (and its ecosystem) makes the whole vectorization/ RAG/ training stuff entirely redundant for this application.

Yes, this code fails still... a bunch, especially given the current lack of guardrails. But the improvement I've seen in the last few days makes me cautiously believe that with enough safeguards and a motivating enough system prompt, an active assistant may be possible.

Image attached isn't nearly as good as I've seen, but it's an off-hand example that demonstrates it working.

The only thing missing for me to be happy with this is one of those organic, grass-fed LLM models whose existence isn't predicated on theft.

#emacs #orgmode #gptel #orgql

RE: https://fed.bajsicki.com/notes/a6jw3n155z

Yesterday I used `gptel tools` to read the source code of `meow` and `emt`, and completed the extension for `meow-mark-word`, supporting Chinese word segmentation. I definitely could not have done this on my own. Thanks to AI and `gptel tools` for bringing my ideas to life. #gptel #AI #meow #emt #emacs

Does anyone have any good GPTel tools to share? #emacs #gptel #FunctionCalling

I was walking down the street in Riyadh and someone shouted "ya hmar!" at me. What did he mean?

@karthink do you think it makes sense to add gptel-add-repo to add entire repo to the context, excluding what's in .gitignore?