Sync the self-hosting stack
This commit is contained in:
@@ -9,6 +9,65 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
|
||||
Every version published to a channel appears here. Nothing is written from memory afterwards: a build
|
||||
cannot be published without its entry.
|
||||
|
||||
## 2026-09-11 — The assistant was reading the first and last pages of a file and nothing in between `api 0.110.0`
|
||||
|
||||
Anything the assistant read — a document in a conversation's workspace, a config file on one of your
|
||||
machines — was cut down to about 12,000 characters before it reached the model. That cut was the
|
||||
problem rather than the size: it kept the beginning and the end and deleted the middle, then joined
|
||||
the two halves together. What the assistant received looked like a complete file. It read as
|
||||
continuous text, with nothing to indicate that 97% of a long document was missing, so the assistant
|
||||
had no way to know it was answering about text it had never seen — and neither did you.
|
||||
|
||||
**`read_document` now returns the document itself.** Up to 60,000 characters by default and 200,000
|
||||
on request, always a single unbroken run starting where the assistant asked, with a line at the end
|
||||
saying how much is left and where to continue. On a document longer than that the assistant reads it
|
||||
in order, page after page, instead of receiving a collage. This matters most for editing: a patch has
|
||||
to quote the existing text exactly, and text welded together from two ends of a document cannot be
|
||||
quoted.
|
||||
|
||||
**`ssh_read_file` and `agent_read_file` had the same fault**, plus one of their own: both offered a
|
||||
`maxBytes` setting that went up to two megabytes, and everything above roughly 12,000 was discarded
|
||||
after being read. They now return what they were asked for — 60,000 bytes by default, 200,000 at
|
||||
most — always from the start of the file, with a note saying how much of it is left. Asking for more
|
||||
than they can return is now refused with a message, instead of accepted and quietly ignored, and the
|
||||
note points at `head`, `tail`, `sed` or `grep` when a file is genuinely too large to read whole.
|
||||
|
||||
**Every other tool is unchanged.** A command's output, a directory listing, a query result — these
|
||||
are still cut at the same place as before, because for a log or a table the beginning and the end are
|
||||
usually the answer. The larger budget belongs only to the tools whose result is meant to be a file.
|
||||
|
||||
**Self-hosters:** nothing to do. No schema, no configuration. Note that a large read now genuinely
|
||||
occupies the model's context, which it previously only appeared to — if your `OPENAI_MODEL` has a
|
||||
small context window, the assistant will be reading in more, smaller pages.
|
||||
|
||||
## 2026-09-11 — Pinning a conversation appeared to do nothing `web 0.132.0`
|
||||
|
||||
The rail on the left of a conversation held two ideas that were never explained apart: a "working set"
|
||||
that the product called something else everywhere you actually touched it, and a pin whose effect was
|
||||
invisible. Pinning a conversation left the list looking exactly as it had a moment earlier — same
|
||||
rows, same order, no mark on the one just pinned — so the only reasonable conclusion was that the
|
||||
pin had not worked.
|
||||
|
||||
**It had worked, and the list was refusing to redraw.** The rail deliberately holds its order still
|
||||
for a moment after you touch it, so a row never slides out from under a tap. Pinning was the one
|
||||
action where nothing came along afterwards to release the hold: the pin was saved, the freeze was
|
||||
applied by the same click, and the rail then went on drawing the pre-pin order for as long as the tab
|
||||
stayed open. It now lets go on its own the moment the pause is over.
|
||||
|
||||
**Pinned conversations have their own section**, above the ones you have merely been in, and a
|
||||
conversation stays under "Pinned" even while it is the one you are reading. A pin that moves somewhere
|
||||
else when you open it is a pin you cannot find at the moment you go looking for it.
|
||||
|
||||
**The pin is now visible without hovering.** It was drawn only when the pointer was over the row,
|
||||
which on a touch screen means never, and on a mouse means the state of the list changes depending on
|
||||
where the cursor happens to rest.
|
||||
|
||||
**One name for one thing.** "Working set" is gone; the rail, the panel, its tooltips and the remove
|
||||
action all say "dock", in English, French and German.
|
||||
|
||||
**Self-hosters:** nothing to do. Pins and recents are stored in the browser as before, and no pin is
|
||||
lost by the upgrade.
|
||||
|
||||
## 2026-09-11 — Fixing one paragraph meant resending the whole document `api 0.109.0`
|
||||
|
||||
The assistant could write a document into a conversation and replace its body, but replacing was the
|
||||
|
||||
Reference in New Issue
Block a user