Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarytools and plugins / 2026-05-19

The model is the replaceable part

Shared Markdown contracts, consistent memory files and shell-callable tools let more of your workflow survive a model change. Each new harness still has to meet the contract.

8 parts / Hover to explore. Click to read.

Shared Markdown contracts, consistent memory files and shell-callable tools let more of your workflow survive a model change. Each new harness still has to meet the contract.

Readable behaviour contracts
Shared memory at known paths
Tools with stable CLI interfaces
              |
       compatible harness
              |
       chosen model
              |
       validate the result
Keep behaviours, context and tool interfaces usable across compatible readers. Each harness still needs integration, permissions and validation; a tool may use a vendor SDK internally.

I wanted to choose a model for the work in front of me without rebuilding my toolkit every time.

My coding workflow ran through Claude Code, Codex CLI and Kimi CLI. Those are different harnesses around models, with different ways to discover instructions and call tools. I had ended up maintaining three versions of capabilities that should have been shared.

I ported one, then another. The second was slightly behind the first. Soon I wasn't sure which version was the one to trust.

The part worth keeping was the method I'd built. I needed to give it an interface that could survive a change of model or harness.

Find where the dependency lives

A useful capability can become tied to a vendor almost by accident. You write it in the tool you're using, borrow that tool's names and assumptions, and leave the behaviour inside its SDK calls.

Later, a different harness can't discover the instructions or invoke the same operation. Now the choice of model comes with a porting job.

Look at what actually needs to move: the instructions, the remembered context and the executable tools. Separating those gives you somewhere stable to put the work.

Two panels: on the left, three capability boxes funnel into a single CLAUDE bubble while GPT and KIMI sit greyed out. On the right, a CONTRACTS / MEMORY / CLIs stack fans out to three equal CLAUDE, GPT, KIMI model boxes.

The diagrams show the intended separation. A new runtime still has to meet the contract; the arrows don't prove compatibility.

Write behaviour as a readable contract

A Markdown capability describes what to do, the required output format and the rules it must respect. That lets more than one harness read the same definition instead of maintaining a private copy for each.

Claude Code, Codex CLI and Kimi CLI discover files differently. You still need to connect each harness to the right file and give it the required tools and permissions. Reading English isn't enough to guarantee reliable execution.

Keep the behavioural interface clear enough to judge: what inputs it expects, what a good result looks like and what must never happen. Use code for the parts that need execution.

Give memory a stable format

Preferences, recurring mistakes and project decisions belong in shared files at known paths. A new session can load that context regardless of which model is doing the reasoning.

Consistency is the cost of sharing it. Keep the same frontmatter shape and entry fields, so each reader knows what it has received. Keep the record current too; a shared stale fact is still stale.

You then have one place to correct the context, instead of three copies drifting apart.

Put deterministic work behind a CLI

Search, similarity calculations, embeddings and transformations can have shell-callable interfaces. The model supplies arguments; the tool returns structured JSON.

For example, let the program compute cosine similarity. Let the model judge what the retrieved material means for the task. Each part has a job you can inspect.

The model-facing interface can remain stable even when a tool's internal implementation changes. The harness still needs compatible execution, dependencies and permission to call it.

A three-tier stack labelled BEHAVIOURS / MEMORY / TOOLS. Tags on each layer read 'markdown contracts', 'files on disk', 'CLIs · shell-callable'. Below the stack, four model boxes (CLAUDE, GPT, KIMI, plus a dashed-outline placeholder for the next model) are connected upward with dashed lines, captioned 'reads'.

The diagram's phrase "No vendor SDK." refers to the public behaviour contract. A tool can still use a vendor SDK internally, as explained below.

Choose for the actual task

The same toolkit can support different choices. A hard reasoning problem might deserve a stronger reasoning model. A mechanical refactor across forty files might suit a less expensive model after you've checked its ability. A hundred-thousand-line transcript needs a reading and retrieval strategy that fits the available context.

Those are examples of decisions, not a fixed ranking. Test the result for the work you have. The longest window or lowest price alone doesn't settle it.

A single shared toolkit box at the top labelled CONTRACTS · MEMORY · CLIs. A connector fans out to four task boxes: Hard reasoning, Mechanical work, Long context, Quick draft. Each task box arrows down to a different model: OPUS, HAIKU, KIMI K2, SONNET. Tagline: 'choose by task · swap any time · no rewrite'.

The drawing's model labels illustrate that choice. Its clean-swap promise is a design aim: shared contracts reduce the rewrite, while harness integration and validation may still need work.

Keep SDKs inside the tools

Vendor SDKs can be perfectly useful implementation details. A CLI may call one to do its job and return the agreed JSON.

The boundary I care about is where the behaviour is defined. If the whole capability exists only as a vendor-specific sequence, every new reader inherits that integration problem. If its contract is readable and its tools have stable interfaces, more of the work can travel with you.

Build the interface with the next compatible reader in mind. You can still use a convenient integration underneath it.

Keep the judgement with you

Portability doesn't make every model equally capable. It gives you more freedom to change the worker without throwing away the instructions, context and tools you've already made useful.

A new release becomes an option to evaluate. A price change becomes a reason to reconsider a lane. Neither has to erase the workflow you've built, though each replacement still needs checking.

I want my working method to outlast the app I happen to open today. The contracts, memory and tools are how I make that possible.

The model is the replaceable part. Keep the work you put around it.

//

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 10