GLM-5.3’s Exploits, AI Models and Hardware Speed Up, DeepSeek’s New Agent Harness

The Batch News & Insights: How have software engineering fundamentals changed with agentic coding?

Share
Cartoon sand pails with arms; one orange trapped, one green wielding shovel; helping each other escape the sandbox; industrial backdrop.

Dear friends, 

How have software engineering fundamentals changed with agentic coding? Even when you use a coding agent to write all your code, understanding software fundamentals is important for steering your agent to make the tradeoffs you want — or to even know what tradeoffs exist to be made. Additionally, when you’re building an AI application, the AI core is often expressed through a broader software application, which a skilled engineer will shape.

A novice who vibe codes without understanding software fundamentals can create simple applications, but this often leads to the coding agent making bad tradeoffs in latency, availability, consistency, reliability, maintainability, simplicity, and/or cost. In most cases, the developer didn’t know such tradeoffs even existed and therefore did not steer the agent to make the right decisions for their application context.

This letter describes what our study of AI Engineering Skills shows are the most important things to know in software engineering. It requires being skilled at:

  • Building full-stack applications
  • Managing data
  • Designing system architectures
  • Making systems secure and reliable
  • Scaling and operating in production

Building full-stack applications. Agentic coding enables many developers who previously played more specialized roles (like front-end developer or mobile developer) to play a broader, full-stack role. A coding agent can help with parts of the development process that you might be less familiar with. However, understanding how the full stack actually works is important. Skilled developers understand the key components and concepts of front-end and back-end systems, including UI components, caching, page rendering, API choice and design, authentication, state and session management, asynchronous processing, data persistence, testing, security, and accessibility.

Managing data. Data deserves special attention because it is a foundation that software is built on top of, that is relatively hard to change (even if agents help with migrations). When you know how to manage data, you can think through access patterns and use them to decide what to store and for how long. You can identify the right data models and select the appropriate storage types (such as relational tables, documents, key-value, or graphs) and infrastructure, which in turn affects speed, scalability, availability, reliability, and cost. You understand transactions, concurrency, and how to ensure your data is clean, consistent, and fresh. When needed, you can ensure proper privacy, governance, and compliance. You know how to manage the data lifecycle.

As an application evolves, you also know how to evolve the data architecture with it. Deciding how to manage data requires significant human-provided context. Your AI systems will get their own input context from your data source, so if data architecture is chosen poorly, the AI doesn’t know what it doesn’t know. This is why it takes skilled intervention from someone with the relevant context and skilled at AI engineering — you! — to set it right. How to build data infrastructure for agents — rather than only traditional software or humans — is also a rapidly evolving area, and you should continue to adjust your best practices as the field evolves. 

Software engineering fundamentals as part of the AI Engineering Skills Map: Building full-stack applications, Managing data, Designing system architectures, Making systems secure and reliable, and Scaling and operating in production

Designing system architectures. When you understand the major components of the full stack of software and data, you are then better positioned to decide how to put the pieces together. Good system design requires understanding what the software is intended to do (how many users? how important is latency? how important is cost? etc.) so you can make choices about the application platform, the boundary between the frontend and backend, system decomposition, application state placement, and architectural granularity (monolith vs. microservices). You will also choose the stack (programming languages, runtimes, component/frontend/backend frameworks, data technologies) — sometimes by running experiments to evaluate options before settling on one. 

Further, the right architecture is a moving target, depending on the phase of the project. The simple architecture you choose to build a quick prototype may not be the right architecture to build the first production system, and that too may change as the application scales. Making these decisions requires deep technical knowledge of both software components and the application context so you can design — and evolve — the architecture to make better tradeoffs.

