1. Models

GLM‑5.3‑Flash: Z.ai bets not on maximum size, but on the cost of long agent workloads

What happened. Z.ai formally introduced GLM‑5.3‑Flash and opened its weights under MIT. The model has 320 billion parameters, but only 18 billion active, is natively multimodal, and supports a context window of up to 1 million tokens. It was previously tested anonymously as Ox Alpha, and some Z.ai products had already begun integrating it prior to today's public disclosure.

Architecturally, the most interesting aspect is the combination of sparse and linear attention. According to Z.ai, compared to the full GLM‑5.3, this results in roughly 3× less compute for attention and a 4.4× smaller KV-cache.

What the data showed. On vendor benchmarks against GLM‑5.2:

• Terminal Bench 2.1: 84.3 vs 81.0
• DeepSWE v1.1: 63.4 vs 46.2
• Toolathlon Verified: 78.4 vs 59.9
• AutomationBench: 48.8 vs 26.2
• Agents’ Last Exam: 26.3 vs 20.4.

These are Z.ai's own evaluations; they are not yet independently verified.

The infrastructure part is separately important. Z.ai claims that the model's real traffic has already been served on Chinese AI accelerators, and its own serving stack delivered approximately 3× improvement in end-to-end serving performance compared to the initial baseline on the same hardware.

Why it matters. Agent workloads are highly sensitive not only to model intelligence but also to the cost of each additional step. If an agent makes dozens or hundreds of model calls, uses a million-token context, and constantly looks at screenshots/documents, efficiency becomes part of capability.

This is precisely why a Flash model could be more important than yet another expensive frontier model: it potentially fits as a layer of workers within a system, leaving the expensive model for planning, difficult reasoning, and verification.

What you need to understand already: MoE / active parameters, KV-cache, sparse attention, linear attention, model routing.

What this could change. It's worth testing not just:

Claude vs GPT vs GLM

but the architecture:

expensive planner/verifier → cheap multimodal workers.

For a production agent, the comparison should include completion rate, cost per completed task, latency, and the number of human interventions.

Date: September 7. Primary source: Z.ai — GLM‑5.3‑Flash

2. Architecture and operation of agent systems

OpenAI for the first time shows real internal scale of coding agent usage: 3.1 agent-workdays per human one

This is the main piece of this issue.

What happened. OpenAI published internal data on how its researchers use coding agents. The company claims it has achieved its goal of an "automated research intern": a system capable, under human guidance, of performing well-defined tasks that would take a qualified researcher several days.

As of mid-August, the total agent runtime within the research organization reached 3.1 standard agent-workdays for every human workday. Until June, the total agent runtime was less than human labor — after June, the ratio flipped.

What the data showed.

The median OpenAI researcher already uses coding-agent inference costing more than $600 per day at API prices. The 90th percentile is over $7,000 per day. More and more employees are running four or more agents simultaneously.

The number of experiments per active experimenter in August reached a peak for the entire observation period since January 2025. OpenAI notes a correlation with the spread of Codex, but separately warns: the company's compute capacity was also growing simultaneously, so causality is not proven here.

The most important limitation: among successful tasks that would take a human 4–8 hours, more than half still required at least one human intervention.

This is not a benchmark. This is vendor-reported production telemetry from its own research organization.

Why it matters. Until now, most discussions about agent productivity have revolved around SWE-bench, demos, or individual companies.

Here, for the first time, a sufficiently concrete operating model appears:

human researcher → several parallel agents → experiments/code/infrastructure → human steering → human judgement.

That is, the most advanced organization has not replaced the researcher with an agent. It has increased the amount of parallel computational work around one person.

This looks very much like what an engineering team might look like in a few years.

What you need to understand already: agent concurrency, human-in-the-loop, long-horizon task, inference economics, AI R&D loop.

What this could change. Perhaps the wrong metric for adopting coding agents is "how many developers can be replaced."

More useful ones are:

• how many parallel workstreams one engineer can oversee;
• how many experiments a team can run;
• how much throughput has increased;
• where the human still becomes the bottleneck;
• how much an additional agent-workday costs.

For small companies, this is especially important: the economics may start to look not like "AI is cheaper than an employee," but like "one strong engineer is now capable of managing a significantly larger volume of execution."

Date: September 6. Primary source: OpenAI — Research acceleration: The view inside OpenAI

But scaling agents immediately runs into supervision

The same report contains a second, almost opposite signal.

OpenAI writes that high-level planning still constitutes a small part of agent workload. People continue to define research priorities, decide which results are important, and make decisions about scaling, stopping, and deployment.

The result is a division:

agents scale execution well; human judgement scales significantly worse.

This is potentially the next bottleneck for agent organizations.

Instead of writing code directly, the person begins to engage in:

goal setting → task decomposition → monitoring → evaluation → selection → escalation.

What you need to understand already: orchestration, delegation, evaluation, human supervision, management bandwidth.

What this could change. The next layer of developer tooling will likely optimize not code generation, but managing dozens of parallel agent tasks: priorities, status, blockers, verification, and exceptions.

OpenAI also showed an unusual economic effect of safety controls: compute simply flows to other tasks

After identifying agent security issues, OpenAI temporarily halted the container service used for training on July 20, then restored it with stricter limits. RL-training of the latest deployable models was paused for about two weeks.

After Astra required a more secure research environment, GPU allocation for Astra-class workloads fell by another 59.2% the following week.

But GPU allocation for other model classes increased by 17.2%, compensating for roughly 85% of the Astra compute reduction.

Why it matters. This is a good example of a systemic effect.

Restricting one workflow ≠ stopping innovation.

If expensive compute is already purchased, the organization almost inevitably starts looking for other workloads to direct it to.

For business, similar logic applies to people and inference budget: if one autonomous workflow is deemed too risky, resources can quickly shift to less autonomous but still useful scenarios.

What you need to understand already: RL training, compute allocation, sandbox, defense in depth, opportunity cost.