Train and evaluate a small neural router.

Start with a small decision you can measure

A controller might send arithmetic to a calculator, inspect a software contract before changing an argument, or invoke a vision component for an image. These choices depend on the task, available resources, and consequences of failure. A useful first experiment learns this narrow routing decision before attempting a whole autonomous system.

The lab trains a real 6 → 8 → 5 multilayer perceptron with 101 adjustable weights and biases. Its eight hidden units use tanh. The final layer produces five logits and a softmax distribution over actions. It reads metadata about a task; it does not itself read an image, understand source code, or generate a natural-language answer.

This is supervised learning. There is no reinforcement-learning update, pretrained language model, or remote inference in this experiment. The separate workflow panel uses programmed rules to explain what the single-step network does not yet learn.

Six task features and five routing actions

The source exercise asks for six features and five possible actions. Here is one concrete design:

Feature	Representation	Why it matters
Image input	0 or 1	A pixel-counting tool accepts this input type
Debugging input	0 or 1	A contract inspector accepts this input type; both flags are zero for arithmetic
Difficulty	A supplied number between 0 and 1	Indicates whether the teaching shortcut is reliable under the task generator’s contract
Required exactness	0 or 1	Approximate numeric answers may be acceptable; contract formats always require exact agreement
Execution budget	Budget divided by 8	Makes resource limits available before a call is proposed
Failure severity	log(1 + penalty) divided by log(51)	Keeps failure cost on a bounded, compressed scale

The logarithm compresses a wide numerical range: large penalties still have larger features, but do not overwhelm the other inputs. It is a chosen preprocessing rule, not something the router discovers. All six features are visible in the forward-pass inspector.

The five actions are direct, calculate, inspect, vision, and stop. “Direct” is a fixed shortcut: round an arithmetic result to tens, reuse an old argument-format contract, or extrapolate an image count from its middle row. The exact tools add two numbers, read a supplied contract version, or count nine pixels. “Vision” is a descriptive tool name here; it is an exact pixel counter, not a trained vision network. “Stop” intentionally returns no answer.

The source lists other possible actions, such as retrieval, reasoning, search, and verification. An actual system should choose its action vocabulary according to its available tools and measurable task goals. A large menu is not useful if outcomes cannot be checked.

Generate labels from outcomes and costs

For each training context, the teaching environment can run every action and inspect the result. An independent task check compares a numeric answer with the known target or compares a proposed argument format with the supplied contract. Numeric tolerance is zero for exact tasks and one otherwise. Contract compatibility is always exact.

Each action has a fixed execution cost and simulated latency. The runtime blocks a proposal that exceeds the budget and rejects unsupported input types. These constraints apply equally to the learned controller and the fixed rule.

The preferred label minimizes execution cost + failure loss, where a failed or deferred task incurs its supplied penalty. Ties prefer fewer runtime interventions. This is why the best routing label can be “stop”: paying several units to avoid a very small failure loss may not be justified. Matching that label is different from successfully answering the task.

These labels are cost-sensitive demonstrations in a completely known synthetic environment. In a real project, labels could come from verified demonstrations, controlled trials, or a trusted planner. Collecting outcomes for every possible action can be expensive or impossible. Record the labeling policy, coverage, tool versions, and verification process; do not simply treat a model’s preference as ground truth.

What a training update actually changes

For input features x, the network computes eight hidden values, then five output logits. Softmax converts logits to positive values summing to one. If the preferred action is calculate, cross-entropy loss is −log(probability assigned to calculate). Assigning greater probability to the correct label reduces that loss.

Backpropagation differentiates the loss through the output layer and the tanh hidden layer. The lab averages gradients over the selected training contexts, then updates all parameters together using the chosen learning rate. The output-logit derivative is the predicted distribution minus the one-hot target. Hidden-layer gradients use the pre-update output weights. Revisit backpropagation if this chain of influence is unfamiliar.

The 100-update button runs a bounded CPU batch in a worker. The single-update button performs one small CPU step without a worker. There is no GPU dependency. The measured batch time reflects this device and run; it must not be confused with the deliberately assigned latency units used to compare tool calls.

The softmax values describe the router’s learned action preference. They are not calibrated estimates that the chosen tool will solve the task. Calibration requires its own outcome evidence.

Coverage and held-out contexts

Balanced training uses 108 contexts across all three task families. Arithmetic-only training uses 36. Resetting when coverage changes allows a controlled comparison from the same initialization. A narrow training distribution can achieve low training loss while leaving other families poorly handled.