Making systems secure and reliable. To build reliable systems, you should know how to develop testing strategies to verify the correctness of your system: What mix of unit tests and integration tests, what frameworks to use, and what level of coverage. You also know how to design around possible failures — how to handle failures (like an API hitting a rate limit), build in graceful degradation, and minimize the blast radius of failures. Additionally, rather than first writing software and then later figuring out how to secure it, the “shift left” movement is moving security work earlier in the lifecycle (to the left on a traditional project timeline). Just as all developers are moving toward becoming full stack developers, many developers are now also partly security engineers. You can now use AI tools to scan your code for vulnerabilities, check dependencies for supply chain injections, and examine your cloud configuration for attack surfaces. But doing this well still requires some knowledge of security.

Scaling and operating in production. To serve real users, you will have to know how to deploy your software to production.You will benefit from knowing how to execute the software development lifecycle (SDLC) which, in addition to building and testing, includes configuring the deployment environment, deciding on release strategy, applying deployment automation (CI/CD), and understanding infrastructure as a service (IaaS). 

Operating in production requires putting in place observability tools, setting alerts, and managing incidents. Lastly, to scale your application, you should understand the real load and know how to scale servers, load-balance, and adapt your data infrastructure (via sharding, indexing, replication) or make architecture changes to allow your system to adapt to scale. Finally, understanding coding best practices like version control, code reviews, dependency maintenance, and how to manage technical debt helps you keep evolving your system over time. 

Coding agents have changed how we build software, including software that does not contain any AI components. Some parts of coding knowledge — like memorizing coding syntax — are becoming obsolete. But developers who deeply understand how software works vastly outperform those who vibe code without understanding.

Understanding software fundamentals (in addition to AI) also helps you figure out what software can and cannot do. This makes them important context for how you use coding agents and shape the build. I will discuss these in the next two letters.

Keep building!

Andrew

A MESSAGE FROM DEEPLEARNING.AI

New AI course by Oracle and DeepLearning.AI focuses on building adaptive coding agents that learn from experience.

Build coding agents that learn from experience. In “Building Adaptive AI Agents,” you’ll turn an agent’s own traces into reusable skills and build a code knowledge graph that finds what keyword search misses, so your agent gets better every run instead of repeating yesterday’s mistakes. Enroll for free

News

GLM-5.3 leads in benchmarks with high scores, compared to Kimi K3 and others, showcasing model improvements.

GLM-5.3 Makes Cybersecurity Gains

Z.ai’s latest flagship model effectively ties open-weights leader Kimi K3 on Artificial Analysis’ index of intelligence benchmarks. The company revealed that the model’s increased skill at finding and exploiting software vulnerabilities warranted safety testing before releasing its weights.

What’s new: Z.ai boosted GLM-5.3’s performance at coding and agentic work solely by fine-tuning its predecessor GLM-5.2, rather than by training a new model from scratch or modifying its architecture.

  • Input/output: Text in (up to 1 million tokens), text out (up to 128,000 tokens, 90 tokens per second)
  • Architecture: Mixture-of-experts transformer, 753 billion parameters total, 40 billion active per token
  • Features: Adjustable reasoning levels (low, high, max), tool calling, structured output, streaming, context caching
  • Performance: Achieved 60 points on Artificial Analysis’ Intelligence Index; best score among all models on CyberGym (an exploit detection benchmark) in Z.ai’s tests
  • Availability/price: GLM Coding Plan subscriptions (from $18 to $168 per month) and ZCode development environment, Z.ai’s API at $1.40/$0.26/$4.40 per million input/cached/output tokens
  • Weights/license: Weights due roughly two weeks after launch, license not yet announced (GLM-5.2 uses an MIT license)
  • Undisclosed: Knowledge cutoff, training data specific to GLM-5.3

