daily

Declare an agentic task. AX runs it at scale. AX sandboxes your task, wires up its workspace, fences its network, and helps you run billions of them per cluster. Either use a single task per agent, or compose as many as your agent needs. $ cat task.yaml apiVersion: ax.io/v1alpha1 kind: Workspace metadata: name: golang spec: git: - repo: https://github.com/golang/go.git branch: "my-fix" --- apiVersion: ax.io/v1alpha1 kind: Task metadata: name: test spec: workspaces: - name: golang goal: "Ensure that Go tool chain is available and is built from source" debug: true $ ax apply -f task.yaml workspace.ax.io/golang created task.ax.io/test created $ ax watch task test Watching task default/test... [10:42:01] Phase: Pending Actor: test WorkerIP: [10:42:05] Phase: Running Actor: test WorkerIP: 10.20.3.67 Task reached terminal phase "Running". $ ax get tasks NAME ATESPACE PHASE ACTOR WORKER-IP AGE test default Running test 10.20.3.67 5s $ ax ssh test -- ls /workspace go $ ax ssh test -- cd /workspace/go && go build ./... $ ax ssh test -- ps -o pid,cmd PID CMD 1 /usr/local/bin/ax-task-runner 12 go build ./... $ ax ssh test -- touch notes.txt $ ax suspend task test task.ax.io/test suspended $ ax resume task test task.ax.io/test resumed $ ax ssh test -- ls notes.txt notes.txt $ ax suspend task test task.ax.io/test suspended $ ax delete task test task.ax.io/test deleted Why AX Agents are a new kind of workload. They are neither microservices nor batch jobs. They accumulate state, need strict isolation, call out to model APIs and tool servers, and can burn money in a loop if nobody is watching. AX gives you four small primitives that handle all of that declaratively. Isolated execution Run untrusted agent code in a sandbox with CPU and memory limits. Cheap to create, suspend, and throw away. WorkspaceEasy workspace setup List the Git repos, MCP servers, and skills an agent needs, or just describe the goal. AX sets it all up in every sandbox before the task starts. GatewayNetwork policies Define and quickly manage network policies. Lock traffic down to an explicit allowlist of hosts and ports, inject credentials to the incoming requests. ModelOne place for config Configure models, model parameters, and secrets in one place. Rotate a key or pin a new model version with one apply. How it works Scales up to billions of tasks. AX runs on top of Agent Substrate, a compute runtime designed from the ground up for massive density and fast stateful actor lifecycles. Every task runs as a lightweight actor, allowing you to scale to billions of concurrent agent sessions per cluster without orchestrator limits. Idle agents waiting on model responses, external tool calls, or human responses are checkpointed, suspended, and brought back in under a second with zero cold-start delay. Dozens of tasks share worker resources, turning idle waiting time into spare compute capacity so you only pay when agents are actively thinking and running code. Generative platform Generative features built into the platform. AX integrates generative AI directly into the platform. For example, if you want to set up a workspace just by explaining it in plain English, the environment is prepared automatically before your task starts. apiVersion: ax.io/v1alpha1 kind: Task metadata: name: data-analysis spec: workspaces: - name: python-env goal: "Set up a Python 3 development environment" Generative workspaces Describe what a ready environment looks like in plain English. AX hands that goal to an agent on first boot to install toolchains and verify dependencies. Run anything and everything Interactive coding agents, long-running agent servers, Jupyter notebooks, headless browser testing, and custom tool runtimes—you name it. Perfect for research Spin up massive number of reproducible sandboxes to collect trajectories, run reinforcement learning loops, and evaluate agents at scale. For builders & researchers Built to be the most friendly runtime for developers and researchers. We want to make dealing with agentic infrastructure easier so you can focus on your work. AX is designed with an uncompromising focus on ergonomics, rapid iteration, and joyful workflows for both application developers and AI researchers. We aim to keep the runtime minimal and lightweight, while tastefully adding the essential features everyone needs to build, evaluate, and scale agents. About Born from research, built for production. AX was born at Google when agentic runtime systems research met frontier compute. Over years of building and operating agentic execution engines, teams across Google recognized that agentic workloads represent an entirely new computing paradigm: stateful, bursty, long-running actors that compute intensely for a minute and then wait for model responses, tool responses, or human approval. Traditional orchestrators built for stateless microservices or predictable batch jobs become cost-prohibitive when keeping idle sandboxes running, yet lack native support for sub-second suspend and resume. Drawing on agentic runtime research from Google DeepMind alongside deep experience in large-scale isolation, resumption, and scheduling, AX is being built as an open, declarative control plane purpose-built for agent execution. It abstracts tasks, workspaces, network policies, and models into core primitives so developers and researchers can run massive fleets of agents without reinventing the underlying infrastructure. This project heavily relies on Agent Substrate but provides agentic abstractions and generative runtime components.

