An Open Client and a Closed Model: Four Things the Licence Buys

You can read, modify and embed the part that orchestrates. The part that thinks is a hosted service, and the licence is silent about it.

The client is open; the thing that thinks is not

A permissive licence on an agent's command-line client is a genuine and underrated advantage, and it is routinely used to argue something it does not support. The client is open source. The model it calls is a hosted service behind an API, governed by terms of service and a price list, and no licence on the client changes that.

So the correct claim is narrow: you can read, modify, fork and embed the part that orchestrates. You cannot run the part that reasons, you cannot fork it, and if the service changes its behaviour, its pricing or its availability, your open-source client will faithfully carry out the new arrangement.

That is still worth a lot. It is worth precisely four things, and being clear about which four is more useful than the general feeling that open is better.

One: you can read the prompts

The most immediately valuable and the least discussed. An agent's behaviour is substantially determined by its system prompt, its tool descriptions, and the scaffolding around each tool call — and with a closed client all of that is inferred from behaviour.

Being able to read it converts a large amount of folklore into fact. Why does it prefer this tool. What exactly does it tell the model about the repository. When does it decide to search rather than read. Teams spend real time speculating about these, and with an open client the answer is a file.

If you use an open client and have never read its prompt assembly, that is the highest-value afternoon available to you in this whole area.

Two: you can audit the parts that matter for security

Sandbox implementation, permission checking, what gets sent in a request, what is written to disk, what telemetry exists. These are exactly the questions a security review asks, and with source they have definitive answers rather than vendor assurances.

This is the argument that actually moves procurement, and it is worth making precisely: the claim is not that open source is more secure, which is not reliably true, but that its properties are checkable. For an organisation that has to attest to how a tool behaves, checkable beats good.

Three: you can embed it

A CLI you can vendor, wrap and call from your own systems without a licensing conversation is meaningfully easier to build on than one you cannot. Putting it inside an internal pipeline, a bespoke runner, or a tool your platform team maintains becomes an engineering decision rather than a procurement one.

In practice most embedding does not require source anyway — a shell invocation and a structured output format cover the majority of cases. The licence matters at the margin: when you need to change behaviour rather than call it.

Four: you can fork, and you probably should not

Forkability is real and it is the benefit most likely to be a trap. The scenario people imagine is a small patch to add an internal capability. The scenario that arrives is an ongoing divergence from a project that ships frequently, and a fork nobody has time to rebase.

Before forking, check whether the extension points cover it — configuration, hooks, tool servers, plugins. The exit ramp exists for exactly this reason and it is nearly always the better answer. A fork should be a considered acceptance of a maintenance burden, not a convenience.

What the licence does not give you

Independence from the provider, which is the thing people most often think it gives. The model, the API, the pricing, the rate limits, the retention terms and the availability are all governed by the service, and the client's licence has no bearing on any of them.

It also does not give you the ability to substitute a different model and get the same behaviour. Agent clients are tuned against particular models — prompt phrasing, tool-calling conventions, how they handle long context — and pointing one at a different model generally works, in the sense that it produces output, while behaving noticeably differently.

Openness is not a proxy for the questions you actually have

Worth saying because "open source" functions as a procurement shorthand for a bundle of properties it only partially delivers.

If the question is data retention, read the service agreement — the client's licence is silent. If it is continuity, ask about the service, not the repository. If it is auditability of what the tool does on your machines, source genuinely answers it. If it is cost predictability, that is a pricing question. Sorting which of your concerns the licence actually addresses takes ten minutes and prevents a lot of misplaced confidence.

The closed alternative is not the opposite

Fairness requires noting that a closed client is not therefore unauditable. Vendors publish documentation, security reviews and behavioural specifications, and a well-documented closed tool can be easier to reason about than an open one nobody has read.

The difference is where the burden sits. With source, verification is possible and requires your effort. With documentation, verification is a matter of trusting the description. Which you prefer depends on whether you actually have someone who will do the reading, and many organisations that choose open on principle never do.

Pin the version, whichever you use

An open client updates frequently, and the same properties that make it inspectable make it fast-moving. Behaviour changes between releases, including behaviour you depend on: how a permission is evaluated, what the default sandbox mode is, how a prompt is assembled.