How it works: The company scaled GLM-5.2’s fine-tuning recipe, applying it to a larger and more varied set of environments (simulated workspaces where the model attempts assigned tasks). The recipe includes single-rollout asynchronous optimization, a reinforcement learning method that trains on attempts one at a time instead of waiting for an entire batch. The training method also splits long records of an agent’s attempts into compacted segments so the model learns from long-running tasks rather than only short ones.

  • The company designed coding-related training tasks to resemble long-running software engineering work rather than tidy, standalone puzzles. In one, the model received a machine learning engineer’s working environment and was asked to find the cause of a slowdown in the training pipeline, then optimize the pipeline and prove the speedup worked without degrading output.
  • Training Z.ai demanded more environments than its developers could build themselves. The company used agents to build environments and, for some tasks, reward signals as well.
  • A separate grader agent first checked whether each task was solvable within its respective environment, then scored the model’s performance. Z.ai built each grader without showing it the task’s reference solution. The grader’s verdict only counted if it accepted a correct solution and correctly rejected an untouched or unfinished one.
  • The company also studied and sought to prevent the model’s attempts at reward hacking, loopholes that the model exploits to earn rewards without properly solving the task.

Performance: Independent testing ranks GLM-5.3 on par with the top open-weights model and a few points behind leading proprietary models, with large gains in agentic work. Z.ai’s own tests show the biggest jumps in agentic coding and cybersecurity.

  • On Artificial Analysis’ Intelligence Index, a composite of nine evaluations of economically useful tasks, GLM-5.3 set to max reasoning (60 points, $0.68 per task) tied Kimi K3 ($0.84 per task) and jumped 7 points from GLM-5.2 set to max reasoning ($0.44 per task). It trails proprietary leaders, including Claude Opus 5 set to max reasoning (63, $2.34 per task), GPT-5.6 Sol set to max reasoning (61, $0.961.23 per task), and Grok 4.6 set to high reasoning (61, $0.84 per task).
  • On Z.ai’s cybersecurity testing, GLM-5.3 achieved 84.5 percent on CyberGym (finding and confirming vulnerabilities in source code by triggering errors), the best score on the benchmark, ahead of Claude Mythos 5 (83.8 percent) and GPT-5.6 Sol (83.6 percent). On ExploitBench (which tests exploit attempts against hardened software), GLM-5.3 reached 54.4 percent, more than double GLM-5.2 (24.4 percent) and ahead of Kimi K3 (32.2) but well behind Claude Mythos 5 (78.0 percent) and GPT-5.6 Sol (76.5 percent).
  • GLM-5.3’s general knowledge scores are less impressive. It answers 42.3 percent of Humanity’s Last Exam questions correctly (behind older Grok and Claude Opus models), solves 91.72 percent of GPQA Diamond’s problems (behind Gemini 3.7 Flash on medium effort), and has an AA-Omniscience Accuracy score of 34 percent, well below other top models.
  • On Code Bench, Z.ai’s own benchmark for coding tasks scored on completion and step-by-step accuracy, GLM-5.3 set to max reasoning completed 34.5 percent of tasks using roughly 75,000 output tokens per task, ahead of Claude Opus 4.8 set to max reasoning (29.5 percent, 120,000 tokens per task) but behind Claude Fable 5 set to max reasoning (39.5 percent, 57,000 tokens per task).

Z.ai’s stealth release: This week, Z.ai confirmed that Ox Alpha, a multimodal model in stealth mode that quickly gained popularity among users of OpenRouter and other platforms, is in fact GLM-5.3 Flash. The company released weights for the 320 billion parameter model under an MIT license.  

Behind the news: GLM-5.3 arrived in the middle of debates about whether open weights models with advanced cybersecurity skills are too dangerous to release and lent both sides credibility.

  • Z.ai chose temporary guardrails rather than the permanent approach taken by OpenAI and Anthropic, which both require organizations to register in order to use their models that are most capable of security exploits. Instead, Z.ai published the model’s scores on CyberGym and ExploitBench and opted to release the model’s weights only after two weeks of safety evaluation with vetted security partners.
  • GLM-5.3’s launch drew a direct response from competitors. In an August 17 post, OpenAI president Greg Brockman warned that open-weights models with cyber skills at or near the state-of-the-art would likely “significantly accelerate the threat landscape,” linking to GLM-5.3’s launch page. His warning came weeks after OpenAI’s own evaluation agents escaped their ExploitGym environment and breached Hugging Face’s infrastructure.
  • Early tests of other open weights models suggest the alarm may exceed the threat. In July, U.S. and UK AI safety institutes jointly evaluated Kimi K3 and found it didn’t execute arbitrary code, the most severe outcome, on any of the 41 ExploitBench tasks. The most capable proprietary models, with their safeguards off, averaged 20 arbitrary code executions.

