-
LLeMbas 1.10.0 Stable
Homer released this
2026-09-29 16:08:02 +00:00 | 0 commits to main since this releaseData groups: a provider's models read only the data of the group their
connection is in. This is the first of three releases. The next two add rules
for which model may talk to which, and helpers on a different model.-
Every connection is in a data group, and its models read only that group.
This covers memories, notes, skills, knowledge bases and their documents,
reports, and the personality and impression a model keeps with you. It applies
both to what a model is handed at the start of a turn and to what its tools
can find. A tool can no longer open a record from another group by its id.
Admin → Data groups makes groups, puts connections in them, and shows
where each group's data goes, flagging a service whose connection sits in
a different group. Every instance starts with one group, called Default, with
every connection and every existing record in it. Until you make a second
group nothing changes, and nothing about groups is shown in the library. -
A chat stays in the group it was started in.
- Inside a chat, the model menu offers only models in the chat's group and
names the others underneath, with the reason. - Switching to one is refused, because it would be sent the whole
conversation. - The crowd picker,
ask_friend, the list of other models, attaching a
knowledge base and the@menu all stay within the chat's group. - If a chat's model is later moved into another group, the next reply is
refused with an explanation rather than sent. - When a chat's own connection has gone, the fallback to "any connection
offering the same model" now only considers connections in the chat's
group. Before, it could silently move a conversation to another provider.
- Inside a chat, the model menu offers only models in the chat's group and
-
A group can have its own embedding model and image reviewer. The embedder
is sent the full text of everything it indexes, and the reviewer every picture
with its prompt. A group that names neither uses the instance's. -
Schedules run in their model's group. A schedule's reports land in that
group. A schedule whose model is in another group than Messages cannot post
into Messages, and says so. The model that works out a schedule's timing from
plain words is now picked from the schedule's own group, not simply the first
pinned model. -
Your own arrangement, with a new permission. With Manage their own data
groups (off by default), a person can:- make personal groups nobody else sees;
- choose which group each connection reads for them alone;
- move their own notes, skills and knowledge bases between groups.
Everybody can see which group each connection reads, on the new Data tab
in Settings, once there is more than one group. New notes, skills, knowledge
bases and memories can be put in any group you can use. -
A search no longer mixes two embedding models of the same width. It
checked only a vector's width, so two different 1024-wide models scored against
each other and returned confident nonsense. That used to need a model change
with a rebuild pending; with an embedder per group it would have been ordinary.
A query now carries the model that made it, and only that model's pieces are
scored. -
The crowd picker on the new-chat screen now leaves out the model the chat is
being started on. It was offering the chat's own model as a member. -
Four lines on the crowd page and in the crowd picker were still in English on
a Slovak instance. They are translated now. -
Known limits:
- A skill name and a knowledge base name are still unique per person across
all groups. The database constraint cannot be changed without rebuilding the
table. - Speech to text and text to speech are not grouped: audio is sent to the
speech server and not kept. - Moving a whole knowledge base to another group leaves its documents indexed
for the old group's embedder until the index is rebuilt.
- A skill name and a knowledge base name are still unique per person across
Downloads
-