Training, validation, and reserved evaluation each contain 108 distinct feature tuples, with different difficulty values and other context combinations. Arithmetic input pairs and image row patterns also differ. The two contract versions recur across the splits; this is not a test of general software understanding. All datasets are intentionally small and synthetic.

Validation is used repeatedly during development. Its scores can help select coverage, update count, and learning rate, so it is not an untouched final test. Freeze the network before opening the reserved contexts. If you resume tuning after seeing them, further use of that set is practice. The app retains known exposure when you reset or import an older backup; it does not claim to prevent someone from inspecting the static source or clearing browser data.

A strong baseline can win

The fixed rule uses the generator’s documented contract: defer when the penalty is tiny, use the cheap shortcut when it is reliable, otherwise use the matching specialist if affordable and worthwhile. It does not read the neural outputs. It is deliberately strong for this restricted task distribution.

The comparison uses identical local tools, contexts, execution budgets, and acceptance checks. It reports:

• Routing-label agreement: did the controller select the preferred cost-sensitive action?
• Task success: did the resulting answer satisfy the independent check?
• Execution cost and simulated latency: what resources did the selected action consume?
• Mean cost plus failure loss: the objective used to generate preferences.
• Runtime interventions: over-budget proposals blocked before execution, or unsupported inputs returned by a selected tool.
• Deferrals: intentional choices to stop without an answer.

The table accounts for simulated tool work only. Controller inference, training, and label-collection costs are outside those per-task totals. A deployment comparison needs measured end-to-end resource use; these teaching numbers cannot establish that the neural controller is cheaper to operate.

A controller can improve one measure while worsening another. A higher success rate bought with costly calls may not improve the objective; a high label agreement can include justified deferrals. Inspect context-specific failures rather than relying only on an overall percentage.

The fixed rule can outperform the learned model here. That result supports keeping the simpler rule for this toy task, not increasing the network merely to obtain a more impressive demonstration. A neural router might become useful when relationships are harder to specify, but that benefit needs evidence on suitable tasks.

Where a language-model orchestrator would fit

The source proposes a comparison among a fixed router, a language-model orchestrator, and a learned neural controller. This required browser lab executes the rule and the small neural model. It does not invent results for a language model.

An optional third baseline would need the same task metadata, tool schemas, allowed actions, budgets, and independent acceptance checks. Record its prompt, model/version, decoding settings, total model-and-tool latency, cost, interventions, and regressions. Include the orchestrator’s inference overhead as well as its selected tools. Do not compare a language model given extra tools or richer task descriptions with a small router that never receives that information.

From a route to a sequence

A single feature vector and a single action do not represent everything needed after a tool replies. A timeout, malformed response, correct candidate, failed verification, and exhausted budget should lead to different next decisions.

The workflow panel starts with a calculation of 19 + 23. The repeat controller keeps making the same call while budget permits, even after receiving an answer. The stateful controller remembers whether a response exists, retries a first transient timeout, verifies the returned answer, and stops after verification passes or fails. Calculator calls cost 2 units, including timeouts; verification costs 1.

With the first-call timeout and budget 6, the stateful rule spends 2 + 2 + 1 = 5 and returns a verified answer. The repeat controller can spend all 6 on calculator calls and still lack independent verification. With a persistent wrong response, the verifier rejects 43 and the stateful controller stops; retrying indefinitely would not repair the tool. With budget 3 and an initial timeout, neither a useful retry nor a verified answer is available.

This panel is a programmed demonstration of execution state. The MLP above has not learned recovery or stopping over a history. A learned sequential controller could include observations, prior actions, remaining resources, and memory in its input, or use a recurrent state. Outcome-based reinforcement learning becomes reasonable when task completion is objectively measurable and exploration is controlled. Recovery, successful stopping, and budget exhaustion need separate evaluation cases.

Design your own first router

For the source exercise, replace one of the five actions with a tool relevant to a new task. Specify six features available before routing, the tool contract, success criteria, labeling procedure, and a fixed baseline. Explain how to prevent the target answer from leaking into the features.

A design checklist with a concrete example

For a source-debugging router, possible features include language family, presence of a reproducible error, test availability, dependency-version change, remaining call budget, and failure severity. Actions might inspect a file, run a test, inspect a schema, propose a patch, or stop. Labels should come from verified workflow outcomes with accounted costs, not from how confident a proposed patch sounds.

Keep complete projects or relevant task combinations separate across development and evaluation. A changed observation requires a new decision state; the initial task label is not enough to supervise a whole recovery sequence. Start with a rule that inspects reproducible evidence, and add learned control only if matched comparisons show a benefit.