Why it matters: Z.ai set out to build a stronger agentic coder but also got a model highly capable of discovering security exploits. The company deliberately added data and environments that rewarded the model when it found cybersecurity flaws. As intended, that skill climbed as training scaled, outperforming every other model on CyberBench. But the model’s gains at building exploits outstripped its designers’ goals of discovering them. The company didn’t intend for GLM-5.3 to more than double its predecessor’s score on ExploitBench; the model grew more capable simply by pursuing available rewards for exploiting vulnerabilities.

We’re thinking: Each Z.ai release is more capable and generates more buzz than the last. All users benefit from AI labs seeking to outdo each other, especially when they release the weights for everyone to study, modify, and run on their own hardware. Keep the new models coming!


Bar graph compares GPT-5.6 Sol Ultrafast and Sol, highlighting speed differences in processing tasks.

Inside AI’s Need for Speed

Developers who already track models’ cost and accuracy have good new reasons to pay closer attention to a third essential factor: speed.

What’s new: OpenAI and Cerebras previewed Ultrafast, a new API service tier that runs GPT-5.6 Sol on Cerebras hardware instead of OpenAI’s usual infrastructure.

  • Throughput: Ultrafast touts up to 750 output tokens per second. Artificial Analysis measures GPT-5.6 Sol at max reasoning on Open AI’s own API at 65 tokens per second, which would make Ultrafast about 11 times faster.
  • Time to finish: Across six quality-matched GDPVal tasks (OpenAI’s benchmark of realistic, economically valuable work tasks), Cerebras measured Ultrafast at 83 seconds per task against 7.7 minutes for standard Sol, a 5.6x end-to-end speedup.
  • Latency: GPT-5.6 has an unusually high latency. Artificial Analysis lists standard GPT-5.6 Sol at max reasoning at 97.2 seconds to its first answer token, against 14.5 seconds for GPT-5.5 at high reasoning. Neither company has published a latency figure for Ultrafast.
  • Price Availability: Limited preview for selected customers, waitlist for everyone else, no price or general-availability date announced
  • Undisclosed: Independent confirmation of benchmark figures

Two other releases landed the same week with speed as their headline pitch. Google shipped Gemini 3.7 Flash, and Nvidia released Nemotron 3.5 Lightning. All three are aimed at developers building applications where response time determines how well a product works.

What is speed, exactly?: Two measurements often show up under the word “speed” in AI, and different models and hardware handle them differently. Latency, sometimes called time-to-first-token, is the wait before a model’s response arrives; throughput is how many tokens per second it produces once it starts. Ultrafast targets throughput: Cerebras’ hardware keeps GPT-5.6 Sol’s weights in 44 gigabytes of on-chip SRAM, avoiding the trips to external memory that create bottlenecks on GPU-based inference.

  • GPT-5.6 Sol on Ultrafast: The clearest throughput demonstration comes from Cerebras. Ultrafast answered all 2,500 questions on Humanity’s Last Exam, a test of expert-level questions across more than 100 subjects, in 11 hours and 11 minutes, compared to 78 hours and 27 minutes for Claude Fable 5, that is, about 7 times faster. Cerebras also reports Ultrafast running 11 times faster than Claude Fable 5 and 5 times faster than Claude Opus 4.8 on Fast mode overall.
  • Gemini 3.7 Flash: Google hasn’t disclosed throughput or latency figures for Gemini 3.7 Flash, but Artificial Analysis measured 330 output tokens per second — only behind Gemini 3.5 Flash-Lite — and a 13.2-second wait to the first token. The model also posts performance gains measured against its predecessor: Its Artificial Intelligence Index average is 56, up from 52 for Gemini 5.6 Flash.
  • Nemotron 3.5 Lightning: Up to 4 times faster output than other models in its class and 30 percent faster agentic task completion, according to Nvidia. Artificial Analysis measured a throughput average of 302 output tokens per second across providers, with a 7.5 second time to first token. Nvidia’s NeMo Switchyard, an open-source routing library released alongside the model, sends each step of an agentic workflow to whatever available model best fits that step’s needs for speed, quality, or cost. Nvidia reports that routing through Switchyard, rather than running every step on a single large model, cut task-completion cost to about a third of the cost of Claude Opus 4.8 alone.

