How to Make Claude Code Run OpenCode and Benchmark Models by Itself

The most interesting moment in AI right now is not a new model. It is the quiet shift where one agent learns to run another agent, and does it on its own hardware while nobody watches. I am Madhuranjan Kumar, and I want to walk you through a build that captures that shift perfectly: a Claude Code agent, living on a dedicated Mac Mini, taught to launch OpenCode from the command line, point it at any model through OpenRouter, and benchmark several models in parallel without a human touching the keyboard. Once you see it work, a chatbot stops feeling like a toy and starts feeling like a machine you own.

The premise that changes everything

For most of the last two years, we treated AI as a single conversation. You open a window, you type, it answers. That framing quietly caps what the technology can do for a business, because a conversation needs a person on the other end. The premise that breaks the cap is small but powerful: the orchestrator does not need to know everything itself. It only needs to know how to call the right tool and read the answer back.

That is the entire trick here. A Claude Code agent runs autonomously on its own Mac Mini, and the goal of the session is not to solve one problem but to teach the agent a single genuinely repeatable skill it can reuse forever. The skill is running OpenCode as a tool. Because OpenCode can be pointed at any model, and Claude Code can call OpenCode, one agent can now drive another coding agent with whatever engine you name. The day a new model ships, this setup can test it before lunch, with no re-teaching and no fresh instructions from you.

I keep coming back to that idea because it reframes what an agent is for. It is not a smarter search box. It is a worker that can pick up other tools.

Feed it the truth before you ask it to act

There is a discipline underneath this build that matters more than any single command, and it is the thing I would want a business owner to take away even if they never touch a terminal. Before writing a line of code, Madhuranjan Kumar fetches the real OpenCode CLI documentation and pastes it into a local markdown file, then tells Claude Code to read that file and find the correct way to run a set model and prompt.

This sounds trivial. It is not. The single most common way AI work fails is a model confidently inventing a flag or an API shape that does not exist, then building an entire pipeline on top of the hallucination. Handing the agent ground truth first, the actual docs, in a file it can read, is the cheapest reliability upgrade available anywhere in this field. The agent discovers the run flag from the documentation instead of guessing it, and everything downstream inherits that correctness for free.

When the agent finds the pattern, the resulting command is clean. You call opencode run with a model flag and a prompt, routed through OpenRouter using an API key already wired in, and one line returns the answer headless. No window, no clicking, no waiting for a person. Just a prompt in and an answer out, on demand.

I want to linger on why the docs-first habit is worth more than it looks, because it is the part a business owner can adopt even without any of the surrounding machinery. When a model guesses a flag, it does not guess randomly. It guesses plausibly, which is far more dangerous, because a plausible wrong answer sails past a quick review and only fails three steps later when you have already built on top of it. Pinning the agent to real documentation removes that entire failure mode at the source. The agent is no longer reasoning about what the command probably is. It is reading what the command actually is. That distinction, between probable and actual, is the quiet line that separates AI work you can trust from AI work you have to babysit, and it costs you nothing but the two minutes it takes to paste a docs file into the repo.

A tiny test proves the whole mechanism

I love that the proof of life here is not some grand benchmark. It is a joke of a question: should I walk or drive to the car wash if it is fifty meters away. GLM 5 answered walk. Gemini 3 Pro answered drive, reasoning that you cannot wash a car you left behind. The point was never the right answer. The point was that a single command, unchanged except for one word, could route the same prompt to two completely different engines and bring back two distinct reasoning styles.

Because OpenRouter sits in the middle, switching from GLM to Gemini to Minimax to Opus is a one word change in the same line. That is the muscle you actually want. You are not marrying a model. You are building a socket that any model can plug into, so your business is never trapped by a single vendor's pricing, outages, or quality swings.

This matters more than it looks. The models that lead the pack change every few months. A team that hard-wires itself to one provider has to rebuild every time the leaderboard shifts. A team that builds the socket just swaps a name. Over a year, that is the difference between a stack that ages badly and one that quietly gets better every time the field moves, without any migration project or vendor negotiation. You are not betting on which model wins. You are building so that the winner, whoever it turns out to be, plugs straight in.

From a trick to a permanent capability

The moment the command works, Madhuranjan Kumar does the one thing most people skip: he tells Claude Code to save the whole flow as a reusable Skill, a plain markdown file describing the steps. That single act is the difference between a clever afternoon and a compounding asset. Now the agent can run model benchmarks on demand, and nobody has to re-teach it what OpenCode is or how the run flag works.

