"keeps its note until the session is resumed" started `sleep 0.5` and counted
on the turn taking less than that before /new. On a loaded machine (load 7 on
two cores) the turn took longer, the job ended while the session was still
open, and its note went in as a turn instead of waiting. The command now
waits for a file written after /new.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What a user sees change: the CLI uses the server it is logged in to and
nothing else, models by their served names, memory on the server, stacked
instruction files, short tool results that are never rewritten, recall and
show, link protocol 3, and a chat's model or a refusal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- LEMBAS_PROTOCOL, the device protocol and the protocols the CLI logs in to
and links with are 3 alone (harness/acp.md *Versions*). A server listing
only 1 and 2 is refused at login and at every dial — before anything is
dialled — with its version and protocols and "update the server, or use
LLeMbas CLI 1.x with it"; a newer one is told to update the CLI
(ProtocolError). A 4400 stops the link with the same advice. The old
downgrade to protocol 1 is gone.
- session/new's result says `instance`: whether the session's model is the
link's instance's.
- `lembas_model` is the model, full stop: a device not logged in to the link's
instance, a link with no instance (serve --stdio), or a model the instance
does not serve to this device is -32602 with the reason, never a session on
the device's own model. `_lembas/configure` naming such a model is refused
likewise and the session keeps its model.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
acp.md *Versions*: LLeMbas 2.0 and LLeMbas CLI 2.0 speak link protocol 3 and
nothing else, so a 1.x peer and a 2.0 one refuse each other and each says what
to update. A 2.0 server's discovery says `protocol: 3, protocols: [3]` —
`protocol` was frozen at 1 so 1.x clients comparing it could log in; raising
it now is the point. A 2.0 CLI logs in and links only where 3 is listed and
otherwise names the server's version and protocols; a 2.0 server closes a
hello of 1 or 2 with 4400 and "update LLeMbas CLI to 2.0".
Model naming: the served id is the device's ref (one server, no connection
prefix, no second login); the older forms still resolve. A configure naming a
model the device cannot run is -32602 too, and the session keeps its model.
initialize's example says 3; `show` in the client's capabilities.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Harness spec 3.0.0 (acp.md *Memory*): memory records are the server's for the
device as for a chat; everything else in the library is the device's own.
- `library: lembas` (the default when the login's token has the `memory`
scope, or the older `library`) adds the server's /mcp with its `memory`
tool alone, in place of this machine's memory tool; notes_*, knowledge_*
and skill_* are always this machine's. No prompts, resources or
instructions are taken from it.
- The memory in the prompt is the server's: the resource lembas://memory,
read as a session starts (McpManager.readResource) and kept for it — put in
while nothing has been sent, so the prompt never changes under a session.
- A session the client opened (session/new, or opened from the store) sends
its id as `_meta.lembas.scope` on every memory call and on the resource
read (App.setScope); a session of the device's own sends none.
- An instance's `library` context (its knowledge bases) is no longer read:
the knowledge block names this machine's bases only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
acp.md said a logged-in device reads "the resource holding the entries for
the prompt" without naming it, so neither side could implement it. It is
`lembas://memory`: the entries as the memory block of a system prompt shows
them, read as a session starts and kept for it. Only `memory` is taken from
/mcp — notes, knowledge bases and skills stay the device's; the scope rides on
the resource read as on the tool call; a token's older `library` scope counts
as `memory`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LLeMbas CLI 2.0 is LLeMbas-server-specific (CLI rule 2). Removed: the
anthropic, gemini, ollama and responses clients, context discovery and
llama-swap unloading (discover.ts), the Connection schema with its dialect,
auth, key_cmd, discover, unload_url and one_model_at_a_time, the model
`fallback` (it only ever moved to another server), effort_map and cache, and
the multi-connection refs. Kept: openai-chat, http, sse, think, effort,
tokens and all of src/lembas.
- connections.yaml holds the login (`type: webui`, as lembas login writes
it). A custom entry from 1.x is read past with a warning that says how to
log in, so an old file still starts; with several logins left, the latest
is used and the others named.
- A model's ref is the id the server serves it under; the older forms
(`<login>/<id>`, `<login>/<model>`) still resolve and config.yaml is
rewritten once. Without a login there is no model, and the error (and the
first-run screen, now the sign-in alone) says `lembas login <address>`.
- A login to another server signs this machine out of the previous one.
- The window is the server's word (no discovery); a capacity group comes
from the server's `capacity.group` alone; embeddings use the server's
/v1/embeddings.
- `lembas models` lists the server's models; install.sh's starter files, the
README and the JSON schemas say the same.
Tests: every fixture is a login now (the fake server lists models, answers
other GETs with 404, and can hand one model to another script, as a server
with several backends); the dialect suites and the cross-connection tests are
gone with their code.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Harness spec 3.0.0 (context.md, loop.json `context`), in session/results.ts,
applied by the engine when a result goes into the conversation and never
afterwards:
- every result is headed by its id ([#0001]); a read also by the path as
given, its lines, the file's length and the first 8 hex digits of the
content's SHA-256; an empty file says so;
- a read of an unchanged file whose lines lie inside an earlier full read is
a stub naming it; a list/glob/grep repeated with the same arguments and the
same result is "Same result as #…";
- output over 400 lines or 40,000 characters keeps head and tail with the
elided line; the full result is kept with the session (a new `results`
table in sessions.db, gone with the session);
- edit, multiedit, write and apply_patch answer with their hunks under a
bracket with the new content's hash; a new file is "Created, N lines.";
- recall (new built-in tool) shows any stored result, or a range of it, also
after a resume; ids are never reused;
- compaction appends the table of the reads still in the conversation to the
summary.
A stub only ever points at a result still in the conversation, so after a
compaction, an /undo or a rewind the file is read in full. compaction.prune
is gone: cutting old outputs in place threw the prompt cache away (an old
config's key is dropped with a warning). blocks/context.md is in the prompt
wherever recall is offered. Conformance runner for the `context` area (11
cases pass).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The README linked the page on the forge's own host. It names the page in
LLeMbas CLI's wiki instead, so the spec (vendored by the server) carries no
host name.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
conformance/context.json named results #g001…#k001, which are not the
lowercase hex context.md requires (an implementation that finds a result's id
at the head of the result by that rule cannot see them); they are #1001…#5001
now, with the same answers. Its `about` names the CLI's module,
session/results.ts.
context.md §5 says what it left open: a deleted file's bracket, and an
apply_patch over several files — the id alone, then each file in its own
bracket with its change, in the patch's order; a tool's note after the diff.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
instructionChain (spec 3.0.0, filesystem.md): from the boundary — the project
root — down to the start directory, outermost first, each directory gives the
first of AGENTS.md, CLAUDE.md that is a file really inside the project; one
that is not (a link out) is passed over and the walk goes on below it. Before,
only the nearest file counted. The chain's files are named to the model by
their path in the project; agentsBlock reads them all: none means "make one",
and git is settled when any of them settles it.
Conformance runner for the `instructions` area (all 9 cases pass).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The spec's version may be a pre-release (3.0.0-draft). Every tool file is
loaded, with the new fields `sessions`, `requires`, `unavailable` and
`confirm`; the CLI's tools are those not the server's alone and offered in an
agent session (forCli) — a chat's own tools over the server's tree (mkdir, mv,
rm, search, python, the forge verbs) are not built in. blocks/context.md is
known; blocks/workspace.md is the server's alone.
show is built in with `requires: display`: offered only in a session a client
opened over the link when that client said `show: true` (capability `show`);
the device reads the file (at most 1 MB) and sends it with `_lembas/show`.
The harness tests now say 3.0.0's split of tools instead of "the execution
tools are the CLI's alone".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
blocks/context.md tells the model about stubs and recall; blocks/workspace.md
tells a chat's model its view. blocks/library.md and blocks/prototypes.md are
the CLI's alone. acp.md: `instance` on session/new, a client-opened session
runs on the chat's model and no other (the own-model notice is gone),
capability `show` with `_lembas/show`, memory through the instance. README:
the new fields and the 3.0.0 section. VERSION 3.0.0-draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
context.md and loop.json `context`: every result has an id, a read carries its
lines and content hash, an unchanged re-read (or a range inside one) is a stub,
large output keeps head and tail with the elided line, recall shows any stored
result, edits answer with their diff, a repeated listing or search with the
same result is a stub, and compaction adds a table of reads and empties the
dedupe table. Nothing already sent is ever rewritten. Conformance area context.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
filesystem.md: paths, the node kinds dir/file/mount, the access levels
none/ro/stage/commit with grants and floors, the exact error texts, and the
rule that a granted path under one that is not is reached only by its full
path. Listings, search, indexing by tokens (480 a piece, 64 repeated),
instruction files stacked from the boundary to the start directory, skills,
and memory kept by the server for both sides. Conformance areas fs_access,
instructions and chunk_tokens, answered from a reference model of the rules.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every tool says its `sessions` (chat, agent or both). The file tools read, write,
edit, glob, grep and list are shared; mkdir, mv, rm, search, python and the forge
verbs (commit, branch, pr, merge, tag, release) are the chat's; show and recall
are new and shared. New fields: `requires` (page, display, forge) with the exact
`unavailable` answer, and `confirm: always` for merge, tag and release.
knowledge_*, notes_search, note_view and note_manage leave the chat. Default
rules for the new tools; modes.json says what `confirm` does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A second `lembas login` to the same instance overwrote the old token without
signing it out, leaving an offline twin of the device holding its agent chats.
The old token is now signed out over the TLS that just worked, naming the new
one, so an instance that knows `replaced_by` moves the chats; a failed sign-out
is said.
`login --ca` kept the path as typed, so a service started in another directory
dialled with no CA. It is kept in full now, the link trusts what discovery got
through with (the system's bundle included), and "could not reach the instance"
says why: a CA file that is gone, or what discovery met.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An image counted as half a million tokens: the context estimate measured its
base64 as text, so a 1-3 MB screenshot read as "context at 150-280%" the
moment view_image added it, and the session compacted after every image.
An image now counts by its dimensions (28 px patches, at most 16k tokens, a
flat 1600 when unreadable) everywhere the CLI estimates -- the meter, pruning,
/context and the no-usage fallback of all five dialects. Images over 1600 px
or 500 KB are shrunk to 1600 px when ImageMagick is there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One registry per process, every job owned by a session: bash's background commands (and a command
still running at its timeout, which now goes to the background instead of being killed) and
subagents started with task background: true. job_list, job_output, job_stop (the former
bash_list, bash_output, bash_kill) and the new job_send and report; a finished job wakes the owning
session in every front end with its marked note. The TUI counts jobs, lists them (/jobs), opens a
command's output, enters a subagent and messages it, moves a command to the background (ctrl+b)
and asks before quitting with jobs running. The link gains the jobs capability. Subagents get a
session row of their own, the spec's preamble and agent texts, and their errors reach the report.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The CLI's facts in memory, notes_search, note_manage, skills_list,
skill_view and skill_manage are `variables` now, filled with the CLI's own
values (src/tool/spec-vars.ts): every description and parameter list the CLI
sends is word for word what 1.1.0 said, except note and document ids, which
are strings on both sides (a number is still taken). Descriptions are
filled by the prompt texts' rules, parameter descriptions too. `narrow`
says what a project offers of a shared tool's parameters. Memory's changes
are one pure function (applyOps). Conformance: fill, narrow, memory.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The turn log answered a repeated id with what that turn had answered, which
was right for a prompt sent twice over a dropped link and wrong for a turn
the web UI had just rewound to edit: the same id came back with the old
reply. rewind now returns the ids it took out, both handlers forget them from
the log, and the turn file drops them too, or the next load would have
brought them back.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The spec: plan_write and plan_update (new, shared, offered in every mode) and
plan_submit (now shared) keep one structured plan — findings, objectives,
phases of tasks — in place of the todo list, which lives on as a former name
of plan_write. The shared system text is one text for both projects, with
variables for what differs; the mode texts, a prototypes block and a library
block are shared. acp.md: the client hands the device what only it knows
(context, library, prototypes), the plan travels as a structure (plan_state),
library calls carry the chat's scope, and a client may rewind a session.
loop.json says its numbers as numbers. Four conformance areas: plan,
prototype, library_scope, toolcall_index.
The CLI: the plan is kept per session in the store and drawn above the prompt
and on the approval card; the prompt is assembled from the spec's texts with
their variables filled; the link reads the instance's instructions,
personalization, knowledge scope and prototype offer, sends the plan as a
structure and answers rewind; library calls to the instance carry the session
as scope; a prototype written in the terminal is saved as a file and named in
the transcript; a tool-call fragment without an index continues the last call;
the default theme is Moria; dead exports and Hermes leftovers removed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Config, data and state are rooted at <project>/.agent/local/lembas (or
.lembas/), kept out of git; a local directory the repository carries is
refused. The user's logins and connections.yaml are read, never written; the
user's config.yaml is not read. The TUI is started with TMPDIR inside it (the
compiled binary unpacks its native library there) and OpenTUI's cache goes
there too; the agent's commands keep the user's TMPDIR.
An instance serves models, chat, speech and the balance only: the link,
/remote, the service and the hub are off, deletes are not sent, and the server
library, search, fetch, embeddings and personalization are not used.
Self-update and uninstall are refused. hardline_disable is ignored, and tools
treat the local directory as outside the project.
The smoke test runs a whole local session in the compiled binary and checks
that HOME, the XDG directories and TMPDIR gained nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`lembas remote list | add | remove | enable | disable | mode | terminal`, with
`--json` printing {enabled, roots, max_mode, terminal}, for LLeMbas Desktop.
Writes go through the global config writer and keep comments.
The device's limits are now live getters over the remote: block, re-read when
config.yaml's stat changes. `lembas service` links even with remote work off
or no roots: it says roots: [] and refuses every session, directory and
terminal, so the instance can tell "no folder allowed yet" from "not running".
When what the instance was told changes, the link re-dials once nothing is
working, so `lembas remote add` or `enable` takes effect without a restart.
Harness spec 1.0.1 documents both.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The first public release of LLeMbas CLI: a terminal coding agent and project manager for any LLM
API, with permission modes, git snapshots, memory and skills, knowledge bases, MCP, voice, and a
link to a LLeMbas instance whose web UI can work its sessions too. Signed Linux binaries for x64
and arm64.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HomerandClaude Opus 5.5