Behind the news: Ultrafast isn’t OpenAI’s only investment in speed. This week, the company released its first test results for Jalapeño, its new inference chip produced in partnership with Broadcom. These tests show promising latency and throughput measurements when running both OpenAI’s and open weights models. Note that chipmakers also have to balance speed against the total number of users and power used by their hardware: Each affects cost and reliability of inference.

Why it matters: Inference at these speeds changes what a model can be used for rather than just how well it performs a fixed task.

  • In conversational and other real-time applications, users notice latency directly: A voice assistant that pauses for more than about a second starts to feel broken, because human conversation runs on turn gaps of roughly 0.3 to 1 second.
  • For developers using agents to write code, a few minutes of wait time for a result is long enough to get distracted, lose your place, or start another task. Coming back later means rebuilding the problem in your head, which increases mental fatigue from context switching.
  • Low latency and high throughput help always-on agents monitor a system, a website, or a security feed and react as events happen. An agent that takes one minute of analysis to notice a problem potentially already missed the window to act on it in real time.
  • Tool use is also highly latency- and throughput-dependent. Search, code execution, and data retrieval tools all add time to agentic workflows.

We’re thinking: Faster AI models have already enabled agents that code, retrieve data, and respond to conversations at the speed of speech. We encourage developers not only to think about which of their applications require more throughput and less latency, but new applications that are only possible with the kinds of speed new models and hardware can deliver.


Plugin configuration screen with multiple plugins enabled, reflecting DeepSeek-V4-Pro’s new features.

DeepSeek-V4-Pro Gets Refreshed

DeepSeek’s flagship model graduated from preview with improved performance plus the harness the model was benchmarked in. The harness is free and open-source, but the company’s model prices increased.

What’s new: DeepSeek released DeepSeek-V4-Pro-0813, the official version of the larger of its two fourth-generation models.

  • Input/output: Text in (up to 1 million tokens), text out (up to 384,000 tokens, 78.1 tokens per second)
  • Architecture: Mixture-of-experts transformer, 1.6 trillion total parameters, 49 billion active per token; optional speculative decoding module brings the checkpoint to 1.7 trillion parameters
  • Features: Adjustable reasoning (none, low, high, max), defaults to high reasoning; tool calls; context caching
  • Performance: 53 points on Artificial Analysis’ Intelligence Index, third among open weights models; 10th of 115 models on Arena’s WebDev leaderboard
  • Availability/price: Via DeepSeek’s app and website via Expert Mode; via DeepSeek’s API at $1.32/$0.044/$3.96 per million input/cached/output tokens during peak hours (01:00–04:00 and 06:00–10:00 UTC), half price during off-peak hours
  • Weights/license: Free for commercial and noncommercial use under the MIT license
  • Undisclosed: New training data and methods, knowledge cutoff

The company also released an open-source agent harness in developer preview and increased its API prices for all models.

