C.W.K.
Stream
Lesson 01 of 04 · published

Two Halves, One Call

~11 min · boundary, client-server, separation, narrow-interface

Level 0Cold Flint
0 XP0/34 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Flint knows how to grab the words and put them back. It does not know how to think. That line is the whole architecture."

Two Halves, One Call

Flint is one half of a two-part system, and the halves meet at a single narrow point: one request across a boundary. On Flint's side is everything physical and local — the gesture, the target, the macro list, the shortcuts, the insertion. On the other side is everything intelligent — the model, the persona, the effort, the actual transformation. Between them is not a shared library or a tangle of calls; it's one finished prompt going out and one transformed string coming back.

The Client Half

Flint's half is the part you can see and touch. It captures which app and which text you meant. It stores your macros and their chords locally. It renders a prompt. It proves the target and inserts the result. None of that requires understanding language — it requires understanding macOS, focus, pasteboards, and safety. Flint is, in a sense, a very careful pair of hands with no opinion about what the words should become.

The Brain Half

The other half is the part you never see inside Flint, because it isn't there. Which model runs, whether a persona is applied, how hard the model thinks, where inference happens, and every credential that makes it possible — all of that belongs to the borrowed brain. Flint doesn't route models or hold keys; it names a choice ('this macro, local tier, vault bypassed') and hands the finished prompt across. The intelligence is a service, and Flint is its client.

FLINT (client half)          |  BORROWED BRAIN (intelligence half)
-----------------------------|------------------------------------
gesture / hotkeys            |  which model runs
target capture               |  soul / persona
macro CRUD (local)           |  effort level
prompt rendering             |  the actual inference
guarded insertion            |  all credentials & routing
                             |
         one request  --->   |   one transformed string  <---

Why the Line Is Drawn Narrow

The narrowness is the point. Because the only thing crossing the boundary is a prompt and a result, you can change either side without disturbing the other. Swap the model, add a new persona, move inference from local to a server — Flint doesn't change, because it never knew those details. Rewrite Flint's insertion logic — the brain doesn't care, because it only ever saw a prompt. A wide boundary couples two systems into one you can't reason about; a narrow one keeps them two.

Flint inherits the house rule: keep the boundary narrow, absorb cost downstream. This is the same discipline the whole cwkPippa family runs on — the interesting complexity lives behind a thin seam, and the client stays simple by refusing to know the server's internals. Flint is a client of that brain, so it carries the rule outward: know as little about the intelligence as the job allows, and pay for that ignorance with a clean, stable contract.

Code

The brain, from Flint's side, is one thin call·swift
// Everything Flint knows about the intelligence fits in this interface.
protocol BrainClient {
    func applyFree(prompt: String,
                   vault: VaultContextMode,
                   tier: OllamaTier?) async throws -> String
}

// Flint holds no model, no key, no routing table. It sends a finished
// prompt and its execution choices, and awaits a transformed string.
// Swap the implementation (local, server, cloud) and Flint is unchanged.
let result = try await brain.applyFree(prompt: rendered,
                                       vault: macro.vaultContextMode,
                                       tier: profile.ollamaTier)

External links

Exercise

Draw the two halves of Flint and label every responsibility on the correct side. Then pick two realistic changes — 'we switch the default model' and 'we rewrite how insertion handles terminals' — and for each, say which half changes and why the other half doesn't even notice. What property of the boundary makes that independence possible?
Hint
Model choice lives entirely on the brain side, so switching it never touches Flint's capture or insertion. Terminal insertion lives entirely on Flint's side, so rewriting it never touches the brain, which only ever saw a prompt string. The enabling property is the narrowness: only a finished prompt and a result cross the line, so neither side depends on the other's internals.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.