OmniNode

This design has six parts: tools, skills, a model, hooks, working files and settings. For a new job, you change the parts, not the design. An OmniNode can also hold a sidecar: an internal part, inside the OmniNode, never a separate node or service. The feed maintenance OmniNode has none today.

Here is what they hold in the feed maintenance OmniNode, as of November 3, 13:19 UTC. Tools: github_search, github_latest_release, license_check, word_screen. Skills: label and audit. Model: Muse Spark 1.3 or Muse Wonder 1.0, through the Meta API. Hooks: a spending limit before any model call, and a rule that the maker is not the checker. Working files: spec.json, written for each run. Settings: batch size 10, at most 24 items, 8 allowed licenses, and more.

Read the current spec ↗.

You can place an OmniNode at the entry, to sort requests. You can place it on a branch, or at the end, as one small tool. You can place it beside another node, to audit it, or inside another OmniNode.

OmniNodes join in four ways: one after another, side by side, a backup if the first one fails, and a pair where one works and the other audits. The group is one OmniNode too, so small parts can build large systems. The runtime and its tests cover all of this. The node in production uses one of these shapes: search, reuse check, model label, rule check and store, as a pair with a separate audit.

In a run, it tries the simple ways first. Code, when the answer is known: GitHub search, the license check and the word list. Reuse, when the work is already done and the item's details have not changed: this answers with no model call. A Meta model, when it takes judgment: a Muse model proposes labels for new or changed items. Then a rule tests each label against the item's own text.

This is a real trace, not a savings claim. It is one small feed, and most listings stay the same between runs. Reuse looks at the listing: name, description, license, topics and latest release. Settings also changed after run 1, and run 1 includes a failed call that used all 3,000 of its tokens. It was not a controlled test.

Our wider plain benchmark still shows tokens per correct job rising overall, from 12,297 to 25,628, with Muse Spark 1.3, one run per item on 55 paired items, November 2, 2026. So we make no general savings claim yet.

Across the six runs, a separate worker approved 15 items and rejected 3. The rule refused 2 first tries; both were retried, and one was approved and one rejected, so they are counted above. One model call failed and stays on the record. All six runs, with their audits, cost $0.20 in Meta API spend.

The separate worker uses its own Fabric key and the other Muse model, and it reads the project's listing again. Both workers share one Meta API key.

After each run, a tuner reads the recorded outcomes and changes the spec. It uses Thompson sampling, with a small penalty for cost. It moved the share of Muse Spark 1.3 from 50 percent through 45, 85, 71, 71 and 66 to 64 percent as of November 3, 13:19 UTC, with Muse Wonder 1.0 taking the rest. It raised the batch size from 8 to 10 after a run passed its gate; no run has used 10 in full yet.

This reading rests on 20 outcomes. The models saw different items and graded each other, so it is an early reading, not a model comparison. Feed maintenance is our first OmniNode on its own timer.