A Coding Agent Has to Fit the Work, Not Just the GPU

A 6 GB GPU can run a coding agent, but around 5 GB is the realistic planning figure. The model still has to share memory with context and scratch space.

Fitting the model is only the start.

A Small Model Still Has to Repair Its Mistakes

A machine with 16 GB of RAM and a 6 GB graphics card can run LM Studio, VS Code, and Continue. Neo Horse 4B at 5-bit takes just over 3 GB, while Sparkx 2.5 at 4-bit takes 2.6 GB. Both are practical starting points.

Larger options leave less room. Neoorse 9B at 4-bit uses 5.6 GB, which pushes some layers into slower system RAM. Bonsai 2 has a 5.95 GB file, but it was not established whether the entire model could stay on the graphics card.

Then context starts consuming memory. The cache holds the code and earlier model responses. At 8,000 tokens, it is roughly twice the size it is at 4,000 tokens.

So loading successfully is not the useful test. The models were asked to fix a broken API, add a feature across multiple files, and repair their own mistakes after receiving a new failing test.

That final job matters most. A plausible patch is not enough. The agent must read the failure, change its theory, and try again.

Compression, Offloading, and Runtime Support Change the Answer

Quantization stores model weights with fewer bits, which saves memory. The hardware guide calls 4-to-5-bit the safe zone, with quality falling sharply below about 3 bits.

Qwen 3.8 produced a promising exception. A special 27B build used under 12 GB by keeping sensitive layers at higher precision and compressing less important layers more aggressively. It exactly matched the full-precision model on some coding and math benchmarks.

A 3-bit build also matched the full model on one math test and one coding test. That evidence is encouraging, but narrow. It does not prove aggressive compression is free across other work.

Mixture-of-experts models have a different constraint. Ornets 35B activates about 3 billion parameters for each token, which can improve speed, but memory still has to hold all 35 billion parameters.

Offloading moves the bottleneck instead of removing it. Weights can spill from GPU memory into system RAM, but performance then depends on the connection between them. The same issue appears across multiple cards: the 96 GB RTX Pro 6000 edged ahead of the 94 GB H100 NVL in some single-card benchmarks, while the H100 NVL moved ahead across several cards because of its faster chip-to-chip connection.

DeepSeek v4.1 flash, released September 10, takes this further. It has 552 billion parameters, and the DwarfStar Mac engine keeps a large lookup structure on SSD while frequently used core weights stay in fast memory. That lets a compressed version run on a single 128 GB Mac.

GLM 5.3 flash shows why hardware capacity still does not settle the question. Its available versions range from about 120 GB to 240 GB, but the architecture requires a specific Unsloth branch or desktop app because support had not reached the main open source runtime.

A model can fit the hardware and still be blocked by the software around it.

Cheap Tokens Can Preserve an Expensive Process

Enterprise agent cost depends on more than model pricing. An agent might inspect an account, search its history, check products, call tools, and prepare a response. Every step can add model calls and tokens.

A Dreamforce speaker said frontier models can charge $50 per million output tokens. A cheaper model may reduce that cost, but first ask whether every step needs to happen at all.

The material compares these workflows to an interoffice envelope that became an email and then a ticket. The medium changed, but people continued summarizing and reformatting the same request for the next team. An agent can automate those handoffs while preserving the waste.

For a quote, the required outcome is an authorized price, a recorded quote, and a question about anything unresolved. Known pricing rules can go to a pricing tool, settled steps can go to the CRM, and a model can identify the product, find missing information, and explain the tool’s answer.

Standard requests can go to an open weights model. Unusual cases can go to a more capable model. A smaller model may need a structured harness with instructions, tools, checks, and a defined route, while a frontier model may need less structure for messy exceptions.

As the speaker put it:

“We need to start asking which model can do this job well.”

Evaluation then has to inspect the outcome. Was the price correct? Was approval recorded? Did the record actually change?

A confident answer is not a completed process.

Verification Is What Makes an Agent Operational

Specifications, browser tests, sandboxes, CI, linters, and simulators can make verification difficult to skip. One Cursor engineer reported scaling to around 1000 PRs/month by strengthening automated verification instead of rereading every line.

The trust failures are concrete. One Codex CLI user reported teaching the tool a repository for two nights, then receiving a wrong migration delivered with high certainty during a client walkthrough.

Another report described a Sentry Seer handoff risk. Fabricated errors could become prompts sent into Claude, Cursor Cloud, or Copilot Autofix through a package installation path.

The failures differ, but the practical response is the same: verify the migration, package path, test result, and state change. Then keep testing the questions that remain open. Can small local models repair their own mistakes? Can independent testing reproduce the Qwen 3.8 results? Can verification stop fabricated errors from becoming real changes?