Apply editorial pass from Notion v5

README.md

@@ -13,6 +13,8 @@ We fine-tuned GLM-4.7-Flash to push its agentic coding capabilities further: fro
 
 This 30B Mixture-of-Experts model beats competitors 3.5-4× its size — Qwen3.5-122B-A10B and Devstral-2 — and surpasses Ling-2.6-Flash by a narrow margin.
 
+We trained it with [Halo](https://github.com/whitecircle/halo), the post-training framework we’re open-sourcing today — the full story of the framework [here](https://whitecircle.com/research).
+
 ![Score vs cost-per-task scatter plot on SWE-rebench-V2, 500 Python tasks: GLM-4.7-Flash-Coder at 0.417 sits 26% above GLM-4.7-Flash at 0.332, at a lower cost per task](media/score_vs_cost.png)
 
 ## More reasoning, fewer turns
@@ -23,17 +25,19 @@ Although GLM-4.7-Flash-Coder does 2.4× more reasoning than the base model, it c
 
 ## The key to turn efficiency is concurrent tool calls
 
+The fine-tuned model learned to batch its tool use instead of working one call at a time. Turns with two or more parallel `read` calls jumped from 1.6% to 9.7% of all turns, parallel `bash` from 0.6% to 7.2%, and parallel `edit`, which is almost nonexistent in the base model, grew ~90×. Reading three files in one turn instead of three turns is exactly the kind of habit that compounds into 45% fewer turns overall.
+
 ![Frequency of responses with 2+ read, bash, and edit tool calls: the SFT model issues simultaneous tool calls 6–90× more often than the base model](media/simultaneous_tool_calls.png)
 
 ## SWE-rebench-V2
 
-We trained and evaluated models on [nebius/SWE-rebench-V2](https://huggingface.co/datasets/nebius/SWE-rebench-V2) — a dataset of 32k agentic coding tasks. It consists of real issues from public repositories, closely representing real-world SWE challenges.
+We trained and evaluated models on [nebius/SWE-rebench-V2](https://huggingface.co/datasets/nebius/SWE-rebench-V2), a dataset of 32k agentic coding tasks. It consists of real issues from public repositories, closely representing real-world SWE challenges.
 
 ![SWE-rebench-V2 pipeline: a repository and an issue enter an agentic loop in a sandbox, the generated patch is checked by the test-suite verifier, and the reward is 1 if all tests pass](media/SWE-rebench-V2-pipeline.png)
 
 ## Teacher — GLM-5.1
 
-The training data comes from GLM-5.1 acting as a teacher. We ran it on the train split with 4 rollouts per task and kept only trajectories that passed the tests — 7,777 successful multi-turn traces after rejection sampling.
+The training data comes from GLM-5.1 acting as a teacher. We ran it on the train split with 4 rollouts per task and kept only trajectories that passed the tests: 7,777 successful multi-turn traces after rejection sampling.
 
 We’re releasing the [training dataset](https://huggingface.co/datasets/whitecircle/swe-rebench-v2-glm-5.1-pi-agent-successful-traces) alongside the [train/test splits](https://huggingface.co/datasets/whitecircle/swe-rebench-v2-clean-python-tasks).
 
@@ -115,21 +119,21 @@ Perhaps the most surprising transfer was the `git stash` usage:
 > git stash && python -m pytest tests/test_markdown.py::test_markdown_table -xvs 2>&1 | tail -20
 > ```
 
-## Loss decomposition into Reasoning & Tool Calls
+## Loss decomposition into Reasoning vs. Tool Calls
 
-We only train on assistant responses. Of 177 million tokens in the dataset, only 46 million carry loss — the remaining 131 million (system prompts and tool responses) are masked.
+We only train on assistant responses. Of the 177 million tokens in the dataset, only 46 million carry loss — the remaining 131 million (system prompts and tool responses) are masked.
 
-Assistant messages are split into two parts — reasoning and tool calls. Naturally, tool call tokens have much lower entropy. These parts are very different in nature:
+Within an assistant message there are two very different kinds of tokens, mainly reasoning and tool calls. Tool-call tokens are far lower-entropy:
 
 ![A training trace rendered with per-token probabilities: reasoning tokens in green, tool call tokens in orange, lighter shades meaning higher probability](media/reasoning-tool-calls-logprobs.png)
 
-Although tool call tokens make up 43.3% of input tokens, they only contribute to 16.1% of overall loss. To track convergence separately, we decompose loss into two components — negative log-likelihood on reasoning and tool calling tokens, respectively.
+Although tool-call tokens make up 43.3% of input tokens, they contribute only 16.1% of the overall loss. To track convergence separately, we decompose the loss into two components: negative log-likelihood on reasoning tokens and on tool-call tokens.
 
 ![Train and eval loss curves decomposed into reasoning and tool-call components with epoch boundaries; every eval loss reaches its global minimum at step 300](media/train_loss_decomposition.png)
 
-Training loss charts show 10-20% epoch cliffs, indicating benign memorization of repeated data.
+The training-loss curves show 10–20% cliffs at epoch boundaries — the usual signature of memorizing repeated data. We read it as benign: eval losses keep improving through the second epoch.
 
-Although it’s possible to set different learning rates for two components, we observed that on our data, eval losses reach their global minima simultaneously — at the end of epoch 2.
+It’s possible to set different learning rates for the two components, but on our data both eval losses reach their global minima at the same moment (the end of epoch 2) so we didn’t need to.
 
 ## Test scores
 
@@ -147,15 +151,13 @@ FlashAttention-4 is a fast attention kernel — but it’s incompatible with GLM
 
 > *FlashAttention-4 produces NaN gradients for this model’s head_dim-256 partial-rotary attention; falling back to `attn_implementation='sdpa'`.*
 
-We found that the incompatibility only appears in the backward pass — the forward computation is correct. So we designed a hybrid scheme: FA4 handles the forward pass, while FA2 takes over for the backward. The hybrid approach gave a 1.36× increase in attention throughput.
+We found that the incompatibility only appears in the backward pass; the forward computation is correct. So we designed a hybrid scheme: FA4 handles the forward pass, while FA2 takes over for the backward. The hybrid approach gave a 1.36× increase in attention throughput.
 
 *We’ll have a separate post on FA4-fwd-FA2-bwd in [our research blog](https://whitecircle.com/#research); stay tuned! 💚*
 
 ## Kernels
 
-GLM-4.7-Flash is a Mixture-of-Experts model. Tokens are distributed unevenly across experts — that means MLP blocks receive tensors of varying width.
-
-The Grouped-GEMM kernel batches matrix multiplications of varying shapes into a single kernel launch. Enabling it gave a 1.6× speedup on the FFN step.
+GLM-4.7-Flash is a Mixture-of-Experts model. Tokens are distributed unevenly across experts, so the MLP blocks receive tensors of varying width. The Grouped-GEMM kernel batches matrix multiplications of varying shapes into a single kernel launch. Enabling it gave a 1.6× speedup on the FFN step.
 
 Additionally, with Liger Fused Linear Cross-Entropy, we were able to compute loss without full logit matrix materialization in VRAM, preventing OOM on long sequences.
 
@@ -165,19 +167,19 @@ Together, these improvements yield up to a 1.63× training speedup over TRL, rai
 
 ## Agentic infra challenge
 
-We faced a real challenge with agentic evaluation infrastructure.
+Agentic evaluation at scale turned out to be a real infrastructure problem.
 
-At a scale of thousands of concurrent agents, Docker introduces high startup overhead and heavy disk pressure, and quickly saturates the local network — resulting in a high rate of environment startup errors.
+With thousands of concurrent agents, Docker brings high startup overhead and heavy disk pressure, and quickly saturates the local network — producing a high rate of environment startup errors.
 
 Kubernetes struggled at high concurrency on a single host as well: it couldn’t set up and tear down pods fast enough, triggering timeouts. The problem was worst on powerful hosts: they could support enormous concurrency, but pod scheduling couldn’t keep up, so we never reached full CPU or RAM utilization.
 
 ## Overlay sandboxes
 
-Our solution is the Overlay Sandbox: instead of a container image, the agent runs on the bare host, in an isolated filesystem and process group.
+Our solution is the Overlay Sandbox: instead of a container image, the agent runs on the bare host, inside an isolated filesystem and process group.
 
 It has three layers: a base filesystem with the OS and repository, a hidden layer with the verifier suite, and an upper layer holding all edits and pip-installed packages.
 
-Because overlay mounts are lazy (they don’t even index the filesystem!) and only track modified files, sandbox startup is essentially free.
+Because overlay mounts are lazy (they don’t even index the filesystem!) and track only modified files, sandbox startup is essentially free.
 
 ![Overlay sandbox diagram: a read-only base filesystem, hidden verifier files not visible to the agent, and a writable lazy overlay mount holding edits and new files](media/overlay_sandbox.png)