How it works: DeepSeek-V4-Pro-0813 keeps the parameter count and architecture of the April preview, including DSpark, the speculative decoding module DeepSeek earlier released for the preview. DeepSeek says the update sharpens the model’s agentic skills but did not specify what it changed.

  • DeepSeek pretrained the preview on more than 32 trillion tokens, then fine-tuned 10 separate model copies on individual domains via supervised learning and reinforcement learning. Finally, it merged them into one model via on-policy distillation, in which a new copy, the student model, imitated the 10 specialists’ outputs.
  • DeepSeek’s hybrid attention alternates between two kinds of attention layers. Both compress the keys and values the model stores while reading input, but one also attends only to a selected subset of tokens. For 1 million tokens of input, the model uses only 27 percent of the computation and 10 percent of the memory for stored keys and values that DeepSeek-V3.2 required.
  • The model returns reasoning along with its answer. When a request includes tool use, later API requests must include past reasoning traces or the API rejects them. This lets reasoning persist across calls.
  • DeepSeek Harness treats models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and user interfaces as configurable, swappable plugins. It logs everything the model ingests, such as system prompts, reasoning, tool calls and results, subagent scheduling, and context injection, so any session can be resumed, forked, searched, or replayed. Its minimal mode, which gives a model only a shell and file editor, is the setting DeepSeek used for its coding-agent benchmarks. It is built on a plugin kernel called Cordis, and DeepSeek and Peking University described its design in a paper.
  • DeepSeek’s API accepts requests in OpenAI’s Responses format, so OpenAI’s Codex coding agent can use DeepSeek models after running a setup script. This makes migrating from OpenAI models easier.

Performance: Independent evaluators found that DeepSeek-V4-Pro-0813 made large gains over its April preview, but held only a narrow lead over DeepSeek’s smaller Flash model. DeepSeek-V4-Pro-0813 debuted at third place in overall intelligence among open-weights models, but is roughly 10 points behind the best proprietary models on Artificial Analysis’ Intelligence Index. Its clearest improvement is in coding capability. The model’s cost per task remains a fraction of most proprietary leaders’, but after price cuts, OpenAI’s nearly equally capable GPT-5.6 Luna now costs less per task.

  • On the Intelligence Index, a composite of nine evaluations of economically useful tasks, DeepSeek-V4-Pro-0813 set to max reasoning (53 points, $0.25 per task) jumped eight points from its April preview set to max reasoning (45 points, $0.05 per task) and a point above DeepSeek-V4-Flash-0731 set to max reasoning (52 points, $0.11 per task). It trails 10 models on the index, including Gemini 3.7 Flash set to high reasoning (57, $0.40). It outperforms GPT-5.6 Luna set to max reasoning (52, $0.05 per task), but GPT-5.6 Luna is the rare model that costs less than the updated DeepSeek-V4-Pro or Flash per task.
  • In DeepSeek’s tests, which used max reasoning and DeepSeek Harness’s minimal setup, DeepSeek-V4-Pro-0813’s largest gains stemmed from coding-agent tasks. On Terminal-Bench 2.1 (multistep tasks in a command-line environment), it rose from 72.1 percent to 87.9 percent; on DeepSWE (resolving difficult software-engineering issues), it rose from 12.8 percent to 62.7 percent; and on CyberGym (finding software vulnerabilities), it rose from 52.7 percent to 83.3 percent, just ahead of Claude Fable 5 set to max reasoning with fallback (83.1 percent).
  • Independent evaluations that used DeepSeek-V4-Pro-0813 with other harnesses showed lower performance on Terminal-Bench 2.1. Vals AI, which uses their internal evaluation harness, measured the model at 54.68, and Artificial Analysis, which uses the open-source Terminus 2 harness, measured the model at 78.7 percent.

Behind the news: DeepSeek recently released an experimental version of DeepSeekV4-Flash with vision capabilities. The company has not announced plans for a similar vision-language version of DeepSeekV4-Pro.

Why it matters: DeepSeek published the harness it used to benchmark its models, which few companies do. Agentic performance is a joint function of the model and its scaffolding, so a published harness is the difference between numbers that a developer can only read and those they can reproduce. The harness is also MIT-licensed and model-agnostic.

We’re thinking: The agentic harness market is getting crowded! Although it’s an open-source release, some users may be skeptical of putting DeepSeek Harness into production before it receives a thorough evaluation from security experts, plus benchmarks when running other models besides DeepSeek’s. Let’s hope we see solid third-party testing — followed by developer experiments and modifications — soon.


Illustrated process of context management, highlighting context editing before sending to LLM input.

