AI Coding Live News

Microsoft Open-Sources Mage-VL-Cowork, a 4B Computer-Use Agent That Chooses Between Clicking the GUI and Running Bash, Scoring 66.0% on OSWorld-Verified

On October 30, Microsoft's Mage team released Mage-VL-Cowork on Hugging Face under Apache-2.0: a 4B multimodal computer-use agent in which a single model decides at every step whether to act through screenshots and GUI clicks (computer_use) or through bash and Python in a terminal, with no external orchestrator. Microsoft reports a two-run average of 66.0% on OSWorld-Verified (361 tasks, 50-step budget), above Qwen3.6-27B at 63.9% but below the 9B SCALECUA-Qwen3.5-9B at 68.7%.

Microsoft Open-Sources Mage-VL-Cowork, a 4B Computer-Use Agent That Chooses Between Clicking the GUI and Running Bash, Scoring 66.0% on OSWorld-Verified

Key Takeaways

  • 4B parameters, built on Mage-VL (Mage-ViT vision encoder plus Qwen3-4B-Instruct-2507); about 9.48 GB of bf16 weights under Apache-2.0.
  • On OSWorld-Verified, two independent runs scored 65.33% and 66.75% for a 66.0% average; 87.5% on operating-system tasks and 62.7% on multi-app workflows.
  • In Microsoft's side-by-side, a LibreOffice Calc chart task took 39 seconds (6 steps) via Python in the terminal, versus 9:56 (39 steps) for GUI-only Qwen3.6-27B.
  • Online RL adds 10.16 points over hybrid SFT while cutting mean model calls by 13.0% and output tokens by 25.4%.
  • Training data came from Mage-CUA-Forge, which synthesized about 294K desktop and web tasks across 6,915 skills and cut per-task generation cost from $0.906 to $0.158.
Read full story
Linked Models & Agents:
⚡ Mage-VL-Cowork⚡ Mage-VL⚡ Qwen3-4B⚡ Qwen3.6-27B🌐 Microsoft

X discussion: Flask creator Armin Ronacher says an Opus 5.5 agent could re-implement all of CPython in about two weeks with no human input, sparking a debate over whether the value is in the test suite

Flask creator Armin Ronacher (@mitsuhiko) posted on November 1 that he is convinced an Opus 5.5 agent could now re-implement all of CPython in about two weeks against just the tests, with no human input, possibly with ABI compatibility, no GIL, a JIT, and better numbers on every measurable metric. The post had about 1,637 likes, 98K views and 162 replies. He later added that a rewrite does not strictly need an existing test suite, and that having the agent build its own tests is often better for porting. antirez agreed, while Mario Zechner and Meta engineer Kevin Newton pushed back. This is a personal prediction; no such rewrite has been done.

Key Takeaways

  • Original post: @mitsuhiko, Nov 1, 11:52 UTC, about 1,637 likes, 269 bookmarks, 162 replies and 98K views at fetch time
  • His core claim: given just the tests and no human input, an agent could rewrite CPython in about two weeks, "probably" with full compatibility including ABI, no GIL and a JIT, which he called "completely crazy"; it is a prediction, not an experiment
  • Follow-up post (14:07 UTC, about 212 likes): an existing test suite is not required, and many pre-existing tests are bad for hill climbing; he says an agent he ran a few weeks ago re-implemented the Excel formula engine and built its own test suite from scratch
  • antirez (creator of Redis) agreed that you can ask an agent to build a large test suite before starting a port; Mario Zechner disagreed, saying his problem with agents is trust and pre-existing test and conformance suites increase it
  • Meta engineer Kevin Newton pushed back that very few Python JITs have succeeded because of complexity and compatibility, and that a good one without human input is unrealistic; others noted that under PEP 703 the free-threaded build is not ABI-compatible with the standard one
Read full story
Linked Models & Agents:

X discussion: Anthropic's head of platform engineering says a team with no Rust developers had Claude port the whole Messages API to Rust, cutting CPU by roughly 40-50%

