4.3.18 2026-11-10

Extension and twinny-server: agent mode gets more out of small local models, the chat follows a reply as it is written, the sidebar has a softer look, and the gateway has fixes from an audit.

• Long conversations fit the model's context. When a conversation outgrows the context the model is loaded with, its oldest turns are folded into a few lines at the start, so the system prompt, the tools and the newest turns reach the model whole. Until now the server cut the conversation itself, and a local model at the end of a long chat lost the task it had just been given. Folding goes in blocks, so the start of the conversation stays the same for several turns and a local server keeps its cache of it. Plain chat is fitted the same way.
• Reads sized to the context. read_file returns as much of a file as the context has room for (150 lines at 8k, up to 500 at 32k and above) in place of 150 lines whatever the model, so a file is read in one request more often. Where a read stops, it lists what is defined further down with line numbers, so the next read goes straight there.
• Trimmed results leave a digest. When old tool results are trimmed to make room, a read keeps what it read and what is defined there, a search keeps where it matched, and a command keeps how it ended. Short results, such as an edit made, are no longer trimmed at all.
• edit_file does more in one call. replace_all changes every place the text is; edits takes a list of changes to one file; start_line and end_line rewrite lines by number, refused with the current lines when the file changed since it was read. A finished edit returns the lines as they now are, so the next edit needs no read. An edit to a file the model has not read, with text that is nowhere in it, gets the file back in place of advice.
• A task list for longer work. The model can keep a list of steps with update_tasks. It shows in the reply, ticked off as it goes, and is put back in front of the model when a reply runs out of steps or the next turn begins. Turn it off with twinny.chatToolsTasks.
• A record of what a reply did. The edits, files and commands of a reply are kept as a short list: it is given to the model when a reply runs out of steps, so its summary matches what happened, and it heads the notes the next turn starts from.
• Tool calls written in a code block are run. A model without native tool calling that writes its call inside an ordinary fenced block, instead of the format it was asked for, used to end the reply with nothing done. The call is now read from the block when it names a known tool.
• Fixed: the chat not following a reply as it is written. The transcript fell behind during long code blocks and jumped back up when the reply ended. It now stays at the end until you scroll up, and stays where you are once you do.
• The chat says what the model's server knows, before you send. The composer's footer shows a gauge once the conversation and the draft take a quarter of what the model is loaded to hold, says so from 80%, and warns when the message will not fit. When a local model is not in memory, a Load model button loads it in the background so the first reply does not wait; Ollama and LM Studio say whether it is.
• A first screen with something to do. The empty chat shows the context the model is loaded with and whether it is in memory and on the GPU, and offers three first questions (Explain this file, Find bugs, Write tests) about the open file or the selection, cut to what the model's context holds.
• A softer sidebar. Rounded corners and filled surfaces in place of outlined boxes across the chat, providers, history and embeddings tabs: user messages are a soft block, code blocks and approvals are cards, the composer is a rounded field with a solid send button, and tool steps are easier to read.
• A livelier Overview on the admin page. Each tile shows how the period compares with the one before and draws its days as a line. The chart switches between requests, tokens and failures, and pointing at a day shows who asked, how many failed, the tokens and the average latency. The usage API gains per-day failures, tokens and time, and compare=previous for the totals of the period before.
• Fixed: a refused WebSocket upgrade could stop twinny-server. A caller that reset the connection while its upgrade was being refused ended the process; no key was needed.
• Fixed: stalled requests holding the gateway's request slots. A request whose body never arrived, or whose reader stopped reading, was not ended by the request deadline and kept its slot.
• Fixed: demo keys joining the team pool. A demo's visitor and guest keys can no longer connect as a shared computer.
• Fixed: limits.maxOutputTokens bypassed by a maxTokens of zero or less.
• Fixed: a removed review model stopping the gateway. A review alias that no longer exists falls back to the first chat model, and background reviews that fail are logged. A failed automatic review is tried once per commit, not every minute.
• Other gateway fixes. A bad since on the audit and recordings lists answers 400; request metrics no longer grow a series per unknown model name; the SSO landing page shows provider errors as text, and one address cannot fill the sign-in list; GitLab notes cannot run quick actions such as /approve; backups leave out shared-context clones and skip paths too long for an archive; GitHub issues are found on repositories with many open pull requests; developers post a triage reply once.
• Supporting twinny means buying a licence. The READMEs, the GitHub sponsor button and the Support twinny page point to twinny.dev's pricing in place of donation addresses.
• A Personal licence: $29 once. One person gets policy, recording and plugins on their own gateway, with one key that works on all their machines, for good. Gateways from 4.3.19 hold a Personal licence to that one key. Buy it at twinny.dev; see Licensing and seats.