A reference, not a digest. The brief is replaced every morning. This is
appended to and rarely deleted from — when something here goes wrong, the line
gets a correction under it rather than being quietly removed, so you can see how
your own thinking moved.
Verified 9 September 2026. The Radar at the bottom is written by the daily job;
everything above it is hand-maintained and only changes when something real
changes.
Read this first. The single biggest gain in fluency is not knowing more
model names. It is knowing **which decisions are model decisions and which are
not.** Most people trying to get good at AI tools are tuning prompts when the
actual problem is that they gave the model no way to check its own work. The
tables below are ordered by how much leverage each one carries: harness first,
then context, then model, then prompt. Prompt is last on purpose.
| Layer | What it decides | How much it matters |
|---|---|---|
| Harness | What the model can do — read files, run code, browse, loop | Most |
| Context | What it knows about your situation | A lot |
| Model | Raw capability and cost | Moderate — and shrinking |
| Prompt | Wording | Least, and the most over-taught |
Why this order. A weaker model with a shell, your files and permission to run
a test will beat a stronger model answering from memory, almost every time. You
have already proven this to yourself: every real bug in Grand Scheme was found by
running something and measuring, not by thinking harder. That is a harness
result, not a model result.
The practical rule: before reaching for a better model, ask whether the
current one had any way to be proven wrong. If not, fix that first.
Costs move constantly; capability tiers move slowly. Pick by tier, then check
price at the time.
| Job | Reach for | Why |
|---|---|---|
| Deep debugging, architecture, multi-file changes | Frontier reasoning model in an agent harness | The job is search over a large space; this is what the extra capability buys |
| Long autonomous runs where you close the laptop | Cloud-async agent (Codex-style goal mode) | Survives network drops and session ends |
| Inline completion while you type | In-editor agent (Cursor-class) | Latency is the whole product here |
| Summarising, classifying, extracting, tagging | Local 8B (Qwen3 8B, Llama 3.3 8B, Phi-4) | Frontier models are wildly overqualified. This is your brief's whole workload |
| Anything touching client or patient data | Local, always | Not a cost decision. A jurisdiction decision |
| Bulk cheap work at volume | Small hosted model | Cents; do not burn frontier budget on it |
| Drafting in your own voice | Frontier + your own examples | Needs the examples far more than the model |
Roughly: an 8B model at normal quantisation is about 5GB, which is why 8B is
the laptop default. Rules of thumb by RAM — **16GB → Phi-4 · 36GB → Llama 8B ·
64GB → Qwen 34B · 128GB → Llama 70B**. Ollama is the right runner for you:
simplest path, native Mac support, and it exposes a local API so your scripts can
call it exactly like a hosted one.
Qwen3 has become the default answer for "what do I run locally" — 8B, 14B and
30B are the practical sizes. Llama 3.3 has the largest fine-tune ecosystem.
Phi-4-mini (3.8B) punches above its size on constrained machines.
Your existing tagging habit is the right one. Keep marking every recurring
job LOCAL or FRONTIER. That tag is a migration plan, a privacy audit and a cost
control at once, and almost nobody does it.
MCP (Model Context Protocol) is the standard way a model reaches tools and
data. Anthropic introduced it in November 2024; in **December 2025 it was donated
to the Agentic AI Foundation under the Linux Foundation**, making it
vendor-neutral. By 2026 it is near-universal — Anthropic, OpenAI, Google and
Microsoft all support it natively, with reportedly **10,000+ MCP servers in
production** and SDKs downloaded ~97M/month.
The 2026-07-28 spec revision is the one to know about. Described by MCP's own
maintainers as the most substantial change since authorization was added. It
brought:
Why this matters to you specifically: a stateless core means an MCP server can
be a plain serverless function. That puts "write a small MCP server" inside a
Cloudflare Worker — the same place your brief now runs — instead of requiring a
box that stays up. For someone building operational tooling for small
organizations, that is the difference between a product and a side project.
Security, and take this seriously: the NSA published an MCP security guidance
document in June 2026. If you are going to sell systems that connect models to
client data, read it. It is also the single best credibility artifact you could
cite in a board conversation — you would be one of very few people in the room
who has read the primary source.
An agent harness is the loop around a model: what tools it has, how it keeps
context, whether it can run and check its own work. This is the layer with the
most leverage and the least public discussion.
| Harness | Shape | Best at |
|---|---|---|
| Claude Code | terminal-first, deepest programmable harness | deep reasoning, debugging, architectural change; ~1M-token context reads large repos without a prebuilt index |
| Codex CLI | broadest surface, low entry price | cloud-async — a goal survives network drops, a closed laptop, hours-long runs |
| Cursor | strongest in-editor agent | fast inline agentic editing; reads .cursor, .claude/agents and .codex/agents configs |
On the Artificial Analysis Coding Agent Index: **Claude Opus 4.7 in Claude Code
(max) ≈ 66, GPT-5.5 in Codex (xhigh) ≈ 65, Cursor Composer 2.5 ≈ 62** — the last
being the cheapest agent above 60 by a 10–60× margin.
The settled pattern most developers land on: two or three agents. One heavy
agent for real work, one inline completer, one open-source agent for model
flexibility. Not one tool for everything.
Sub-agents. Each gets its own context window. Ten workers with one clear job
each beat one worker carrying ten. When a task has genuinely separable
parts — research, then build, then verify — splitting them is not tidiness, it is
what stops the context filling with irrelevant history.
Ordered by return for you specifically, given what you build.
Evals. A test suite for non-deterministic output. You already do this
instinctively — the headless simulations, the 30-game measurements. Formalising it
is the single highest-leverage skill on this page. It is also the thing you could
sell: "we do not ship AI features without evals" is a genuine differentiator to
a nervous board.
Structured output / tool-call schemas. Force the model to return JSON matching
a schema instead of parsing prose. Removes an entire class of silent failure.
Prompt caching. Reuse a large stable prefix across calls at a large discount.
If your brief sends the same instructions 47 times a morning, this is free money.
RAG, and knowing when NOT to. Retrieval matters when the corpus is bigger than
the context window. With today's windows, many small-org problems just do not need
it — you can put the whole thing in the prompt. Reaching for RAG first is a common
and expensive mistake.
Distillation / fine-tuning a small local model on your own frontier outputs.
This is the concrete path from "cloud does everything" to your Local AI OS
north-star: use a frontier model to generate examples, train a small one, run it
on your own hardware forever.
Speculative decoding. A small model drafts, a large one verifies. Same output,
meaningfully faster. Increasingly on by default — worth knowing the name so you
recognise it in a vendor's claims.
Computer-use / browser agents. Models that drive a UI. Genuinely useful for
systems with no API — which describes most software a small business already owns.
This is an underpriced consulting angle.
Guardrail models. Small classifiers that check input and output for policy
violations. Directly relevant to Sentinel: the policy is the document, the
guardrail is the enforcement, and selling both is worth more than either.
Not "read more news." Four habits, in order.
1. Build the eval before the feature. Ten examples with known-good answers.
Now every model, prompt or harness change is a measurement rather than an opinion.
This one habit is most of the gap between people who sound fluent and people who
are.
2. Re-run one old task on a new model, quarterly. Not a benchmark — your
task, one you know the right answer to. Benchmarks tell you about the benchmark.
3. Keep the LOCAL/FRONTIER tag current. You already do this. It is a rehearsal
for the migration and a privacy audit at the same time.
4. Write the correction down when you are wrong. You already run RULINGS.md.
Extend it to model behaviour. *"Model X confidently invents citations under
condition Y"* is worth more than any article about model X.
The trap to avoid. Chasing releases produces the feeling of fluency and none
of it. The people who are genuinely good at this have three or four tools they
know deeply and a measurement habit. Depth beats breadth here, and it is not
close.
Watch these; do not act on them yet.
goal. Your Loop Kernel is early-correct on this.
frontier spend becomes local-capable. This is your acquisition thesis quietly
getting cheaper.
settled — worth watching, too early to build on.
This is the strongest tailwind under the Local AI OS idea.
audited. Every step in that direction prices Sentinel higher.
Everything in section 2 about relative capability has a short half-life. The
structure — harness over model, evals over prompts, local for sensitive data,
tag everything — has a long one. When those two disagree, trust the structure.
And I do not know everything current. Where I was unsure I said so rather than
smoothing it over, and the Radar below is generated from live sources
specifically so this document is not limited to what I happened to know on the
day I wrote it.
No radar entries yet. Run Apex.command and this fills in.