Katelyn Lesse, Anthropic's head of platform engineering, said on the Latent Space podcast (published Oct 27) that a Rust version of the Messages API fully rolled out the previous week. The old system was a CPU-hungry Python monolith, the team started with "not a single Rust developer", humans designed and verified the system, Claude wrote the implementation, and shadow traffic compared outputs between the old and new versions. Her ballpark figures are roughly 40-50% less CPU and 10-20% better time to first token. A clip posted by Somi (@somi_ai) drew 1,000+ likes and about 140K views on X and was quoted by swyx and others, with the debate centered on whether "never do the big rewrite" is now outdated advice. These are X discussion views and spoken estimates; Anthropic has not published a written engineering report.

X discussion: Anthropic's head of platform engineering says a team with no Rust developers had Claude port the whole Messages API to Rust, cutting CPU by roughly 40-50%

Key Takeaways

  • The first-hand source is Katelyn Lesse speaking on the Latent Space episode "How Anthropic ships Claude with Claude", in the "56:05 Rebuilding the Messages API in Rust" segment
  • Lesse said the move was driven by CPU becoming a bottleneck as usage surged; CPU now has to be capacity-planned in advance, and research sandboxes, product sandboxes and CI all draw from the same pool inside Anthropic
  • The team forked the entire API in Rust in one go, ran shadow traffic to confirm the Python and Rust outputs matched, then turned it on gradually, deliberately adding no new features during the port
  • Her ballpark is about 40-50% CPU savings and 10-20% better time to first token, with larger gains on longer-running workloads; these are spoken estimates from the podcast, not a formal benchmark
  • On X, Somi called "never do the big rewrite" dead advice and swyx said Anthropic "vibecoded their entire backend to Rust"; the latter is an exaggeration, since Lesse only discussed the Messages API
Read full story
Linked Models & Agents:

Kimi launches 3D Make: K3.1 Pro drives Blender, CAD tools and Unreal, Unity and Godot to build models, scenes and games

Moonshot AI's official Kimi account announced 3D Make at 03:14 UTC on Oct 30, saying Kimi connects to tools such as Blender and CAD software to create models, assemble scenes and develop games, available now on kimi.ai and Kimi Work. The companion 3D guide says K3.1 Pro was specifically trained to drive 3D software through Python scripts, so specialized tools without MCP support can join the workflow, while meshes such as people and animals are handed to diffusion services like Tripo. Plugins that need locally installed software work only in Kimi Work.

Kimi launches 3D Make: K3.1 Pro drives Blender, CAD tools and Unreal, Unity and Godot to build models, scenes and games

Key Takeaways

  • Availability: 3D Make is live on kimi.ai and Kimi Work; plugins that need locally installed software are Kimi Work only
  • Two modeling routes: parametric models (furniture, mechanical parts, buildings) via Python scripts written by K3.1 Pro, and meshes via services such as Tripo, Meshy and Hyper3D
  • Engines: Kimi says it is adapted to Unreal Engine, Unity and Godot to import models, assemble scenes and build gameplay step by step
  • Showcase: the celestial palace in the K3.1 Pro launch video was built in Unreal Engine 5.8 from source models totaling 36 million triangles, rendered with Nanite and Lumen
  • Benchmarks: no 3D benchmarks were published; the guide admits some tasks need several rounds, and rigging and complex materials remain weak spots
Read full story
ADSponsored

xAI adds a guidelines field to the Grok API for per-request moderation of NSFW, violence and profanity

On Oct 28 xAI announced on the official @grok account that all API customers can now add a guidelines array to text requests and set the nsfw, violence and profanity categories to decline, so Grok tightens that content while it writes rather than through after-the-fact filtering. The field works on the Responses API, Chat Completions and the xAI Python SDK; multi-agent models and deferred completions are not supported, and invalid values are rejected with 400 or 422 before the model runs.

xAI adds a guidelines field to the Grok API for per-request moderation of NSFW, violence and profanity

Key Takeaways

  • Three categories: nsfw, violence and profanity; the only behavior today is decline, and unlisted categories keep the default (docs)
  • Works on the Responses API, Chat Completions and chat.create in the xAI Python SDK; with the OpenAI Python SDK pass it via extra_body
  • Applies only to the request that carries it, so send it on every turn; the xAI SDK chat object stores it for you
  • Not supported on multi-agent models such as grok-4.20-multi-agent or deferred completions; duplicate categories return 400 and unknown values return 422
  • The official post had about 592K views and 271 likes when this was written
