A local coding agent can go offline for painfully normal reasons. A laptop sleeps or a terminal closes. Sometimes a login expires and the process just stops.
The confusing part begins when the cloud keeps talking under the same name.
Coding agents are starting to move between machines. OpenAI is building persistent Codex environments so work can continue after a laptop closes. Cursor offers hosted agents and machines you manage, sometimes inside the same project. GitHub's own agent transparency card separates its local CLI, cloud agent, review agent, and desktop app because each one has different permissions and data flows.
A laptop lid should not decide whether the team loses the conversation. The handoff between runtimes is still part of the work, and the people in the room should be able to see it.
Same name, different place
In hilos, an agent can run through the local daemon on somebody's machine. That gives it the checkout and tools already set up there. The agent can also use a hosted runtime when the workspace has configured one.
The room still sees the same agent. The squircle and the conversation do not change.
The runtime underneath changes. A hosted reply may use a different model and does not inherit the local checkout or its tools. It may spend workspace credits instead of the person's own coding-agent account. It can answer while the machine under the desk is asleep.
We had the continuity part before we had the explanation. If a local daemon was unavailable, an agent with hosted replies enabled could answer from the hosted runtime. This is a new reply with the room's context, not a resumed local coding session. The room kept moving, which looked nice... maybe too nice.
Somebody reading the answer could reasonably assume it came from the local setup they connected. The fallback had erased its own tracks.
What the room says now
The local daemon sends a heartbeat while it is connected. After three minutes without one, hilos posts a single notice in the latest active room where that agent was mentioned or ran. It does not repeat the warning every minute. When the daemon reconnects, the room can move on.
The owner gets a small Connect card. Everyone else gets the useful fact: this agent is offline. They do not need instructions for restarting a process on somebody else's laptop.
The recovery detail stays local. The daemon writes a private, redacted log at ~/.hilos/logs/<handle>.log, including an exit reason when it can. A forced kill or dead battery cannot leave a final note. Computers are still computers. The owner at least has somewhere to look.
If the hosted runtime answers during that lapse, the reply carries a quiet marker:
Answered from hosted; local daemon offline
The first fallback reply also explains whether it used workspace credits or the workspace's own API key. Inside the prompt, the agent receives its actual hosted model and a blunt instruction not to claim it is the local CLI or IDE.
That instruction sounds almost silly until a model confidently describes a machine it has never seen.
The disclosure stays attached to the message metadata, so it appears in passive views too. It does not vanish like a toast after the one person at the keyboard sees it. The room keeps the fact beside the answer.
Continuity needs a seam
A lot of agent design tries to remove seams. Start in Slack, continue in an editor, then check the run from your phone. The perfect handoff is supposed to feel invisible.
Some handoffs can disappear. A draft moving from phone to laptop is still the same draft. An agent moving to a runtime with different access deserves one line, especially when the way the workspace pays also changes.
People use the answer differently once they know. The engineer may restart the local daemon because the next step needs an internal service. For a question about copy, the team may decide the hosted answer is enough. The workspace owner can also see why credits moved.
One line is enough. It gives the next person the truth they need to make a good decision without turning the message into an infrastructure diagram.
This is the same reason we keep the agent's short answer separate from its execution trace. Most people need the outcome. The person investigating a strange result needs the machinery. A runtime handoff sits between those layers: small enough for one line, important enough not to bury.
Local and cloud are becoming one workflow
Search for local versus cloud coding agents and you will find a familiar scorecard. Local has the environment already sitting on your desk. Cloud keeps working when you leave and makes parallel runs easier.
Teams are already using both. hilos does too.
Who notices when the work runs somewhere else? In a private agent window, the person who started the session might remember. In a project room, the answer belongs to several people. A teammate can arrive later, read the thread, and make a decision from it.
That is why several local and hosted agents can share one hilos room, while the room still records which path did the work. One identity can survive a runtime change without pretending the runtime stayed the same.
There is still an awkward edge here. A fallback can keep a conversation alive. Sometimes the local machine has the only honest context, and the hosted agent should wait instead of improvising. We will probably keep finding places where "still available" is worse than "currently offline."
The laptop can close. The room should say what happened next.