Measure mcp stdio cold-start per invocation, then decide the keep-alive daemon #338

New issue

Closed

opened 2026-08-30 03:44:00 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-30 03:44:00 +00:00

Owner

Deferred out of #336 deliberately, filed so the decision is not waiting on a conversation nobody can read later.

What was built instead

The mcp dialect opens a session per invocation and closes it (opcore.executeMCP). A CLI process runs exactly one leaf, and a kept-alive stdio child would outlive the call that wanted it, so per-invocation is correct and simplest for phase 1.

The cost is a cold start on every call. That number is unmeasured. mcporter carries a keep-alive daemon precisely because stdio servers are slow to start and hold session state, so the question is real rather than hypothetical.

Why this is a measurement and not a design task

#336 scoped the daemon out on the explicit condition that the latency be measured first. Building a process manager inside a policy engine on an assumption is how a gate becomes a service. The measurement decides whether that cost is worth paying.

Do

Time specgen run against an mcp member over a stdio upstream, cold, n>=10, and record the distribution rather than a single number. A real server (npx-launched) rather than a Go fixture, since npm start-up is the suspected cost.
Do the same over the http transport as the control, which has no spawn.
Record both numbers in this issue.

Then decide, with the numbers stated

Under roughly 200ms, close this: per-invocation stays and no daemon is warranted.
Materially worse, open a design issue for session reuse and say in it what the numbers were.

A daemon is not the only answer if the number is bad. Reusing one session across the leaves of a single invocation, or a short-lived socket, are both smaller than a supervised background process.

Not this issue

The http transport has no spawn and no cold start worth measuring beyond the control above.

Deferred out of #336 deliberately, filed so the decision is not waiting on a conversation nobody can read later. ## What was built instead The mcp dialect opens a session per invocation and closes it (`opcore.executeMCP`). A CLI process runs exactly one leaf, and a kept-alive stdio child would outlive the call that wanted it, so per-invocation is correct and simplest for phase 1. The cost is a cold start on every call. **That number is unmeasured.** mcporter carries a keep-alive daemon precisely because stdio servers are slow to start and hold session state, so the question is real rather than hypothetical. ## Why this is a measurement and not a design task #336 scoped the daemon out on the explicit condition that the latency be measured first. Building a process manager inside a policy engine on an assumption is how a gate becomes a service. The measurement decides whether that cost is worth paying. ## Do 1. Time `specgen run` against an mcp member over a stdio upstream, cold, n>=10, and record the distribution rather than a single number. A real server (`npx`-launched) rather than a Go fixture, since npm start-up is the suspected cost. 2. Do the same over the http transport as the control, which has no spawn. 3. Record both numbers in this issue. ## Then decide, with the numbers stated * Under roughly 200ms, close this: per-invocation stays and no daemon is warranted. * Materially worse, open a design issue for session reuse and say in it what the numbers were. A daemon is not the only answer if the number is bad. Reusing one session across the leaves of a single invocation, or a short-lived socket, are both smaller than a supervised background process. ## Not this issue The http transport has no spawn and no cold start worth measuring beyond the control above.

coilyco-ops referenced this issue

2026-08-30 03:44:57 +00:00

upgrade specgen into a mcporter replacement #336

coilyco-ops referenced this issue from a commit

2026-08-30 05:25:39 +00:00

perf(mcpclient): bound the stdio close wait, cutting 5.2s off every call

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-30 05:25:54 +00:00

Bound the stdio close wait, cutting 5.2s off every call #344

coilyco-ops referenced this issue

2026-08-30 05:26:14 +00:00

specgen build reuses a cached binary when a --umbra-replace checkout changes, so a dev iterating on umbra gets stale output silently #345