A harness is everything around the model
An agent is a model called in a loop with tools. The model is the part you rent. Everything else is the harness: the loop, what the model sees, what it can touch, where its actions run, what survives when something dies, and what decides whether a result counts.
It matters more than it looks. On Terminal-Bench, GPT-5.4 scored 76.0% inside OpenAI's own Codex CLI and 55.1% inside a plain reference harness. Part of that gap is training on the vendor's own tools, but the lesson holds: the harness is half the system, and it is the half you control.
This piece draws a production harness as one architecture. Each part gets what it does, the choices it forces, and what good looks like. It ends with a prompt your coding agent runs to audit and improve your own harness against it.
Eleven parts in four layers
The parts group by how long they live. The brain is stateless and should restart anywhere. The hands are disposable. The state outlives both. Control decides what is allowed and what is true, and it sits where the agent cannot reach it.
Click a part to see what it does, the options with their trade-offs, and what good looks like.
The loop
BrainCalls the model, runs the tool calls it asks for, feeds the results back, and repeats until the model answers without a tool call or a limit stops it.
What good looks like- Small and owned: a few hundred lines you can read.
- Hard stops in code: steps, time and spend.
- Steering between steps, and a stop the loop handles itself.
- Retries with backoff for provider errors, and a clear end state for everything else.
- Without it
- A loop without a hard stop keeps spending until someone notices.
- On this platform
- A pinned OpenCode runs one turn at a time inside the VM, behind a port the platform owns. The chat agent's loop runs on the server with a step cap and a timeout.
How the parts meet on a single turn
A turn is where the architecture becomes a sequence. Before the model sees anything, control reserves what the turn may spend. After the model stops, control decides what happened, from evidence. Between the two, the brain and the hands do the work.
Admit
Reserve what the turn may spend, or refuse it before anything runs.
Without it The budget is checked, if at all, after the money is gone.
Keep the loop small and the context stable
The loop itself is small. mini-swe-agent reports more than 74% on SWE-bench Verified from about 190 lines, with bash as its only tool. A study of eleven production coding harnesses found that none imports a general-purpose agent framework. The loop is worth owning, and the machinery around it is worth buying.
Context is where the cost hides. Put stable instructions first and append history rather than editing it, and every step reuses the provider's prompt cache. On Opus 5.5, cached input costs 5% of fresh input. Plan for a full window before it happens, because a summary can drop the instruction that mattered.
for (let step = 0; step < MAX_STEPS; step++) {
const reply = await model.call({ system, history, tools });
history.push(reply); // append, never edit
if (!reply.toolCalls.length) return reply; // it answered: done
for (const call of reply.toolCalls) {
const result = await sandbox.run(call); // the hands
history.push(toolResult(call, cap(result))); // capped, head and tail kept
}
if (spent() > budget || stopRequested()) break; // stops live in code
}Run each action at the isolation it needs
Every harness that runs model-written code has to decide where it runs. The answer is a ladder, not one product: climb only as high as the work needs. Searching a knowledge base needs no machine at all. Running a stranger's repository with network access needs its own kernel.
- 01Virtual shellNo real machine: a shell interpreter over an in-memory filesystem. just-bash, code in a V8 isolate.
- 02OS sandboxA process fenced in by the host's kernel. bubblewrap and Seatbelt, as Claude Code and Codex use locally.
- 03ContainerA packaged filesystem and process tree on a shared kernel. Docker, Daytona, Cloudflare Containers.
- 04MicroVMA small virtual machine with its own kernel. Firecracker, as in Vercel Sandbox and E2B.For The strongest isolation that is practical per task.Against Boot time, and a cost per minute while it runs.
- 05BrowserAn isolated browser session, local or in a fleet. Browserbase, Kernel, Playwright.
Install scripts run arbitrary code. Give it its own kernel, deny egress by default, and keep secrets outside.
Keep the credential out of the box
Whatever the sandbox can read, a prompt injection can read too. So the major labs keep secrets outside it. Anthropic, OpenAI, Meta, Docker and Vercel all add credentials outside the sandbox, on the way out, and the inside holds a placeholder or nothing.
The first version of this platform's editor passed the real model key into the VM, and it was moved out the same day. Switch between the two placements and run the same injected commands.
The key lives where the model's commands run.
Illustrative output. The placeholder is the literal string the editor VM holds on this platform.
Decide what survives before something dies
The labs settled on one rule: the sandbox is disposable, the loop is stateless, and the record lives outside both. Anthropic keeps an append-only session log. Codex writes resumable rollout files. OpenCode's next version records every prompt in a SQLite event log before it runs.
The drill runs five failures against three designs. The third column is this platform, including the two places it still loses.
The loop, the tools and the only copy of the work go down together, and so does the record of what happened.
The sandbox was disposable. A new one boots, the state is still outside, and the loop carries on from the log.
A heartbeat keeps the VM alive while the session is open, and a stop is refused if the snapshot fails. If it dies anyway, the work since the last snapshot is gone: a turn is not event-sourced here.
The first two columns are illustrative. The third is how this platform behaves, including where it loses.
Decide in code what the agent may do and what counts as done
Permission prompts feel like control, but Anthropic measured its users approving 97% of them. When dangerous commands were planted, people caught 13.6% and a reviewer model caught 89%. What holds up is a set of tiers decided in code: what runs freely, what is watched, what asks a human, and what is refused.
The same logic covers money and truth. A budget the model can read is advice, and one the database enforces is a ceiling. A summary that says done is a claim, and an exit code with a diff is evidence.
Destructive. No setting turns this into auto-run.
Own the loop, wrap a harness, or rent one
You rarely build every part yourself. The real choice is which parts you own: the more of the loop and the state is yours, the more control you have and the more you maintain. These are the four common starting points.
For You own the context, the cache, the checkpoints and the stops.
Against You build the tools, the sandboxing and the compaction.
Pick it when The agent is your product, or it has to run inside your own billing and durability.
For A proven loop with tools, compaction, hooks and sandboxes built in.
Against Shaped around one lab's models, and still pre-1.0 with frequent releases.
Pick it when You use one model family and want that lab's loop.
For The strongest coding loop available, maintained by someone else.
Against Its output format becomes your contract: pin the version and test the format.
Pick it when The task is editing code and you own the control around it. This platform does this.
For The loop and its session run for you, and the sandbox can too.
Against Sessions and memory live with the vendor, and you have the least control.
Pick it when Speed to production matters more than portability.
What changes when the model gets better
The parts that face the model get thinner. In 2026 Claude Code replaced its dedicated search tools with search inside the shell, removed its todo-list tool on new models, and deleted most of its system prompt when Opus 5 arrived. OpenAI now tells teams that instructions written for older models over-constrain the new one.
The rest does not change. The key still has to stay out of the box, the work still has to survive the machine, and a crash still must not read as success. Write the model-facing part thin and expect to delete it. Build the control part like any system that holds money and keys.
The prompt: audit and improve your harness
Audit and improve this agent harness
Written for Claude Code and Codex, and composed from the parts on this page, so the prompt and the page cannot disagree. Point it at the repository your agent lives in and let it run: it maps the harness, audits every part with evidence, writes a plan ordered by consequence, builds the safe fixes in isolated worktrees, proves each control by breaking it, and reports in docs/HARNESS.md. It never commits, so you review once, on the diff.
- 0AHow to run thisAs an orchestrator, end to end, without asking. One subagent per part reads the code, every finding is refuted by an agent that did not make it, and fixes are built in isolated worktrees.
- 0BAbsolute constraintsNever commits. Reads no secret, calls no live provider, and changes no production config. A fix adds a control and never changes what the agent does for its users.
- 01Find the harnessThe loop, what the model sees, the tools, where actions run, the secrets, the state and the controls, mapped from the code rather than the README.
- 02Audit, part by partHeld, partial, missing or not applicable for every part, each resting on a file and line. What it cannot judge becomes a question, never a finding.
- AThe reference architectureEvery part on this page, composed from it: what it does, what good looks like, the options with their trade-offs, the checks, and the failure without it.
- 03PlanOrdered by consequence: secrets and destructive actions first, then spend, false success, cleanup, cost and traces. Anything that needs a dashboard or a decision becomes an owner action.
- 04BuildThe smallest version of each fix, one per worktree, with its own tests, merged one at a time with the checks green after each.
- 05Prove each control by breaking itA different agent breaks every control on purpose, watches a test fail, and restores the file byte-identical.
- 06The final reportWritten into docs/HARNESS.md: the map, the verdicts with evidence, what was built and proven, the owner actions, and every claim it could not verify.
The whole architecture travels with the prompt, so it is long. Paste this line instead and your agent fetches it itself; the copy and download buttons work too.
Read https://alicantorun.com/lab/harness-engineering.md in full and follow it exactly, against this repository. Do not summarise it, do not plan around it: execute it, starting with the map.Run it in a fresh session on your strongest model at high effort, with a long budget; it spawns its own subagents and worktrees. It does not stop to ask, so give it the whole run, then read docs/HARNESS.md and the diff before anything is committed.
Audit and improve this agent harness
You are working in a repository that contains an AI agent: a model called in a loop with tools. Your job is to measure the software around the model, the harness, against the reference architecture below, part by part; to write down what you find; to build the fixes that are safe to build, in order of consequence; to prove each one; and to report. You change the harness, never the product the agent serves.
How to run this
You run inside Claude Code, Codex or a harness like it, on your own, end to end: map, audit, plan, build, prove, report. You never ask the owner what to fix or in what order. Consequence decides the order, and where two choices are close you pick one and record why. Nothing is committed, so the diff is the owner's review and undo.
Work as an orchestrator:
- Do not read the whole repository yourself. One subagent per part of the architecture reads the code and returns findings in one shape. Your context is for the map, the plan and the report.
- Every finding is checked by an agent that did not make it. A finding that cannot cite the file and line it rests on is removed.
- Independent fixes happen in isolated worktrees, one builder per fix, each verified before it is merged, one at a time.
Absolute constraints
- Never commit, push, tag or open a pull request. Never rewrite history.
- Read no secret value. Check that a variable exists, never what it holds.
- Call no model provider, payment provider or other live third party. Tests use stubs or recorded fixtures.
- Change no production configuration, infrastructure or provider dashboard. Write those as owner actions in the plan.
- A fix adds a control. It does not change what the agent says or does for its users, the intent of its prompts, or its model.
- After every merged fix, the repository's typecheck, lint and tests are green, or the fix is reverted and recorded as blocked.
Phase 1: find the harness
Write the map at the top of docs/HARNESS.md. If the repository runs more than one agent,
map each one.
- The loop. Where it lives, which model and which SDK or framework, and what ends a run.
- What the model sees. The system prompt and instruction files, memory, history, and what happens when the window fills.
- The tools. Every tool, what it can reach, and which can delete, send, pay, publish or merge.
- Where actions run. The machine, container or sandbox, and what network it can reach.
- The secrets. Every credential the agent's code can read at runtime, and how it got there.
- The state. Where the record of a run lives, where the work lives, and who can write each.
- The controls. What approves what, what caps spend, what decides a run succeeded, what cleans up after a crash, and what is traced.
Read the code, not the README. Instruction files are claims to check, not truth.
Phase 2: audit, part by part
One subagent per part below. For each part, return a verdict (held, partial, missing, or not
applicable), the file and line it rests on, the failure it risks in this repository, and the
cheapest fix. A part that does not apply (an agent that runs no code needs no sandbox) is
marked not applicable with the reason, never failed. Anything you cannot judge from what you
read is unknown, and unknown becomes a question for the owner, never a finding. Write the
verdict table into docs/HARNESS.md.
The reference architecture
11 parts in 4 layers. The layers group the parts by how long they live.
Layer: Brain
The loop and what the model sees. Stateless: it should be able to restart anywhere.
1. The loop
Calls the model, runs the tool calls it asks for, feeds the results back, and repeats until the model answers without a tool call or a limit stops it.
What good looks like:
- Small and owned: a few hundred lines you can read.
- Hard stops in code: steps, time and spend.
- Steering between steps, and a stop the loop handles itself.
- Retries with backoff for provider errors, and a clear end state for everything else.
The options, with their trade-offs:
- Your own loop on a model SDK. Pros: Every step is visible, checkpointable and cache-friendly. Cons: You write streaming, retries and cancellation yourself.
- An agent framework's loop. Pros: Tools, streaming and approvals work on day one. Cons: Harder to checkpoint mid-loop, and the abstraction leaks around caching.
- A coding harness run as a component. Pros: A mature loop with tools and compaction, maintained by someone else. Cons: Its output format becomes your contract, and its session lives on its machine.
Check:
- Where does the loop live, and who owns its code?
- What stops it: a step limit, a timeout and a spend limit, each enforced in code?
- Can a user stop a running turn without relying on the model to obey?
The failure without it: A loop without a hard stop keeps spending until someone notices.
2. Context
Decides what the model sees on every step: instructions, memory, recent history and tool results.
What good looks like:
- A stable prefix: instructions first and unchanging, so the prompt cache hits.
- History appended, never edited. A change of settings is a new message.
- Instructions as a short map to deeper docs, not a manual.
- Large tool output written to a file, with a path in context.
- Untrusted content marked as data, not instructions.
The options, with their trade-offs:
- Auto-compaction. Pros: Long sessions keep going without intervention. Cons: Lossy: a summary can drop the instruction that mattered.
- Handoff to a fresh context. Pros: A clean window, with the state written down on purpose. Cons: The harness has to write the plan and progress files.
- A memory window rebuilt per turn. Pros: It survives the machine, and you choose exactly what the model sees. Cons: The window is bounded, so older detail has to live elsewhere.
Check:
- Is the start of the prompt stable across steps, or does something early in it change every turn?
- What happens when the window fills, and could that drop a safety instruction?
- Is content from outside (a web page, an email, a user's file) marked as data rather than instructions?
The failure without it: Recall degrades as the context grows, and a cache miss on a long prefix multiplies the cost of every step.
Layer: Hands
What the agent can do and where it runs. Disposable, isolated, and paid for by the minute.
3. Tools
The actions the model can ask for, and the contract for each: its name, its input, and what comes back.
What good looks like:
- A few general tools the model was trained on: a shell, read, edit.
- Output capped, keeping the head and the tail.
- Destructive tools marked, so control can treat them differently.
- Large integrations loaded on demand, not all at once.
The options, with their trade-offs:
- A few general tools. Pros: Models are trained on them, and the prompt stays small. Cons: Harder to gate precisely: a shell can do almost anything.
- Many specific tools. Pros: Each one is typed and can be approved on its own. Cons: Their definitions crowd the context and confuse the model.
- Tools behind code or search. Pros: Hundreds of tools cost almost nothing until one is used. Cons: The code needs a sandbox, and a trace is harder to read.
Check:
- How many tokens do the tool definitions cost before the first message?
- Which tools can delete, send, pay, publish or merge, and are they marked as such?
- Are tool outputs capped, and does a truncated output say that it was truncated?
The failure without it: Tool definitions eat the context before work starts, and one uncapped output can fill the window.
4. Sandbox
Where model-written commands and code actually run.
What good looks like:
- Disposable: losing it must not lose the run.
- Isolated at the level the threat needs.
- Egress denied by default, with a short list of allowed hosts.
- A time limit, and a handle to find it and stop it later.
The options, with their trade-offs:
- An OS sandbox on the host. Pros: Fast and free, and right for a developer's own machine. Cons: It shares the kernel, so the isolation is weaker.
- A container. Pros: Familiar and reproducible. Cons: A shared kernel is a thin wall for code you did not write.
- A microVM. Pros: Its own kernel: the strongest isolation that is practical per task. Cons: Boot time, and a cost per minute.
Check:
- What is the most damaging thing a prompt injection could make this sandbox do?
- Can it reach any host on the internet, or only the ones it needs?
- If it dies, what is lost, and what finds it if the request that started it dies first?
The failure without it: Model-written code runs next to secrets, customer data or the only copy of the work.
Layer: State
What survives: the record of the run, the work, the memory. It outlives the brain and the hands.
5. State and memory
Keeps what must survive when the loop or the sandbox dies: the record of the run, the work, and the memory.
What good looks like:
- The record lives outside the loop and the sandbox.
- One writer per session.
- The work kept in a system with history, usually git.
- Memory consolidated into a new copy, never edited in place.
The options, with their trade-offs:
- In memory. Pros: The simplest thing that works. Cons: Any crash or deploy loses the run.
- An append-only event log. Pros: Resume, audit and replay from one record. Cons: You design the events, and replay has limits.
- Database rows plus git. Pros: Queryable and diffable, and usually already there. Cons: A turn in flight is recovered, not replayed.
- A mounted drive of files. Pros: Memory and skills as files anyone can read. Cons: One writer at a time, and tied to one region.
Check:
- Kill the process mid-turn: what is lost, and how does the next turn know?
- Can two runs write the same session or workspace at once?
- Where is the only copy of the agent's work at the moment the sandbox stops?
The failure without it: A crash loses the run and its record, so nobody can say what happened.
Layer: Control
What is allowed and what is true. Outside the agent's reach, and unchanged by the next model.
6. Credentials
Authorises the agent's requests without the agent ever holding the secret.
What good looks like:
- No real secret inside the sandbox: a placeholder or nothing.
- The credential added at the egress proxy, for one host and one path.
- Keys scoped to one task or project, capped in spend, and easy to rotate.
- Short-lived tokens where the provider allows them.
The options, with their trade-offs:
- An environment variable in the sandbox. Pros: Simple. Cons: Any injected command can print it and send it away.
- Brokered at the egress proxy. Pros: The box holds a placeholder, and the proxy adds the real header. Cons: It needs a proxy you control, and not every protocol passes through one.
- Short-lived scoped tokens. Pros: A leaked token expires and reaches one thing. Cons: Another service to run, and not every provider supports it.
Check:
- List every secret the agent's code can read at runtime. Which of them could an injected command print?
- Is each key scoped to the least it needs, and capped in spend?
- What would you rotate first if the sandbox were compromised?
The failure without it: One injected echo sends your API key to a stranger.
7. Approvals
Decides in code which actions run freely, which are watched, which ask a human, and which are refused.
What good looks like:
- Tiers set by what an action can break, not by how it is phrased.
- Irreversible actions ask, every time.
- An approval recorded as a scoped permission, not a chat reply.
- A stop the loop handles itself.
The options, with their trade-offs:
- A prompt before each action. Pros: A human sees everything. Cons: People approve almost everything: Anthropic measured 97%.
- A reviewer model. Pros: Catches most dangerous actions without a click. Cons: It still misses some, so it is a layer, not a boundary.
- A sealed box and no prompts. Pros: No friction. Cons: Only safe when the box holds nothing worth taking.
Check:
- Which actions can delete, send, pay, publish or merge, and what stands between the model and each one?
- Is any rule that must never break written only as an instruction to the model?
- Can a user stop a running turn without the model's cooperation?
The failure without it: An instruction to confirm first gets summarised away, and the agent acts anyway.
8. Budgets
Caps what a run may spend, enforced where the model cannot reach.
What good looks like:
- Reserved before the run starts, not checked after it.
- Each turn settled at its actual cost, failed turns included.
- Concurrency capped in the database, not in the prompt.
- A separate, smaller key for the sandbox than for the product.
The options, with their trade-offs:
- A step limit in the loop. Pros: One line of code. Cons: It caps steps, not money, and only for one run.
- A reservation in the database. Pros: A hard ceiling across turns and sessions. Cons: You keep the accounting honest yourself.
- A budget at the model gateway. Pros: Nothing to build. Cons: Often a soft cap, reported after the spend.
Check:
- What is the most one run can spend, and where is that number enforced?
- Can two sessions for the same customer run at once?
- Is cost settled from actual usage, including runs that failed?
The failure without it: A long session keeps spending after the wallet reaches zero.
9. Verdict
Decides whether a turn worked, from evidence rather than from the model's summary.
What good looks like:
- Success read from the exit code and the diff.
- Four outcomes, not two: ok, failed, aborted, unknown. Only ok passes.
- A check the agent can run on its own work: tests, a typecheck, a screenshot.
- A separate checker where judgment is needed.
The options, with their trade-offs:
- Trust the summary. Pros: Free. Cons: The model says done, sometimes when it is not.
- Exit code, diff and checks. Pros: Cheap, deterministic, and hard to fool. Cons: Only as good as the checks that exist.
- A separate evaluator agent. Pros: Catches problems a test cannot see. Cons: Another model run, and it needs tuning to be sceptical.
Check:
- How does the harness decide a run succeeded? Could a crash or a silent process read as success?
- Does the agent have a check it can run on its own work?
- Is 'not checked' ever displayed as 'passed'?
The failure without it: A crashed run shows green, and the customer is billed for it.
10. Lifecycle
Cleans up what a dead request leaves behind, and makes retries safe.
What good looks like:
- Every unfinished state has a reaper that does not depend on the request that started it.
- Every side-effecting step carries an idempotency key.
- Every external resource the agent creates has a teardown.
The options, with their trade-offs:
- Clean up in a finally block. Pros: Simple, and right most of the time. Cons: A killed process never runs it.
- A scheduled reaper. Pros: Finds what died, whatever killed it. Cons: It needs an idle window, so cleanup arrives late.
- A durable workflow engine. Pros: Steps resume after a crash or a deploy. Cons: Determinism rules, and a retried step still needs an idempotency key.
Check:
- What happens to an open session, a running sandbox and a reserved budget if the request is killed?
- If a step is retried, can it charge, send or publish twice?
- Does deleting a customer tear down every external resource the agent created for them?
The failure without it: A killed request leaves a sandbox running and a budget held, with nothing to release them.
11. Traces and evals
Shows what the agent did, and measures whether a change to the harness helped.
What good looks like:
- Every model call and tool call traced, with its cost.
- Transcripts kept and read, the failures first.
- Harness changes tested on a fixed model, with several runs per task.
- An eval set built from real failures.
The options, with their trade-offs:
- A tracing product. Pros: Dashboards and evals without building them. Cons: Another vendor holds your transcripts.
- Your own event log. Pros: The audit trail and the eval input are one record. Cons: You build the views.
- Judging by feel. Pros: Fast. Cons: You cannot tell a better harness from a lucky run.
Check:
- Can you reconstruct any past run, step by step?
- The last time the prompt or a tool changed, how did you know it helped?
- Are failures read, or only counted?
The failure without it: A prompt change makes the agent worse, and nothing notices.
Phase 3: plan
Write the plan into docs/HARNESS.md, ordered by consequence:
- Secrets the agent's code can read, and actions that delete, send, pay, publish or merge without a control.
- Spend without a ceiling the model cannot reach.
- Runs that can read as success when they failed, and state that a crash loses.
- Unfinished states with no cleanup, and side effects a retry can repeat.
- Context and tool cost.
- Traces and evals.
Each item names the part, the change, the failure it prevents, and how you will prove it. An item that needs a provider dashboard, a new service, a paid plan or a product decision goes under Owner actions, with the exact steps, and is not built.
Phase 4: build
Smallest version first, one item per unit, each in its own worktree with its own tests. Typical fixes, roughly in this order: a hard stop in code; a secret moved out of the sandbox's reach, or where that needs infrastructure, the key scoped and capped and the rest recorded as an owner action; an approval tier for a destructive tool; an idempotency key on a side effect; a verdict that reads the exit code and treats silence as unknown; a reaper for an unfinished state; a cap on tool output; a trace on a path that had none. Do not refactor what is not on the plan. Write what you see on the way under "seen, not touched".
Phase 5: prove each control by breaking it
For every control you added, and every one you found and rely on, a different agent breaks it on purpose and watches a test fail: remove the step limit, read the credential from inside the sandbox, retry the side effect, report a crashed run as done, kill the request mid-run. Then it restores the file byte-identical and hands back the proof. A control that has never failed is decoration.
Final report
Append to docs/HARNESS.md: the map; the verdict table with each part's evidence; what was
built and the proof for each; the owner actions; everything seen and not touched; every step
left blocked; and every claim you could not verify. Never commit for the owner.
The architecture this prompt is composed from, with the reasoning behind each part: https://alicantorun.com/lab/harness-engineering
- I think "agent" may finally have a widely enough agreed upon definitionSimon Willison · 2025-09-18
- Terminal-Bench 2.1, the same model across harnessesTerminal-Bench · 2026-05-06
- mini-swe-agentSWE-agent · 2026
- A source-code study of eleven production coding harnessesarXiv 2609.00006 · 2026
- What a task costs on Opus 5.5Anthropic · 2026-09-22
- Effective harnesses for long-running agentsAnthropic · 2025-11-26
- Scaling Managed Agents: decoupling the brain from the handsAnthropic · 2026-04-08
- Unrolling the Codex agent loopOpenAI · 2026-01-23
- OpenCode v2Anomaly · 2026
- Beyond permission prompts: Claude Code sandboxingAnthropic · 2025-10-20
- From model to agent: equipping the Responses API with a computer environmentOpenAI · 2026-03-11
- How We Built Safety Into MuseMeta · 2026-09-08
- Why microVMs: the architecture behind Docker SandboxesDocker · 2026-04-16
- Sandbox firewall and credential brokeringVercel · 2026
- just-bashVercel Labs · 2026
- How we built Claude Code auto modeAnthropic · 2026-03-25
- Auto mode is now the default in Claude CodeAnthropic · 2026-08-07
- Claude Code changelogAnthropic · 2026
- Boris Cherny at YC Startup SchoolY Combinator · 2026-07-27
- Rethinking skills and prompts for GPT-6 AstraOpenAI · 2026-09-11