Read full story
Linked Models & Agents:

LiteLLM 1.107.0 hit by a supply-chain compromise: PyPI wheels and Docker images shipped a credential stealer and backdoor; LiteLLM says it is contained and advises pinning 1.106.2

On October 21 the release pipeline of the popular LLM gateway LiteLLM was compromised. A malicious 1.107.0 was live on PyPI for about two hours (11:39 to 13:23 UTC), and the Docker tags v1.107.0, latest, main-latest and main-stable pointed to a poisoned image from 11:46 to 14:20 UTC. LiteLLM's incident report says the payload steals cloud, SSH, AI-tool and proxy keys on every Python start; the artifacts are pulled, OSS users should pin 1.106.2 and rotate secrets, and the private enterprise registry was not affected.

LiteLLM 1.107.0 hit by a supply-chain compromise: PyPI wheels and Docker images shipped a credential stealer and backdoor; LiteLLM says it is contained and advises pinning 1.106.2

Key Takeaways

  • Scope (vendor figures): all 7 PyPI wheels of litellm==1.107.0, live 11:39:51 to 13:23 UTC; 4 Docker Hub and GHCR tags poisoned from 11:46:56 UTC
  • Attack chain: the attacker held 3 sets of developer GitHub CLI credentials, one belonging to an org owner, used it to disable branch protection and force-push, then had the release workflow build and sign from the lookalike repo Berri-AI/litellm
  • Payload: cook.pth, cook.py and sitecustomize.py run on any Python start and survive uninstalling litellm; a second loader fetches remote code hourly
  • Fix: delete the 3 files and matching .pyc first, then pin litellm==1.106.2 or rebuild from scratch, and rotate every provider key in the proxy DB, the master key and the database password
  • This is LiteLLM's second supply-chain incident of 2026 (versions 1.82.7/1.82.8 in March); the GitHub source tag v1.107.0 itself is clean
Read full story

Claude API ships version 2026-10-21, its first since 2023: sampling parameters removed, new major SDKs across languages

On Oct 21 Anthropic released Claude API version 2026-10-21, its first official version since 2023. It removes the temperature, top_p and top_k sampling parameters and drops old Admin API field names, while new SDK majors (Python 2.0, TypeScript 1.0, Go 2.0, Java 3.0 and more) default to it. Version 2023-06-01 is not deprecated.

Key Takeaways

  • Version: 2026-10-21 is the Claude API's first official version since 2023; 2023-06-01 is not deprecated and more frequent versions are planned
  • Breaking: sending temperature, top_p or top_k returns a 400 on every model; Claude 4.7+ models behave as before
  • SDKs: Python 2.0.0, TypeScript 1.0.0, Go 2.0.0 (/v2 path), Java 3.0.0, C# 13.0.0, Ruby 2.0.0, PHP 1.0.0, ant CLI 2.0.0
  • Auth: SDKs send the API key as Authorization: Bearer and hold 1 credential per client; SDK license moves to Apache 2.0
  • Platforms: Claude API, Claude Platform on AWS, Microsoft Foundry, Google Cloud; Bedrock only for Claude 4.7+, see the migration guide
Read full story

BlenderWorld Benchmark Launches for Autonomous 3D Creation: GPT-6 Astra Leads with 79.9 Score on 223 Industrial Tasks

Researchers introduced BlenderWorld (arXiv:2610.23986), the first comprehensive benchmark evaluating visual agents creating and editing 3D models from real-world references in Blender. Spanning 223 tasks across procedural geometry, Python scripting, material shaders, spatial layouts, and lighting, GPT-6 Astra leads the benchmark with a composite Score of 79.9 (and a 42.2% Perfect completion rate), followed by Opus-5 at 73.0. Open-weight flagship DeepSeek-V4.1-Flash claims 65.7, matching proprietary models while relying on active execution-and-inspection tool loops.