To show off what the crystallized skill can do, he runs a real creative test across four engines at once. Every model gets the same prompt, build a full screen retro arcade space battle in a single HTML file, and GLM 5, Minimax 2.5, Gemini 3 Pro, and Claude Opus all execute in parallel. Each model saves its result to a fixed path, something like game-glm5.html inside an llm-test folder. That strict naming convention is quietly the most important engineering decision in the build, because pipelines almost never fail on a weak model. They fail when the filenames are loose and the next step cannot find the outputs.

With four clean, predictably named files sitting on disk, a separate Remotion skill stitches them into a side by side grid video labeled by model, turning a technical comparison into a single shareable clip. Then the agent drafts the accompanying social post, injects this breakdown, writes the caption itself, and stops at a draft rather than publishing. The full loop, from prompt to a publishable post, runs hands off, and the human only steps in to hit send.

Why this is a business tool, not a party trick

Strip away the space battle and what remains is a method any company that has to choose between AI tools can use tomorrow. The value is never the specific test. It is the discipline underneath it: fetch real docs, prove the mechanism on a small question, enforce strict outputs, and bottle the working flow as a Skill so nobody re-teaches it.

A marketing agency can benchmark which model writes the best ad copy before committing a client's budget, and that kind of proof feeds directly into the creative that moves cost per lead on Facebook and Instagram ad campaigns. A law firm can compare how different engines summarize the same contract and pick the one that misses the fewest clauses. An e-commerce brand can test which model writes the cleanest product descriptions at the scale its catalog demands, then let that same content foundation strengthen its SEO and organic search without any extra work. A real estate team can compare listing descriptions before paying for one. A staff accountant can test which engine untangles a messy ledger most cleanly. Only the prompt and the judging criteria change by industry. The underlying loop never does.

Let me make it concrete with one worked example. Imagine a med spa owner who is the practitioner, the marketer, and the front desk all at once, and who is constantly asked to write content: treatment descriptions, reactivation emails, post care instructions, and ad captions. Instead of picking a model on a hunch, the owner stands up the orchestrator agent, feeds it the real docs for the tools it will call, and runs the spa's actual prompt, draft a 90 day reactivation email for clients who have not rebooked, across four models in parallel through OpenRouter. Each result saves to a fixed path like email-glm5.html and email-opus.html, and the agent lays them side by side, labeled, so the owner can read all four between two appointments and pick the voice that actually sounds like the brand.

Say the whole comparison, once, takes the owner ten minutes to review instead of the hour it would take to write and rewrite by hand. That flow then gets saved as a Skill. Next month, when a new model launches, the spa reruns the benchmark in about four minutes and knows immediately whether it beats the incumbent. The leads those reactivation emails bring back land in the CRM and website stack where follow up automation carries the next few touches. The spa keeps doing exactly what it did before. The one difference is that its content is now produced by the proven model, not the lucky guess, and the proof gets cheaper to rerun every single time.

The part I want you to steal

You do not need a Mac Mini or a dedicated agent to take the lesson from this. The reusable pattern is four habits, and they cost nothing but attention. Give your agent real documentation instead of letting it guess, by pasting the tool's actual CLI docs into a file it can read. Prove the mechanism on a tiny throwaway prompt before you scale it, exactly like the walk or drive question, so you know the plumbing is sound. Run the same prompt across two or three models in parallel and force a strict output naming scheme, because loose filenames are what actually break pipelines. And once the flow works end to end, have the agent save it as a Skill so it never needs re-teaching.

None of that requires you to be a hardcore engineer. It requires you to be disciplined about docs, tests, naming, and reuse, which is honestly a better description of good engineering than most job listings manage.

The reason I keep pushing this on business owners rather than only on developers is that the discipline is what compounds, not the code. Anyone can run one benchmark once. The value shows up on the tenth benchmark, when a new model has launched and you already have a saved Skill that reruns the whole comparison against your real prompts in minutes. Every time you resist the urge to guess and instead feed the agent ground truth, prove the mechanism small, name your outputs strictly, and save the flow, you are lowering the cost of the next decision your business has to make about AI. That is the actual product of this build. Not a space battle video, but a company that can answer which model to trust, cheaply and repeatedly, while its competitors are still arguing about it in a meeting.

I would start this week by feeding your agent the real docs for one tool you keep reaching for, and running a single throwaway test to watch the socket work. That one step is where the whole idea clicks from theory into something you own. If you would rather have someone wire up the orchestrator, set the benchmark against your actual business prompts, and hand you a reusable Skill that runs hands off, that is exactly the kind of build I do for clients, and you can bring me in to handle it.