Yesterday a brand-new Newton customer finished signing up, opened the chat, typed their very first hello — and then nothing. No reply. My stomach dropped, because the first minute a customer spends with their AI is the single most important minute there is.
When I actually went digging, it turned out the AI hadn't crashed, hadn't hung, and wasn't even "thinking too long." The customer's first message had simply vanished into thin air — it never reached the agent at all. So today I want to walk through how sneaky this little bug was, and how Tim (my AI agent) tracked it down and fixed it.
The setup — a freshly booted server is still "cold"
Quick bit of background. Every Newton box is the customer's own private server. When someone signs up, my system spins up a fresh machine for them in under two minutes, and the AI is ready to talk right away.
But there was one thing I overlooked. The very first time a customer opens the chat, the machine is still cold — meaning the AI (in this case Codex) has never been invoked before. When it gets woken up for the first time, it has to boot itself: load this, initialize that. It takes several seconds before it's genuinely ready to accept a command.
Compare that to a few messages later, once the box is "warm." Then the AI is always ready — you type, it answers instantly. So this bug only ever showed up on the very first message of a freshly booted box. Which, of course, is exactly the first impression for every single new customer. That's where it hurts.
Where the bug hides
My system already had a check in place. Before typing a message into the AI, it waits for the agent to be ready — it doesn't just blindly fire text in. The problem was that my way of guessing whether it was ready was a little too crude.
The old logic was simple: wait a beat after launch (at least 1.8 seconds), and if the screen goes "quiet" — no characters streaming out — for more than 0.7 seconds, call it ready and start typing.
Sounds reasonable, right? Except a cold Codex has its own quiet stretches while it boots. It's loading things silently, not printing anything yet. So my system misread that as "oh, it's quiet now = it must be ready" — when in fact it wasn't ready at all, it hadn't even finished setting itself up.
So the moment I typed the message in, the characters fell into the void. And then, when Codex actually finished initializing, it cleared its input field on startup (normal behavior for a terminal-style program) — and the customer's first message was wiped clean, no trace left behind.
I confirmed it from the logs exactly: process spawned at 12:41:07 / system fired the message in at 12:41:12 (released at ~5 seconds because it thought it was ready). But the customer said nothing ever came back. Retry once the box was warm — answered every time. Clear as day: this wasn't a fluke, it was a real race condition.
The plain-language version — talking before the other person picks up
Picture this. You call a friend. The second you hear the ringing stop, you launch straight into "Hey, are you free tomorrow?" — but actually your friend just tapped accept and hasn't even got the phone to their ear yet. Your first sentence sails off into nothing. By the time they're listening, all they catch is "Hello? Sorry, say that again?"
The ringing going silent = my system reading it as "the other end is ready" — when really the person hasn't even raised the phone to their ear.
What I should have done is wait until I actually hear them say "Hello" before I start talking. That's the real signal that they're ready to listen — not a guess based on silence.
How Tim fixed it — wait until the cursor actually blinks
When I pointed this out to Tim, it threw out the readiness check entirely and rebuilt it — stop guessing from "silence," start watching the real thing instead.
A terminal-style program, when it's genuinely ready for a command, shows a prompt marker (in this case the › symbol — like a cursor blinking, waiting for you to type). As long as that marker isn't on screen yet, it isn't ready. Done. No guessing.
So Tim reused a tool the system already had — a headless terminal mirror I'd been using for something else — to read Codex's screen live, and watch for the › symbol to appear. The moment it shows up, let the message through. If it doesn't, keep waiting.
For safety, Tim kept the old method (guess from silence) as a fallback — if it can't find › within 8 seconds, fall back to the old way, with the same 15-second hard cap so it never hangs forever.
The result — faster and nothing vanishes
The fun part is that switching to watching the real thing actually made it faster. On a warm box, the › shows up at 0.5 seconds (versus the old code forcing a needless 1.8-second wait every single time). It can type right away.
On a cold box, it waits until Codex is truly ready before typing — and the first message never vanishes again. I tested both cases live, both pass. So when a new Newton customer's box gets provisioned, it inherits this fix automatically from the very first minute.
Why this tiny thing matters to Newton customers
Because every Newton customer hits a "cold box" exactly once in their life — the first time they open the chat after signing up. And that one time is the moment they decide whether this thing actually works.
If the first message disappears, the customer has no way of knowing it was just a tiny boot-time race condition. All they feel is, "Huh, I said hi and got silence — is this thing broken?" And their trust is gone at the first step, even though the system works beautifully one second later.
This is the difference between having a real AI agent that works for you running on your own private server versus a chat box that just answers questions. Once the AI is actually doing work on the customer's machine, fine-grained details like "the exact instant it's ready for a command" become things you have to get smooth — because they're the direct experience the customer feels.
My lesson — don't guess from "silence"
This taught me something: "silence" doesn't always equal "ready." Sometimes it's quiet precisely because it's still getting itself together. Good system design waits for a real confirmation signal — not the absence of activity. A few days later I hit the sibling version of the same lesson: a long Thai prompt looked like a model failure, but the real culprit was a 1KB terminal input buffer silently dropping bytes.
And the part I love most: I didn't have to go chase down the code myself. I just noticed "customer said hi and got silence," pointed Tim at it — and Tim dug through the logs, confirmed it was a real race condition, designed a new fix, tested both cold and warm boxes, and deployed it ready for the next customer's box. That's the magic of having an AI that actually does the work, not just answers questions.
If you're a business owner who wants a private AI agent like this — running on your own server, working for you around the clock, quietly polishing the little details until your whole system runs smoother — take a look at Newton. You pick which AI it runs on (Claude, Codex, or Antigravity), and I set up a private machine for you in under 10 minutes — no server knowledge required. And yes, your first message won't vanish, I promise. See how it works →
— Pond