BlenderWorld Benchmark Launches for Autonomous 3D Creation: GPT-6 Astra Leads with 79.9 Score on 223 Industrial Tasks

Key Takeaways

  • Researchers introduced BlenderWorld (arXiv:2610.23986), a 223-task benchmark evaluating autonomous visual agents creating 3D content in Blender
  • GPT-6-Astra leads the world with a 79.9 composite Score and 42.2% Perfect completion rate, followed by Opus-5 at 73.0
  • DeepSeek-V4.1-Flash ranks #1 among open models with 65.7, matching proprietary GPT-5.6-Sol on multimodal 3D synthesis (65.5)
  • Unmasks distinct engineering styles: GPT emphasizes upfront planning (39.9K tokens), while DeepSeek uses iterative inspection loops (168 tool calls/task)
Read full story
Linked Models & Agents:

OpenAI open-sources MultiLangBench and reports low-resource language gains: GPT-6 Astra averages 87.4% building SQLite across 20 languages, GPT-6.1 Sol reaches up to 97.9% on COBOL migration

On October 19 OpenAI said its latest models are much better at low-resource languages such as COBOL, Fortran, Visual Basic and OCaml, and open-sourced MultiLangBench, which asks a model to build a SQLite-compatible database engine from scratch in each of 20 languages. GPT-6 Astra averages an 87.4% test pass rate (GPT-5.6 Sol: 26.8%), above 83% in 19 of 20 languages, with COBOL hardest at 72.1%. On a separate COBOL migration eval requiring byte-for-byte output parity after porting to C++, Java, Kotlin, Python or Rust, GPT-6.1 Sol scores 86.6% at low effort (GPT-5.6 Sol: 5.4%) and 97.9% at higher effort. All figures are OpenAI's own.

OpenAI open-sources MultiLangBench and reports low-resource language gains: GPT-6 Astra averages 87.4% building SQLite across 20 languages, GPT-6.1 Sol reaches up to 97.9% on COBOL migration

Key Takeaways

  • MultiLangBench: GPT-6 Astra (max) averages 87.4% across 20 languages vs 26.8% for GPT-5.6 Sol, above 83% in 19 of them (OpenAI-reported).
  • Per language: COBOL 10.9% to 72.1%, OCaml 25.6% to 85.8%, Fortran 21.4% to 83.5%, Visual Basic 27.5% to 89.4%.
  • Budget tier: GPT-6 Luna averages 40.3% at about $0.77 per sample vs $3.48 for GPT-5.6 Sol, roughly 78% cheaper.
  • COBOL migration: GPT-6.1 Sol scores 86.6% at low effort (GPT-5.6 Sol 5.4%) at about 61% of the API cost; 97.9% at higher effort, near saturation.
  • The eval setup, test suite and per-language results are on GitHub openai/multilangbench; the COBOL migration eval is not public.
Read full story

vLLM Ships Precompiled Bytecode Images and Decision 3.0 Serving: Cold Start Accelerated by 18%, MI325X Decision Throughput Hits 1.8x

The vLLM team announced two major milestones: shipping precompiled Python bytecode via uv in v0.32.0 release images cuts cold-start container launch by 14–18% (~18s on NVIDIA H100) with zero runtime recompiles. Additionally, vLLM integrated the Decision 3.0 (D3) structured reasoning family (0.6B to 27B) into the /v1/systemone endpoint, ranking #1 on the Jev Decision Index and delivering 1.8x req/s on a single AMD MI325X under 64 concurrent clients.

vLLM Ships Precompiled Bytecode Images and Decision 3.0 Serving: Cold Start Accelerated by 18%, MI325X Decision Throughput Hits 1.8x

Key Takeaways

  • vLLM ships precompiled Python bytecode via uv in official images, reducing H100 cold starts by 14–18% (~18 seconds saved)
  • Natively serves the Decision 3.0 (D3) family (0.6B to 27B) via the /v1/systemone structured decision endpoint
  • D3 models rank #1 on the Jev Decision Index with 66.3 in text and 71.3 in vision
  • D3 27B achieves 1.8x the request throughput of standard checkpoint servers on a single AMD Instinct MI325X under 64 concurrent clients
