Skip to Content
ExtrasBatching background completions inline

Batching background completions inline

GitHub measured 2.3% saved by delivering background results inside already-happening requests instead of dedicated polling turns. FreeCode gets this for free today — this page records why, and the rule that keeps it that way.

The problem, in plain words

Imagine the agent kicks off two long-running commands in the background, then later asks “is task 1 done?” (one model call), gets the result (another), asks “is task 2 done?” (a third), gets that result (a fourth). Four model calls to collect two results — and remember, every call re-sends the entire conversation. That polling pattern is pure waste: the results should ride along inside model calls that were going to happen anyway.

GitHub fixed this in Copilot by attaching finished background completions to the next already-scheduled request. Their saving: 2.3% of total cost.

Why FreeCode doesn’t have this problem (yet)

By construction. FreeCode has no background bash and no async subagents — when the model emits several independent tool calls in one response, the batching layer (apps/core/src/tools/batching.ts + tools/orchestrator.ts) runs them concurrently and returns all their results in the same single follow-up model call. There is no “check status later” turn to eliminate, because nothing runs detached from the loop.

So the implementation here isn’t code — it’s the absence of the anti-pattern, plus the existing batching layer already proving the right shape: many results, one request.

How I implemented it (as a recorded invariant)

The risk isn’t today; it’s the roadmap. FreeCode’s autonomous/ subsystem (Phase 0: types, budgets, storage) will eventually grow detached execution, and async subagents are a natural future feature. The day either lands, the polling anti-pattern becomes possible.

So the spec (2026-09-04-harness-cost-efficiency.md, D5) records this as a hard constraint on all future work:

A background completion is delivered as an ordinary tool-result in the next already-happening model call — never via a dedicated retrieval turn.

Four calls to process two results is the named anti-pattern. Any future background-execution design gets reviewed against this line before it builds.

Performance improvements

MetricValue
Dedicated polling turns today0 — impossible by construction
Cost of enforcing the invariant0 tokens, 0 code — it’s a design rule
Measured savingn/a until background execution exists; GitHub’s 2.3% is the reference point

The cheapest technique of the four: it costs nothing because it was adopted before the feature that would violate it.

Last updated on