Your coding agent needs to know how much computer it actually has

01

WHAT ACTUALLY CHANGED

Researcher Manu Agrawal tested a straightforward idea: tell a coding model where its program will run before asking it to write the program. The paper calls the missing information substrate blindness, meaning the agent understands the requested outcome but cannot see the physical and operational limits that determine whether its plan is suitable.

The experiment asked Claude Opus 5, GPT-5.6-Sol, and Gemini 3.7 Flash to generate Python code for a high-dimensional pairwise-distance calculation. One group received only the task. The other received the same task plus a contract specifying 128 MB of RAM and a 10-second wall-time limit. The models received no algorithm recipe and no opportunity to repair their work after execution feedback.

Disclosing the contract lowered measured peak memory in 13 of 14 executable index-aligned comparisons and lowered average runtime for all three model groups. Some implementations ran as much as 3.1 times faster. The code changed structurally, using approaches such as bounded blocks, lower-precision data, upper-triangle traversal, memory mapping, and reuse of temporary buffers.

A second test tightened the memory contract to 96 MB. Correct programs that stayed within budget rose from zero of five to four of five for Claude, from one of five to five of five for GPT, and from zero of five to three of five for Gemini. Across those samples, average peak memory fell by 49 to 74 percent and runtime fell by 35 to 64 percent relative to the task-only references.

The accompanying Apache-2.0 repository preserves the generated code, row-level results, benchmark scripts, hashes, figures, and verification tooling. It also keeps inconvenient results in view. One GPT comparison used more memory after disclosure, and three of five Gemini outputs still exceeded the observed 128 MB boundary.

02

WHY THIS MATTERS

Coding agents are commonly given a logical problem and introduced to the real machine later. That is backwards. A technically correct program can still fail because it allocates too much memory, assumes the wrong runtime, exceeds an API quota, takes too long, or chooses tools that do not exist in production.

The interesting result is not that agents can optimize code. It is that a tiny addition to the planning state changed the kind of code they wrote before anything ran. The models did not need a person to prescribe chunking or memory mapping. They needed the constraints that made those choices relevant.

This suggests a practical design rule for agent systems. Treat execution context as part of the assignment, alongside the goal and the available tools. RAM, deadline, operating system, accelerator, budget, service reliability, and permission boundaries can all determine which otherwise reasonable plan survives contact with Tuesday afternoon.

The principle reaches beyond programming. A travel agent needs a spending ceiling and mobility requirements. A research agent needs database access and a deadline. A publishing agent needs image dimensions and a deployment target. Intelligence without context is perfectly capable of designing a beautiful bridge for the wrong river.

03

WHERE IT COULD HELP

• Give coding agents explicit RAM and runtime budgets
• Choose algorithms that fit edge devices and local computers
• Reduce cloud cost by exposing compute and quota limits before planning
• Include operating-system and tool availability in agent assignments
• Test generated programs against declared resource contracts