jcode

The trait worth trying is that every tool behaves the same over SSH as it does locally. If your real environment is a build box or a staging server rather than your laptop, that removes the awkward gap where the agent understands your machine and not the one the code actually runs on.

Be honest about the stage though. This is very new and almost nobody is using it, so you would be finding the bugs. Try it on a side project, pick Claude Code for anything with a deadline, and revisit in six months.

Coding agents are debugged by exposure. The interesting defects are not in the code paths a maintainer tests but in the strange repository, the unusual toolchain, the model that returns something unexpected, and finding those requires users the project does not have. A quiet issue tracker on a young project is an absence of evidence, not a record of quality.

Treat any early adoption as a pilot with a rollback. What it does right: every tool call is visible and requires approval, which is the correct default and one that older, more popular agents took years to reach.

Two design choices are worth naming. 1. Planning is separated from execution by a mode that cannot write, so the artefact a user reviews was produced under a guarantee rather than a promise, which is stronger than asking a model to plan before acting. 2. Tool implementations are shared across local, remote and containerised execution, so a plan validated in one environment carries to another without a second code path to diverge.

Verification after execution is not described, and no benchmark is published, which for a project this young is unsurprising rather than evasive.

Nothing to underwrite and nothing to acquire. Terminal coding agents are where the frontier labs, the editor vendors and a dozen funded startups all compete simultaneously, and an unfunded entrant needs a distribution wedge rather than a feature advantage, because features are matched within a quarter by teams with staff.

The remote and container parity is a plausible wedge if the author pursues it. Realistic outcomes: it stays a personal tool, or it becomes a hiring credential. Position: none, and a note that this is one person against three well-funded roadmaps.

The zero on the invoice does not survive contact with the rest of the form. No supplier means no agreement, no security contact and no commitment that anything gets fixed. There is no console, so access is per machine and per key with no central record of what ran where.

It also cannot run unattended, so it produces nothing our pipelines can measure and nothing an auditor could review. Onboarding is a script, which is the easy part and never the deciding one. Not yet. Revisit when there is an organisation behind it and someone to sign a support commitment.

This is built the way I would build it. One Go binary from an install script or a make install, MIT so the source is mine, and a model layer that accepts any OpenAI-compatible endpoint, which means the server in my basement is a first-class provider and no key leaves the house.

MCP configuration is a JSON block declaring servers as stdio commands or http urls, so my tool wiring lives in a file I commit rather than a menu I click. It runs inside Docker with the same tools, so I can hand it a container and relax. Small project, correct instincts, and I can maintain it myself.