v4.0.18: Every Chat Turn Gets 10,000 Tokens Lighter, You Choose Your Claude Context Window, and Creating an Employee No Longer Depends on One Provider
Every message you sent a Claude employee was carrying its instructions file twice. Claude sent it, and then the platform sent it again. From v4.0.18 it goes once.
About 10,000 fewer tokens, every turn
A minimal chat turn drops from roughly 40,000 tokens to roughly 30,000. That is not a tuning gain, it is the same content being read twice and now being read once.
It applies to every message, so the saving compounds quietly across a busy day rather than showing up as a single number anywhere. Employees pick it up the next time their chat session starts, with nothing for you to do.
Choose how much your Claude employees remember at once
Admin > Settings gains a Claude context window, matching the one custom LLMs already had: 128k, 256k, 384k, 512k or 1M tokens. It stays at 1M by default, exactly as before, so nothing changes unless you decide it should.
Past whatever size you pick, Claude summarises the older part of the conversation itself rather than dropping it.
The trade is straightforward and worth understanding before you touch it. A smaller window means fewer tokens read on every single message, which is cheaper and faster. A larger one keeps more detail in working memory. The chat's context badge follows whatever you choose, so you can see where you are, and the setting takes effect when an employee's session restarts.
Most people should leave it alone. If you run a lot of short, self-contained exchanges, a smaller window is money you are currently spending for nothing.
A kanban listing that is 75 times lighter
Asking an employee to list its board used to return the entire thing: every done card, every description, every comment. Hundreds of kilobytes read for a glance at what is in progress.
It now returns the open cards, one line each, plus a count of the done ones. A single column, done included, or the full detail, are each one option away, and an individual card still comes back in full when asked for by name.
This is the same idea as the one above, applied to a different pipe. The expensive part of running agents is rarely the thinking. It is how much they have to read before they can start.
Creating an employee no longer depends on one provider
Writing a new employee's profile relied on Gemini. If Gemini was down, overloaded, refusing the key, blocking the IP or out of quota, you could not create an employee.
Now the AI already connected to your instance takes over: Claude, then Codex, then your custom LLMs, using the same instructions and the main language chosen in the wizard. Every instance has at least one, since creating an employee requires it. After a Gemini failure, Gemini is skipped for ten minutes so the next person is not left waiting on the same timeout.
And if nothing answers at all, the employee is still created, with a plain profile in your language and a catalogue persona if you did not choose a name. You end up with a working employee rather than an error page, which is the right outcome even when it is the less impressive one.
Finishing a profile that was created without AI
An employee created that way now shows an offer at the top of its chat to complete its profile: an AI writes its real personality and its suggested requests, and the employee folds them into its instructions.
If no AI is available yet, it says so plainly and the offer stays until one is. No silent failure, no half-finished employee you have to remember to go back to.
Fixes
Profile generation errors are readable. When a new employee's profile could not be written, the wizard showed the provider's raw JSON error next to a success icon, which is close to the worst possible combination. Errors now look like errors, and that applies to image and hiring failures too.
WhatsApp echoes no longer confuse an employee. When an employee uses its owner's WhatsApp number, the phone sends each of its own messages back before the send is even confirmed, so an employee could mistake its own reply for a new incoming message. The outgoing text is now noted just before sending, and its echo is recognised and ignored.
Replies leave from the address they were written to. With a custom mailbox connected, a reply to an email received at the employee's workspace address was going out from the custom mailbox instead. It now leaves from the address the sender actually wrote to.
Discord is treated like the other channels, with the same inbound guardrail and daily message limits as Telegram or WhatsApp.
Grouped webhook calls are recognised as webhooks, so several deliveries arriving together are guarded and counted like any other.
One note for self-hosters
Builds no longer download anything from GitHub. A GitHub outage was enough to stop every build, because LiveKit and the memory engine's GPU binaries were fetched each time. LiveKit now comes from a local image built once, the same way Asterisk does, and the GPU binaries are skipped entirely since the memory engine runs on the CPU and never used them.
Before your first build of this version on a machine, build the LiveKit image once:
docker build -t getateam-livekit:1.13.7 - < Dockerfile.livekit
Want to test the most advanced AI employees? Try it here: https://Geta.Team