So pin the version in anything automated, read the changelog on upgrade, and re-run your control verifications afterwards. The freedom to inspect is worth little if the thing you inspected was three versions ago.

Contributing back is the cheap version of forking

If you find a gap, the upstream change is usually less work than the fork, and it is permanently maintained by someone else afterwards. That calculation is unusually favourable for small behavioural fixes and unfavourable for anything specific to your organisation, which is a reasonable filter for deciding which to attempt.

It also has a side benefit worth naming: the process of proposing a change forces you to articulate the general case, and about a third of the time that exercise reveals the change was not needed — the behaviour you wanted was already configurable and nobody had found it.

How I would actually weigh it

For most teams, the licence is a secondary consideration behind capability, cost and the terms attached to your data. It becomes primary in two situations: when you must attest to a tool's behaviour to a third party, and when you intend to build a product on top of it rather than merely use it.

Outside those, the practical value is the first item on this list — you can read the prompts — and that is a real, daily benefit that has nothing to do with procurement and everything to do with understanding the tool you are using all day.

Reading the prompts changes how you write yours

Expanding on the first benefit, because it has a second-order effect worth naming. Seeing how a client structures what it sends — where your repository instructions land relative to the system prompt, how tool results are framed, what gets truncated — teaches you where your own instructions have leverage.

People write instruction files by trial and error, forming theories about why a rule is sometimes ignored. Reading the assembly answers several of those theories directly: this section is always present, that one is only included under a condition, this content is placed after the thing you hoped it would govern. That is a better basis for writing rules than experimentation.

Openness and the security review it invites

A practical note for anyone using the licence as a procurement argument. Offering source to a security team is only useful if someone reads it, and "the code is available" without a review is the same position as a closed tool with better optics.

If you are going to make the argument, budget the review: a day for someone to read the sandbox implementation, the permission evaluation, the request construction and the telemetry. That is a real and finite piece of work, it produces a document you can point at afterwards, and it converts a rhetorical advantage into an actual one.

What to check on each upgrade

A short list, since the freedom to inspect implies an obligation to re-inspect. Did the default sandbox mode change. Did permission evaluation change. Were new tools added, and what do their descriptions say. Did the telemetry change. Did anything in the prompt assembly move.

Five questions, most answerable from a changelog, and the ones that are not are answerable from a diff. That is fifteen minutes per upgrade to keep an audit current, which is cheap relative to having done the original review and then let it go stale.

The one-line version, for anyone who has to summarise this in a meeting: the licence tells you what you may do with the client, and nothing about what the service will do with your data or your money. Both matter, they are answered in different documents, and only one of them is on the repository's front page.

Read the prompt, then read your own instructions again

A concrete exercise for anyone who takes the first benefit seriously. Having read how the client assembles a request, go back to your repository's instruction file and ask whether it is placed and phrased to have the effect you assumed.

Common discoveries: a rule stated as a preference where a prohibition was intended; guidance placed where it is loaded once rather than where it is consulted; a long file whose later sections carry less weight than its first paragraph; instructions duplicating something the client already states, which adds tokens and no behaviour.

None of that is discoverable by experimentation, and all of it is obvious from the source. It is the clearest example of the licence paying off in daily work rather than in procurement.

What to tell a security reviewer

If you are asked to summarise the position, three sentences do it. The client is open under a permissive licence and its sandboxing, permission handling and request construction can be audited directly. The model is a hosted service governed by a separate agreement, and questions about data retention, residency and training use are answered there rather than in the repository. We have reviewed the client at a pinned version and re-check on upgrade.

That is accurate, it distinguishes the two questions people conflate, and it states an ongoing practice rather than a one-off assurance — which is usually what the reviewer is actually asking for.

The distinction to hold onto is between what you may do and what you can rely on. The licence governs the first: read, modify, embed, fork. The service agreement governs the second: availability, pricing, retention, what happens to your data. Teams treat an open licence as evidence about both, and it is evidence about one, which is worth saying explicitly in any conversation where someone is about to make a procurement decision on the strength of a badge.