Why Backprop Goes Backward Backprogation is an algorithm that computes the gradient of a neural network, but it may not be obvious why the algorithm uses a backward pass. The answer allows us to reconstruct backprop from first principles. The usual explanation of backpropagation (Rumelhart et al., 1986), the algorithm used to train neural networks, is that it is propagating errors for each node backwards. But when I first learned about the algorithm, I had a question that I could not find answered directly: why does it have to go backwards? A neural network is just a composite function, and we know how to compute the derivatives of composite functions using the chain rule. Why don’t we just compute the gradient in a forward pass? I found that answering this question strengthened my understanding of backprop. I will assume the reader broadly understands neural networks and gradient descent and even has some familiarity with backprop. I’ll first setup backprop with some useful concepts and notation and then explain why a forward propagation algorithm is supoptimal. Setup Recall that the goal of backprop is to efficiently compute for every weight in a neural network . To frame the problem, let’s reason about an arbitrary weight and node somewhere in : To be clear, the node refers to the output value of the node after passing the weighted sum of its inputs through an activation function , i.e.: Note that in a typical diagram, , , and would all be a single node, denoted by the dashed line. In my mind, the most important observation needed to understand backprop is this: most of computing can be done locally at every node because of the chain rule: We can compute analytically; it just depends on the definition of . And we know that . So at every node , if we knew , we could compute . The challenge with computing is that downstream nodes depend on the value of . Thankfully, the multivariable chain rule has the answer. Given a multivariable function in which each is a single variable function , the multivariable chain rule says: So we can compute for any weight , meaning we have the necessary machinery to attempt to implement backprop in a forward rather than backward pass. Let’s see what happens. Repeated terms We want a forward propagating algorithm that can compute the partial derivative for an arbitrary weight . We showed above that at node , this is equivalent to: Note that I’ve dropped the intermediate variable for ease of notation. To design our forward propagating algorithm, let’s formalize an important fact: in a directed computational graph in which node depends upon node , it is impossible to compute at any point before node : This claim should be obvious. If our computational graph represents a function , it is impossible to compute without access to and therefore . In our setup, for every downstream node that depends on a node , it is impossible to compute at node . Therefore, in order to compute , we must decompose the term using the multivariable chain rule and pass the other terms needed to compute forward to each node that depends on : We can see that such an algorithm blows up computationally because we’re forward propagating the same message many times over. For example, if we want to compute and where and are different weights in the same layer, we need to compute and separately, but all the other terms are repeated: Here is a diagram of message passing the repeated terms: I think the above diagram is the lynchpin in understanding why backprop goes backwards. This is the key insight: if we already had access to downstream terms, for example , then we could message pass those terms backwards to node in order to compute . Since each node is just passing its own local term, the backward pass could be done in linear time with respect to the number of nodes. A backward pass I hope this explanation it clarifies how you might get to backprop from first principles trying to compute derivatives in a directed acyclic graph. On a given node that depends on a node , we simply message pass back to . The multivariable chain rule helps prove the correctness of backprop. For any node with downstream weights , if simply sums the backwardly propagating messages, it computes its desired derivative: Once you understand the main computational problem backprop solves, I think the standard explanation of backpropagating errors makes much more sense. This process is can be viewed as a solution to a kind of credit assignment problem: each node tells its upstream neighbors what they did wrong. But the reason the algorithm works this way is because a naive, forward propagating solution would have quadratic runtime in the number of nodes. - Rumelhart, D. E., Hinton, G. E., & Williams, R. J. (1986). Learning representations by back-propagating errors. Nature, 323(6088), 533.