LLMs Take Out the Agents’ Trash

AI agents typically compact the contents of their context windows by summarizing or deleting the oldest material. Researchers devised a method that manages an agent’s memory more selectively.

What’s new: Xubin Hao and colleagues at the social-shopping site Xiaohongshu (also known as RedNote) built self-governing context (Self-GC). Like familiar agentic designs, Self-GC builds up a context of inputs and outputs that includes user requests and tool calls as well as results like URLs and file paths. Unlike typical compacting algorithms, a large language model decides which parts of the context to keep, trim, or throw away before sending it to the associated LLM.

Key insight: Rules based on types or shelf lives of inputs and outputs aren’t sufficient to enable an agent to decide which contextual information it should retain. An older tool output may hold the only copy of a URL that must be reopened later, while a recent output may have become outdated. An LLM can make such judgments in a more flexible way, because it can read the information available as the context accrues and decide which details are likely to be useful later.

How it works: When input tokens fill more than 30 percent of the primary LLM’s context window, Self-GC sends the history to a planner model (by default, Qwen3.6-Plus) and asks what to do with each user request or tool call, plus their results.

  • The planner can retain these items or pick one of three actions. (i) “Fold” sets an item aside. Its content moves to separate storage, and a short note describes its location so the agent can bring it back word-for-word if necessary. (ii) “Mask” shortens an item in place, keeping its opening and closing text while cutting repetition in the middle, which suits long logs. (iii) “Prune” deletes items the task no longer needs, such as logs of failed commands.
  • Self-GC first carries out the planned actions on a copy of the history, discarding any action that may interfere with the most recent request or the agent's ongoing response to it. Then it measures how many input tokens the remaining actions would save.
  • Self-GC shortens the history only if it estimates that it would reduce the cost of running the model on future calls including savings from using cached inputs. In practice, they found that the plan was worth applying if it shortened the history by at least 30 percent, so they used that heuristic in their tests.

Results: The authors tested Self-GC on an agent that browses the web, runs shell commands, and edits documents for Xiaohongshu users. They compared it to methods that follow fixed rules such as deleting the oldest messages or deleting the tool outputs. Self-GC removed less history, but it was far less likely to lose useful information. To measure this, the authors replayed completed conversations between real-world users and its agent. For each conversation, they stopped partway through, ran Self-GC on the history up to that point, and used GPT-5.5 to judge whether the shortened history still held every detail the real-world conversation went on to use.

  • On a set of 33 conversations deemed to be especially demanding, Self-GC removed 43.95 percent of input tokens and kept the necessary details 84.85 percent of the time. The rule-based methods removed 61.90 to 69.87 percent of tokens and kept the necessary details 54.55 to 69.70 percent of the time.
  • On a larger set of 332 conversations, Self-GC removed 31 to 34 percent of input tokens while keeping the necessary details 91.27 to 94.58 percent of the time across three different planner models (Qwen3.6-Plus, Qwen3.7-Max, and GLM-5.1), showing that Self-GC can be effective with a variety of LLMs. The rule-based methods removed 40.19 to 47.76 percent of tokens while keeping the necessary details 77.71 to 87.46 percent of the time.
  • Running live on some real-world user accounts, Self-GC removed 10 to 15 percent of input tokens compared to accounts that did not use it.

Yes, but: The authors’ evaluation tested Self-GC’s ability to retain important details, but not its ability to produce good output. The output of a system that uses a shortened context may contain the same details and output as that of of a full-context system, but it may not be as useful.

Why it matters: Reducing context to save cost carries the risk that a model may forget a detail that’s required later. Knowing what to keep, trim, and remove enables long-running agents to be affordable without becoming forgetful.

We’re thinking: John McCarthy, who coined the term artificial intelligence, invented “garbage collection” for computers around 1959 so programmers would not have to manage computer memory by hand. The need to properly manage agent memory is another way in which LLMs can be treated like an operating system — and another way software engineering fundamentals are essential to building good AI applications!