A fork becomes hard to describe when it stops being one program. Kilo Code’s public README is unusually direct: its CLI is a fork of OpenCode, enhanced for Kilo’s agentic engineering platform. The same page points readers to VS Code, JetBrains, a CLI, a cloud agent, automated code review, and an always-on agent surface.
The useful question is not whether that list sounds like a platform. It is where the source starts requiring Kilo-specific promises that upstream code cannot make by accident. Two July 22 changes give a good answer: one sends work from a local repository into a cloud task; another lets a running remote session notify a person. A third leaves literal breadcrumbs where Kilo’s session processing diverges from upstream.
A cloud command has to decide what a repository means
The new kilo cloud commit is not a thin request wrapper. It adds command wiring, authentication, model/default discovery, request and response contracts, streamed updates, repository resolution, and focused tests. Its repository parser accepts a GitHub shorthand, a standard GitHub SSH URL, or a validated HTTPS source; it rejects unsafe branch strings, credentials in URLs, ambiguous remotes, and a missing worktree.
That validation is a small but important product boundary. Once a CLI hands a repository to remote execution, the repository name and branch are no longer just local convenience. They become a request describing what an external service may fetch and run. The tests assemble a task from a checked repository and assert the expected organisation, repository, agent mode, and queued delivery. They prove the source contract, not that a particular cloud account has executed it successfully.
Notification is another delivery contract
The notify_user change follows the same discipline. The tool does not create a free-floating phone-push shortcut. It sends an agent_notification over the session’s existing authenticated ingest channel, waits only a bounded time for readiness, returns a friendly failure when the session is disconnected, and hides the tool when remote operation is disabled.
Its receipt is engineering-sized: the patch adds 1,235 lines and changes twenty files, including a 483-line session-delivery test and a focused tool test. Those counts are not the story. The story is the shape of the tests: delivery, bootstrapping, disabled remotes, and tool registration are treated as one interface. A notification that arrives in the wrong session—or silently broadens a local agent’s reach—is a user-trust failure, not a cosmetic bug.
Forks need source-visible seams
Kilo also made one small maintenance choice unusually legible. In the upstream-divergence commit, kilocode_change markers surround local handling for late tool-input events in the session processor and its test. That is not a complete map of the fork. It is, however, a practical acknowledgement that future merges need to know which behaviour belongs to Kilo.
That is the transferable lesson for fork maintainers: put the product boundary where the user can observe it, then make it source-visible enough to survive an upstream update. Name the remote identity, validate the handoff, test its failure state, and mark the narrow local seam. Kilo’s public source shows that work beginning. It does not yet prove that the hosted agent is reliable, inexpensive, or widely used. Those are the next receipts the platform will have to earn.