There's a post going around from someone who spent more than a year living inside Claude Code, running bioinformatics pipelines locally with DeepSeek and deploying the tooling on a shared Sugon server, and came out the other side convinced these things don't need to be complicated. His summary is blunt: the model API is really just an HTTP request plus an SSE stream, the tools are nothing more than reading and writing files and running commands, and the interface can be a plain line-by-line terminal session — not even a TUI. He wrote his own agent in Rust, called it `llm`, shipped it as a single statically linked musl binary with zero runtime dependencies. His line that stuck with me: on that old CentOS 7 box where the glibc was so ancient he'd had to drag conda in just to get Claude Code running, the new binary was `scp` it over, `chmod +x`, done.
That instinct isn't isolated. Look across what people are shipping right now and you see the same move repeated. Someone wrote `rttsh`, a thin command-line wrapper around J-Link RTT plus an MCP surface so an AI coding tool can flash a board and check the board's actual replies instead of taking the model's word for it. Someone else built a Home Assistant bridge for Xiaodu speakers that's pure Python, no third-party dependencies, a minimal-permission token that can only hit its own endpoints, and 276 tests. Different domains, same shape: keep the core small, own the whole thing end to end, and when it breaks you know exactly where to go.
What the loop actually is
Strip the marketing off any coding agent and the essential loop is short. You hold a system prompt and a running list of messages. You send them to a model. The model streams back text, and somewhere in that text it may ask to call a tool. You dispatch the call to a tiny set of functions — read a file, write a file, run something — append the result back into the message list, and go around again until the model stops asking for tools. That is the entire engine. Everything else is ergonomics.
The Rust `llm` design leans hard into this. Its extension model is telling: drop a script with a few comment lines at the top declaring name, description, args, and interpreter, and it becomes a tool the host spawns, feeds arguments, and reads stdout back from. A tool is just a program that prints a result. Once you internalize that, the platform you run on matters less than the loop you understand.
Rebuilding the loop on VicroCode
So the interesting exercise is taking that thesis literally and rebuilding the minimal loop somewhere you can inspect and fix it. On VicroCode the pieces map cleanly onto confirmed capabilities. The model call goes through the Model Center APIs, for models that are already available on the platform. The tool backend — the read file, write file, run-a-thing side — is where Python earns its place: you can back the whole tool set with the ability to run Python online plus file management for the read and write operations. Session state and configuration, the thing `llm` keeps under `~/.llm`, fits a small SQLite database you can edit directly. If your agent needs retrieval context, a LanceDB knowledge base slots in. Then you wrap the loop as a hosted API endpoint with in-platform tool calls, and you have a coding agent you can hit over HTTP, poke at, and repair — which is the practical heart of AI agent development when you want to actually own the thing rather than rent a black box.
The safety layer is worth porting too, because the Rust author is honest about its limits and you should be as well. His blacklist and per-tool allow/deny/prompt policy live in config, and he says plainly that the check is lexical — it sees the parsed command segments, not what gets stitched together at runtime, so it's a prompt, not a locked cage. If you rebuild guard logic in your Python endpoint, carry the same honesty: it filters what it can see, and the real protection is running with least privilege, not pretending the filter is airtight.
One thing you must not skip: an endpoint that calls a model and runs code is network-exposed by definition. If you stand it up without authentication or access control, anyone who finds the URL gets to drive your agent and burn your model quota. Put auth in front of it before you share the link. That's not optional polish, it's the difference between a tool and a liability.
The boundary, stated plainly
Here's where the analogy breaks, and it breaks in exactly the way that made the Rust story compelling. The whole payoff of `llm` was the dependency-free static binary you `scp` onto a crusty CentOS 7 machine and run without touching root or fighting glibc. VicroCode cannot produce that artifact. It doesn't build a binary you carry to some other server; the runtime *is* the hosted platform. You're not distributing an executable, you're hosting the loop where the platform lives. That's a genuine trade, not a footnote — you gain a place to publish, share, and monetize the result, and you give up the portable-binary-on-any-box property entirely.
A few smaller edges follow from the same line. The Rust agent's "run commands" tool is arbitrary shell on a machine you control; the VicroCode equivalent is scoped Python execution and in-platform tool calls, not a shell prompt on a foreign host. And I'd flag the token-streaming detail as unverified: the confirmed capability list covers Model Center APIs and endpoint hosting, but whether a hosted endpoint streams tokens SSE-style the way the terminal REPL does is something to confirm on the platform before you promise it in a UI. Anything past these lines — another language runtime, a different cloud, a specific deployment method — isn't something to infer.
Why bother
Because the signal underneath all these projects is that the value has moved from the wrapper to the loop. People are done treating agents as monoliths they can only configure and hope. If you can hold the essential loop in your head, you can rebuild it on whatever runtime you actually have, and a hosted Python endpoint is a perfectly reasonable runtime when the alternative is a binary you'd have to babysit across a fleet of machines. If you're coming at this fresh and want the fundamentals of AI coding before you wire the pieces together, that's the place to start — then build the smallest loop that works and leave seams everywhere else, so when it breaks you know where to go.