Read full story
Linked Models & Agents:
ADSponsored

vLLM v0.32.0: 814 commits, built-in /v1/systemone structured-decision endpoint, NVFP4 KV cache on more GPUs, and 43–85% more req/s with multiple API workers

vLLM shipped v0.32.0 on Oct 18 with 814 commits from 363 contributors (121 new). Highlights: a default-served POST /v1/systemone structured-decision endpoint and a generic hf tool/reasoning parser; NVFP4 KV cache on SM8x/SM90/SM12x and FP8 KV by default for GLM-5.x on SM100; Model Runner V2 gains a GPU n-gram speculator and Elastic EP and becomes the ROCm default; three security advisories are fixed, default CORS is restricted, and Python 3.10 is dropped.

vLLM v0.32.0: 814 commits, built-in /v1/systemone structured-decision endpoint, NVFP4 KV cache on more GPUs, and 43–85% more req/s with multiple API workers

Key Takeaways

  • Scale: 814 commits from 363 contributors (121 new); see the release notes.
  • Structured decisions: POST /v1/systemone is new and served by default for choice/score questions, including Cloudflare/clef-omni and LiquidAI/d1-3B; --tool-call-parser hf reads a checkpoint's response_template so no model-specific parser is needed.
  • Low-precision KV: GLM-5.x defaults to FP8 KV on SM100, halving KV memory per rank with 2.3–5.5% more throughput at a 7–11% TTFT cost (PR benchmark, vendor figures); ROCm adds a 4-bit KV cache at about 2x FP8 density.
  • Serving: with --api-server-count above 1, connections go to the least-loaded worker for 43–85% more req/s on short requests (Qwen3-0.6B, 32 in / 1 out tokens, PR benchmark).
  • Breaking: Python 3.10 dropped, default CORS origins restricted, cascade attention removed, and max_tokens is no longer reserved from the context window.
Read full story

Tencent Hunyuan open-sources Hy Memory 2.0: ~3B-active memory writer averages 55.49 across four harnesses (vendor-reported, edging Opus 5), plus MemHub local memory for Claude Code, Cursor and Codex

On Oct 16 Tencent Hunyuan open-sourced Hy Memory 2.0 in three layers: the Apache-2.0 memory-writer model Hy-Memory-30B-A3B (~3B active, HF weights plus arXiv report), a Python SDK covering Chat, Working and Coding scenes (PyPI hy-memory 2.0.x), and local-first MemHub (CLI + macOS, preview). Per Tencent, swapping it in as the writer across Mem0, MemOS, Hy-Memory and held-out EverMemOS yields a 55.49 average vs 54.62 for Claude Opus 5, measured on fixed 20% subsamples; it still trails Opus 5 on several individual metrics.

Tencent Hunyuan open-sources Hy Memory 2.0: ~3B-active memory writer averages 55.49 across four harnesses (vendor-reported, edging Opus 5), plus MemHub local memory for Claude Code, Cursor and Codex

Key Takeaways

  • Vendor-reported: 55.49 four-harness average vs 54.62 for Claude Opus 5 and 53.64 for DeepSeek V4.1 Flash
  • Held-out EverMemOS: 56.89 vs Opus 5 at 54.04; still trails on Mem0 LoCoMo (59.54 vs 69.47)
  • ~3B active, Apache-2.0, tested on vLLM v0.31.0 with an OpenAI-compatible API
  • SDK installs via pip install hy-memory with automatic Chat/Working/Coding routing
  • MemHub runs on Linux and macOS (preview); Windows unsupported
Read full story

Last Secure Code Benchmark: Vibe Coding Under Fire as Top Agents Produce Secure Code on Only 25.1% of Tasks

While AI coding agents and 'vibe coding' workflows synthesize an unprecedented volume of production software, code security remains highly fragile. Researchers from NUS and Monash University introduced the Last Secure Code Benchmark, evaluating 450 tasks derived from 150 real CVE vulnerabilities across 7 languages (Java, C, C++, JS, Python, PHP, Go) and 24 CWE categories (including 21 of the 2025 CWE Top 25 and 8 of the Top 10 KEVs). While frontier agents achieve 73.6% to 91.3% functional completion rates, even the strongest model (Claude Fable 5) produces code that is both functional and secure on only 25.1% of tasks, exposing acute supply-chain risks in autonomous vibe coding.

