Code ModeLive
What it looks like when the agent writes the loop.
Every run below actually happened. The programs were submitted to a real MCP server — GitHub's REST API, ingested through MCPCloud and deployed with a token scoped to a handful of throwaway repositories — and the figures were read off those executions, not modelled. Where an answer is trimmed for length, it says so.
What is open across all our repos, who wrote it, and is CI green?
Four repositories, every open pull request, and the check status for each — assembled in the sandbox and returned as one table.
What the agent submitted
const repos = await tool("reposListForOrg", { org: "MCPCloud-Demos" })
const open = []
for (const repo of repos) {
const prs = await tool("pullsList", {
owner: "MCPCloud-Demos", repo: repo.name, state: "open",
})
for (const pr of prs) {
const checks = await tool("checksListForRef", {
owner: "MCPCloud-Demos", repo: repo.name, ref: pr.head.sha,
})
const runs = checks.check_runs || []
open.push({
repo: repo.name,
pr: pr.number,
title: pr.title,
author: pr.user.login,
ci: runs.length
? runs.every((c) => c.conclusion === "success") ? "green" : "not green"
: "no checks",
})
}
}
return open
What came back to the model2 of 8 entries shown.
[
{
"repo": "demo-marketing-site",
"pr": 9,
"title": "feat: docs og:image",
"author": "AbyssinianGuy",
"ci": "no checks"
},
{
"repo": "demo-billing-svc",
"pr": 8,
"title": "fix: rounding on multi-currency invoices",
"author": "AbyssinianGuy",
"ci": "no checks"
}
]
149×
less into context — 306 tokens, not 45,634
17 → 1
model turns, for identical work
16
tool calls, each individually authorized
The loop is nested — repos, then pull requests, then checks — and the number of calls is not known until the first one returns. That is the shape a model cannot plan in advance, and the shape a program handles without thinking about it.
Which open PRs have failing CI, and who wrote them?
The same traversal, filtered to failures. The answer came back empty — nothing was failing — and that is still the useful result.
What the agent submitted
const repos = await tool("reposListForOrg", { org: "MCPCloud-Demos" })
const failing = []
for (const repo of repos) {
const prs = await tool("pullsList", {
owner: "MCPCloud-Demos", repo: repo.name, state: "open",
})
for (const pr of prs) {
const checks = await tool("checksListForRef", {
owner: "MCPCloud-Demos", repo: repo.name, ref: pr.head.sha,
})
const bad = (checks.check_runs || []).filter((c) => c.conclusion === "failure")
if (bad.length) {
failing.push({
repo: repo.name, pr: pr.number, author: pr.user.login,
failed: bad.map((c) => c.name),
})
}
}
}
return failing
What came back to the model
[]
45,328×
less into context — 1 token, not 45,328
17 → 1
model turns, for identical work
16
tool calls, each individually authorized
An empty answer is where the difference is starkest. Sixteen calls of evidence were needed to establish that nothing is broken, and none of it had to enter the model to prove it.
And when the program is wrong?
A real mistake, and the whole of what came back. The program assumed the first repository had an open pull request; it did not.
What the agent submitted
const repos = await tool("reposListForOrg", { org: "MCPCloud-Demos" })
const prs = await tool("pullsList", {
owner: "MCPCloud-Demos", repo: repos[0].name, state: "open",
})
const checks = await tool("checksListForRef", {
owner: "MCPCloud-Demos", repo: repos[0].name, ref: prs[0].head.sha,
})
return checks.filter((c) => c.conclusion === "failure")
The failure digest the agent received
ExecutionError: runtime_error
TypeError: cannot read property 'head' of undefined
tool calls (2):
reposListForOrg({"org":"MCPCloud-Demos"}) 467ms → {id: number, node_id: string, name: string, full_name: string, private: boolean, owner: {login: string, id: number, …+7 more}, html_url: string, description: string, fork: boolean, url: string, …+71 more}[7]
pullsList({"owner":"MCPCloud-Demos","repo":"tally","state":"open"}) 222ms → unknown[0]
shape: 7/7 items have homepage === null
at: at <anonymous> (code:8:56)
7 | const checks = await tool("checksListForRef", {
> 8 | owner: "MCPCloud-Demos", repo: repos[0].name, ref: prs[0].head.sha,
9 | })
43×
less into context — 233 tokens of digest, not 10,129 of payload
3 → 1
model turns spent discovering the bug
2
tool calls ran before it broke — both recorded
Everything needed to fix this is in the digest, and none of it is the raw data. The failing line is shown with its neighbours; both calls are listed with their arguments and the SHAPE of what they returned — and `unknown[0]` on the second is the answer, an empty array, which is exactly why `prs[0]` was undefined. A stack trace would have said "cannot read property of undefined" and left the agent to guess which of its assumptions broke.
Why the failure looks like that
A program that breaks is not an edge case; it is most of what happens while an agent is working out how your API behaves. So the failure gets the same care as the answer: the class of error, the failing line with its neighbours, and every call that ran with its arguments and the SHAPE of what it returned — never the raw payload, which is the thing the sandbox exists to keep out of context.
Shapes are what make it fixable. In the run above, the second call reporting unknown[0] is the entire diagnosis — an empty array, which is exactly why indexing into it produced undefined. A stack trace would have reported the TypeError and left the agent to guess which assumption broke, and guessing usually means rewriting code that was already correct.
What did not change
The tool-call count is identical in both columns of every run above, and that is the point rather than a coincidence. A call made from inside the sandbox is dispatched as an ordinary tool call, through the same path a direct request takes — the same per-tool permissions, the same rate limits, the same upstream key injection, the same audit record, the same metering. Nothing is batched behind your back and nothing skips the policy layer.
What changes is where the intermediate data goes. It stays in the sandbox, and only the value the program returns crosses back into the model's context.
How these were measured
Each figure was captured from a single execution on 2026-08-04. Tool calls, wall clock and byte counts are measured. The direct-call column is derived, not executed: a direct caller spends one model turn per tool call plus the turn that answers, and it carries every intermediate payload into context on the way. Running that side for real would need a model in the loop, and reporting an estimate as a measurement is the one thing these numbers are not for.
Token counts are approximate, converted from measured bytes. Your own numbers depend entirely on how large your tool responses are — the bigger the payloads a task has to walk through, the further apart the two columns move.