Interactive CLI vs Agent SDK
Both reach the same underlying model, which is why the two get conflated. Everything that actually matters about the choice sits around the model rather than in it: how access is billed, whether a human is in the loop, and what you are allowed to build on top.
Which one should I be using?
If a person is steering the work and you want the model covered by the subscription you already pay for, you want the interactive CLI. If you are building software that drives a model on its own schedule, you want the Agent SDK and the metered bill that comes with it. The trap is a tool that presents itself as the former while quietly running the latter, because that moves your spend without telling you.
What each one actually is.
Stated plainly, without the vocabulary either camp uses to make its own option sound like the default.
Interactive CLI
A coding agent you run in your terminal and stay with. It works in your repository, on your machine, and stops to ask when it wants to do something consequential. Access is covered by the model subscription you already hold.
- Runs under your existing subscription, not per-token billing
- Pauses at permission and plan decisions for a human answer
- Has your working tree, tooling, and credentials already in place
- Produces a session another person can be shown or handed
Agent SDK
A library you call from your own code to drive a model as part of a system you are building. There is no terminal session and nobody is sitting with it. Usage is metered as API consumption and billed per token.
- Billed as metered API usage, separate from any seat subscription
- No interactive pause: your code decides what is permitted
- You provide the environment, the context, and the control flow
- Composable into products, pipelines, and unattended automation
Where they diverge.
The dimensions that actually change your decision, rather than every dimension that exists.
| Dimension | Interactive CLI | Agent SDK |
|---|---|---|
| Who is watching | A person, during the run. The session pauses for them. | Nobody. Your code is the only supervisor. |
| How access is billed | Inside the model subscription you already hold. | Metered API usage, charged per token. |
| Where it runs | Your machine, in your working tree. | Wherever your program runs. |
| Permission model | Interactive gates: the agent asks and waits. | Whatever your code enforces before it calls. |
| What you get back | A live session with visible activity and decisions. | Responses and tool calls your program handles. |
| Good for | Real work on a real repository, with judgement applied as it goes. | Products and automation where a human cannot be in the loop. |
| Not good for | Anything that must proceed with nobody available to answer. | Work needing a person to make judgement calls mid-run. |
Three things people get wrong about this.
All three come from treating the SDK as the grown-up version of the CLI. It is not a progression, it is a different shape of access.
Assuming the SDK is simply more capable
The model is the same. What the SDK adds is programmability, and what it removes is the supervised session. If your problem is that you cannot see what an agent is doing, moving to the SDK makes that worse, not better, because you have taken the session away.
Not noticing when the bill changes shape
A subscription is a fixed monthly amount for supervised use. Metered API usage scales with tokens. A tool that runs the SDK on your behalf while looking like a terminal session has moved you from the first to the second, and you find out from the invoice.
Thinking oversight tooling can bridge them
Attaching to an interactive session and calling an SDK are genuinely different integrations. A product built around the CLI reports what a real session is doing. It cannot manufacture that visibility for SDK calls, because there is no session there to report on.
Which one fits your situation.
Neither is the advanced version of the other. They answer different questions, and plenty of teams end up wanting both.
Reach for the CLI when
- A person is available to answer permission and plan decisions as they come up.
- The work involves your actual repository, with its existing state and credentials.
- You want the model covered by the subscription you already hold.
- You want a run somebody else can be shown afterwards, decision by decision.
Reach for the SDK when
- You are building a product or pipeline where the model is a component.
- The work has to proceed on a schedule with nobody available.
- Your own code can decide what is permitted, without asking anyone.
- You accept metered API billing that scales with how much you use.
Virex Remote is built around the CLI, on purpose.
The oversight story only exists because an interactive session exists to oversee. That is a deliberate limit rather than a gap.
It attaches to a real session
A daemon on your machine reports what a Claude Code session is doing over a live link. There is nothing to attach to on an SDK call, because no session is created.
Your subscription stays your subscription
Sessions run under the model subscription you already hold. Virex does not resell or meter model usage, so using it does not move you onto a metered API bill.
The pause is the product
Permission and plan decisions are the moments Virex Remote exists to surface and answer. Those moments are a property of interactive sessions and have no equivalent in SDK calls.
Interactive CLI and Agent SDK questions
What is the difference between an interactive CLI and an Agent SDK?
An interactive CLI is a supervised session you sit with: it runs under your own model subscription, pauses to ask permission, and bills as part of that subscription. An Agent SDK is a programmatic entry point you call from your own code, billed as metered API usage, with no session for a human to join.
Do they reach the same model?
Broadly yes. The difference is not model capability but the shape of access: one is a supervised session under a subscription, the other is a programmatic call metered per token.
Which one does Virex Remote work with?
Virex Remote is built around the interactive CLI, with Claude Code as the primary integration. It attaches to a session that already exists on your machine rather than starting agents through an SDK.
Why does the billing distinction matter so much?
Because it changes who pays and how the cost scales. A supervised CLI session is covered by the subscription you already hold. SDK calls accrue metered API charges, so a tool that quietly moved your work onto the SDK would move you onto a different bill without asking.
Can a team use both?
Commonly, yes. Interactive sessions suit work a person is steering, and SDK calls suit automation that runs without anyone watching. They are different jobs rather than competing choices.
Keep your sessions. Add the oversight.
Virex Remote attaches to the Claude Code sessions you already run, under the subscription you already hold.