Last Secure Code Benchmark: Vibe Coding Under Fire as Top Agents Produce Secure Code on Only 25.1% of Tasks

Key Takeaways

  • First comprehensive vibe-coding security benchmark: 450 tasks based on 150 CVEs spanning 7 languages, covering 21 of the 2025 CWE Top 25 and 8 Top 10 KEVs
  • The functionality illusion: while agents pass functional specs at 73.6%–91.3%, dual functional-and-secure pass rates collapse to 16.4%–25.1%
  • Vulnerability defense crisis: across full-repository and file generation scenarios, top models resolve only 12% of vulnerability environments securely
Read full story

Beyond Pure Neural Prompt Loops: ABCAgent Treats Agent Behavior as Code, Achieving Over 92% Reusability and Robust Execution

Mainstream LLM agents predominantly rely on purely neural orchestration loops (such as ReAct), generating each step, tool call, and control decision through unconstrained language token generation. This paradigm suffers from high API latency, steep operational costs, rapid error cascading, and an inability to reuse verified execution logic across recurring task instances. Researchers from Uniphore introduce ABCAgent (arXiv:2610.04824), an innovative neuro-symbolic framework treating Agent Behavior as Code. ABCAgent decouples agent design from execution: a foundation model serves as a runtime designer to author and edit explicit programmatic specifications (Python programs with embedded neural functions), while a deterministic executor handles control flow, variable bindings, and state transitions. Evaluated across GAIA, Augmented GAIA, GSM-Symbolic, τ²-bench, and WorkArena, ABCAgent matches or exceeds neural agent accuracy while demonstrating superior stability. Crucially, it solves 92.6% of GSM-Symbolic and 20.1% of Augmented GAIA task instances without code synthesis simply by rebinding parameters into existing programs, slashing latency and inference overhead.

Key Takeaways

  • ABCAgent introduces a neuro-symbolic framework specifying agent behavior as executable Python programs
  • Solves 92.6% of GSM-Symbolic tasks via parameter rebinding without LLM re-authoring, drastically cutting cost and latency
  • Exhibits superior stability on τ²-bench and WorkArena over neural loops, eliminating error compounding in loops
Read full story

Tracing the Thoughts of a Coding Agent Playing ARC-AGI-3: White-Box Lessons for Continual Learning

Continual learning without weight fine-tuning represents a frontier in LLM agent research. When an agent acts purely by writing and executing Python scripts inside an execution sandbox, every thought, hypothesis, and plan leaves a verifiable trace on disk. In a newly released study (arXiv:2610.11450), researchers subject coding agents to ARC-AGI-3—a suite of instruction-free abstract visual reasoning environments where each sequential level introduces novel causal dynamics. Developing a fine-grained measurement protocol, the authors trace thoughts across file artifacts across seven full evaluation runs spanning three foundation backbones from two major model families. The empirical findings reveal that scripts written for one level are almost never invoked in subsequent levels (only 33 of 630 cross-task references survive), as agents deliberately abandon 74% of scripts at task boundaries to purge level-specific overfitted state while rewriting core rules. Notes are maintained in an append-only fashion, with conflicting claims arbitrated against raw execution logs to achieve selective rather than catastrophic forgetting. Crucially, the study identifies carrying hard-coded variables across task boundaries as the single most devastating failure mode of autonomous agents.

Key Takeaways

  • Presents the first white-box thought-tracing audit of coding agents continually learning across ARC-AGI-3 environments
  • Finds agents deliberately abandon 74% of scripts at task shifts to purge state, settling append-only notes against immutable logs
  • Identifies carrying hard-coded constants across task boundaries as the single most catastrophic agent failure mode
Read full story
Linked Models & Agents:
⚡ ARC-AGI-3⚡ Coding-Agent⚡ Continual-Learning🤖 ARC-Agent🤖 Thought-Tracer🌐 Hugging Face🌐 Open Source Research