v2.7.23: Your First Employee Arrives in Eight Seconds, and Editing Instructions Keeps Your Conversation

A customer told us the hire wizard sat on Searching… for about a minute and then gave up. It took them three attempts to get an employee created. They stuck with it, which is the only reason we know about it. Most people meeting that screen on their first day would close the tab, and we would never hear from them again.

That is the uncomfortable part. Creating your first employee is the first real thing the product does for you. If it fails there, nothing else we built ever gets a hearing. We suspect that is exactly what happened to several recent signups who never created an employee at all.

Nothing was broken, which is why it took a while to find

Measured on the instance that reported the problem, four successful profile generations took 22, 22, 26 and 37 seconds. The call is cut off at sixty. So nothing was failing in any way a log would flag: the same work simply took long enough, sometimes, to cross a line.

That is a worse shape of bug than an outright error. An error shows up in monitoring, gets a stack trace, gets fixed. A run that usually takes 22 seconds and occasionally takes 55 just looks like a slow day. The average was fine. The average was never the problem. The spread was the problem, and a spread of fifteen seconds against a sixty second ceiling means every hire is a coin flip you are not aware you are tossing.

What was actually slow

Not the proxy. A minimal call through it answers in 1.1 seconds, so the transport was never in question.

Not the size of the profile either. That was the first thing we suspected, on the reasonable theory that generating a full employee persona plus eight starter prompts is simply a lot of text. It was the wrong theory, and it cost us a detour.

Here is what it turned out to be. The model behind the SaaS alias reasons before it answers. On a real profile generation it produced 2134 tokens, and 1334 of those were reasoning tokens. Sixty-two percent of the work was deliberation that nobody ever sees, on a task with nothing to deliberate about. The same model spends twelve reasoning tokens when you ask it to reply "OK".

Think about what generating a profile actually is. You have picked a role, a name, a personality. The model fills in a structured document from those inputs. There is no judgement call anywhere in it, no ambiguity to resolve, no plan to form. It is a form. We were paying a model to sit and think hard about a form, twice over: once in time, once in tokens.

The fix, and where we deliberately did not apply it

Requests can now ask the model not to think first. The important detail is that this is opt-in, and exactly one caller opts in: the profile generator.

Chat is untouched. Nova is untouched. The guardrails are untouched, and so is the vision fallback. For all of those, the reasoning is the entire point, and stripping it to save a few seconds would be trading the thing you actually want for a progress bar that moves faster. There is a version of this fix that gets applied globally as a performance win and quietly makes every employee worse at its job. We did not want that version.

On the same instance, after the change: 8.3, 7.6 and 8.2 seconds, with all eight starter prompts still generated. Roughly two and a half times faster, half the cost per call, and the spread is down from fifteen seconds to seven tenths of one. That last number is the one that matters. The old numbers were gambling against the timeout. These are not near it.

One note for whoever touches this next, because it cost us time: the proxy rejects { effort: 'low' } with a 400. The shape it accepts is { enabled: false }.

Editing instructions no longer costs you the conversation

Correction, September 15, 2026: This section was wrong about one thing. A running employee does not re-read its instructions during a session; they are read once, when the session starts. So after this release, saving kept your conversation but did not change how the employee in that conversation behaved. v2.7.24 fixes it properly: saving now tells a running employee to re-read its instructions, and it applies them straight away without losing the conversation. Read the v2.7.24 notes.

Saving CLAUDE.md used to clear the session, the same way that editing an employee's appearance did until last week.

The appearance case was easy to justify fixing: appearance writes to a separate file, so there was never a good reason to restart anything. This one we had kept on purpose, and the reasoning was not obviously wrong. CLAUDE.md is the system prompt. Change the system prompt mid-conversation and you have an agent operating under two different sets of instructions in the same thread, which is the kind of thing that produces behaviour nobody can explain a week later.

Except the instructions are re-read while a session is running. They always were. So the restart was not protecting anyone from a split-brain agent, because the running session was already picking up the new file. It bought nothing, and it charged you your entire conversation for it.

That is a small change with a disproportionate effect on how the product feels to use. Refining an employee's instructions is not a one-shot act, it is a loop: you watch it work, you notice something you want done differently, you edit, you watch again. If every edit wipes the context you just built up, the loop is expensive enough that most people stop doing it and settle for an employee that is roughly right. The panel now tells you that the change applies to the conversation in progress, because that is what happens.

What we took from this one

Both of these came from the same blind spot, which is worth naming. In each case the system was doing something defensible in isolation. Reasoning before answering is usually correct. Restarting a session after the system prompt changes is usually correct. Neither had been checked against what the specific caller actually needed, and the cost of not checking landed entirely on people in their first ten minutes with the product.

The slow hire we found because one customer was persistent enough to try three times and then tell us. We would rather not depend on that.

Want to test the most advanced AI employees? Try it here: https://Geta.Team