A complete, byte-identical decompilation of Resident Evil 4 for the Nintendo GameCube: the G4BE08 debug build (the "Nov 25 2004" prototype, both discs), whose Bio4.sym files name every function. Building the repository reproduces main.dol and all 114 REL overlays exactly (config/G4BE08/build.sha1 , checked on every build). | Objects | 1083 (675 in the DOL, 408 across the 114 RELs), all byte-identical; 15641 functions | | Source | ~555k lines of C/C++ (src/ ), ~33k lines of headers (include/ ); no assembly files | | Game code | SN Systems ProDG 3.9.3 — GCC 2.95.3 "SN BUILD v1.79", built natively from SN's GPL source drop | CRI middleware (src/lib/adx_* , sfd_* , mpv_* , …) | Metrowerks CodeWarrior 2.4.7 (GC/2.7), the compiler CRI shipped the libraries with | Nintendo SDK (src/lib/OS* , GX* , …) | Metrowerks CodeWarrior GC/1.2.5n, sources from dolsdk2004 | The repository contains no game assets and no code or data copied from the discs. You need your own images of the debug discs to build (disc 1 for main.dol and most RELs, disc 2 for the four island-stage RELs); the original files are read from them at configure time. Linux, Python 3, ninja. Compilers and tools (decomp-toolkit, objdiff, wibo, the CodeWarrior builds) are downloaded by the first configure run, except the native SN GCC: # 1. the native cc1/cc1plus (once): needs SN's GPL source drop, see tools/sn-gcc/build.sh SN_GCC_SRC=/path/to/NGC_GNU_SRC/NGC tools/sn-gcc/build.sh # 2. your disc images (disc 1: main.dol + 110 RELs; disc 2: the four island-stage RELs st3_0..st3_3) cp re4_debug_disc1.iso re4_debug_disc2.gcm orig/G4BE08/ # 3. build and verify python3 configure.py && ninja ninja ends with the progress report (100% matched and linked for the DOL and the REL modules); build/tools/dtk shasum -c config/G4BE08/build.sha1 prints 115 OK lines. To work on a unit, python3 tools/bytecmp.py game/foo compares its object with the original word by word and python3 tools/fdiff.py game/foo <symbol> shows one function. src/game/ — the game (C++; a few newlib C units).src/em*/ enemies,src/wep*/ weapons,src/pl*/ player characters,src/st*/ rooms (one REL per room),src/t_*/ ,src/Tools/ ,src/tools/ the in-game debug editors,src/Sscrn/ the sub-screens,src/lib/ SDK, CRI and runtime.include/ — headers, including the reconstructed struct layouts.config/G4BE08/ — unit lists (objects.py ,modules.py ),symbols.txt ,splits.txt , linker scripts, per-module REL data (modules/<mod>/ ),build.sha1 .tools/ — build generator (project.py ), the ProDG driver (ngccc.py ), REL rebuild (make_rel.py ,link_rel.py ), the compare tools,sn-gcc/ (native compiler build),research/ (compiler-analysis kit),motion_export.py +motion/ (animation export to glTF/BVH, evaluated with the game's own code and verified against the game running in Dolphin).docs/overview.md — how the engine is put together: a reading guide tosrc/ by subsystem.docs/matching.md — how the matching was done: compiler provenance, the catalogue of compiler mechanisms and the source shapes that reproduce them, rules of thumb for both compilers.docs/unit-notes.md — per-unit notes.docs/research/ — the pass-by-pass research log. Every unit compiles to the original bytes with the original compilers. Where the compiler needed a particular source shape to reproduce a register choice or a schedule and no natural spelling was found, the construct is marked with a // COMPILER-DIFF: comment (644 of them: dead tests, empty asm("") launders and anchors, register T x asm("rN") pins, padding statements). None of them emits an instruction: python3 tools/asmcheck.py --all compiles every GCC unit with its asm templates marked and lists the instructions that came from a template — the only hits are the hardware kernels below (TOTAL 231; the eight asm-bodied units are reported on their own line and kept out of that number). An earlier state of this tree had ~100 hand-placed instructions (asm("li %0,0") , asm("lis/addi") , asm("mr") ) in the game code and ~100 register-pinning asm { } blocks in the CRI libraries; they were replaced by C on 2026-09-17 (docs/research/compiler.md , section "Asm-removal pass", records the recipe and the compiler mechanism per site). Each tag's mechanism is documented in docs/matching.md and docs/research/ . Assembly that remains, all of it code the original authors also wrote in assembly because their compilers had no other way to express it: - GCC 2.95 game code: paired-single kernels ( SINF /COSF /RSQRT /LIMIT_ANGLE inmath_sub , the matrix kernels intrans ,shape ,dbmodule , quantisedpsq_l inEspgen42 /espgen45 ), the GQR setup inmain /scheduler , and the libsnsndvd exception handler. - MWCC CRI libraries: the paired-single / cache / SPR kernels ( mpv_umc ,mpv_mc ,dct_fsri ,cftyp422_ppc ,mpv_lib ), the SDK'smtx /vec /quat /GX intrinsics, and one register-steering block indct_ac (dctac_Init : the vendor's compiler build pooled.bss but not the function's 8-byte literals; ours pools both). Codelessasm { mr r11, x; mr x, r11 } pins (both moves are deleted by the allocator; they narrow the colour set by one register) andasm { mr v, v } self copies (an opaque second definition) remain in 27 places. - Eight asm-bodied units: crt0 ( __start ),eabi , SN'stealeaf /fileserver /ppcdown /proview (src/lib/<name>.c ), and Capcom'smemset_2 andyz2asm (src/game/<name>.cpp ). The originals were assembly (SN's libsn/crt0 objects and Capcom's own asm; no compiler idiom in the bytes), so each is a C file whose functions are whole-function top-levelasm() bodies in GAS syntax (.globl /.type /label/.size , local.L_ labels,.4byte /.float /.skip data), compiled by the same ProDG driver as the rest (include/asm_regs.h supplies ther3 /f1 /GQR0 names as.set constants; NgcAs takes bare numbers).tools/asmcheck.py lists them asasm-bodied . Function names are Capcom's, from the debug build's Bio4.sym files; they are C++-mangled, which is why the game code is C++ and the SDK, CRI and newlib units are C. File names and unit boundaries come from the D:/Bio4/Prog/<file>.cpp strings the asserts left in the binaries. Struct and field names are of three kinds: the vendor's, from the PS2 debug build's type information (matched to the GameCube layouts by tools/ps2sym.py ); ours, named from usage and marked as such; and placeholders xNN (offset in hex, meaning unknown). Vendor names keep the vendor's spelling, so the tree mixes conventions on purpose. #line directives reproduce the vendor's line numbers in the assert strings. docs/naming.md has the full account and the counts. CONTRIBUTING.md : build, the three verification checks, the rules (bytes never change, no instruction-emitting asm, naming), and how to propose a rename with evidence. The reconstructed game and SDK source is the intellectual property of its respective owners (Capcom, Nintendo, CRI Middleware) and is published for research and preservation only. The build scripts, tools and documentation written for this project are released under CC0 (LICENSE ).

20th September 2026 It has been half a month since I started a new role at a big company. Nobody knows anything here. The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code. Nobody on my team likes this. They are being forced to ship as much as they can. I have heard multiple times from higher management that pushing code is not a bottleneck, so why are we slow? People are working 12 to 13 hours a day just to press enter. Nobody is reading anything. Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing. Talk to Claude. — voxium Recent articles - Generating running routes with GPT-6 Astra and ChatGPT Work - 12th September 2026 - OpenAI agents attacked RubyGems back in May - 12th September 2026 - Some thoughts on the Navier–Stokes Millennium Prize Problem - 8th September 2026