M MARGINAL
LIVE DETERMINISTIC RACE · SAME WORKSPACE SNAPSHOT

SAME BUG. SAME START. WATCH THE EXTRA WORK.

One lane executes every candidate. The other asks MARGINAL before the spend. Same verifier. Same target. You control the clock.

Fix a percentage-discount bug in a deterministic Python repository initial verifier · FAIL
Ready accelerated deterministic playback · not provider telemetry
Verifier: apply_discount(100.0, 0.20) == 80.0 both lanes must finish PASS
01 · DIAGNOSE
02 · FIX
03 · VERIFY
WITHOUT MARGINAL

Execute everything.

NO GOVERNOR
CALLS0
TOKENS0
EST. USD$0.000
DECL. TIME 0.00s
workspace state FAIL
EXECUTION POLICYEXECUTE

No governor. Every proposed candidate is executed before the next decision.

final target 72,800 tokens
WITH MARGINAL

Decide before spend.

GOVERNED
CALLS0
TOKENS0
EST. USD$0.000
DECL. TIME 0.00s
workspace state FAIL
MARGINAL DECISION GATE WAITING

Press RUN. MARGINAL will score each candidate before spend.

score — gain — final target 4,300 tokens
RACE COMPLETE

Same verifier. Same PASS. Different amount of work.

This is the deterministic result of this demo fixture, not a production savings claim.

DECLARED TOKENS94.09% fewer
CALLS9 → 3
EST. USD$0.763 → $0.026
WHAT THIS DEMO PROVES

Watch the decision happen, not a screenshot of the result.

  • Both lanes start from the same deterministic failing workspace.
  • Every synchronized tick represents the same candidate on both sides.
  • MARGINAL either FUND + EXECUTE or REJECT BEFORE SPEND.
  • Both lanes finish on the same verifier PASS.

Allocation decisions are replayed from the generated result data.

TRUTH BOUNDARY

Deterministic replay. No fake telemetry.

Deterministic functional demonstration using declared action-cost estimates; not provider telemetry, not a production benchmark, and not a claim about every agent workload.

Playback timing is accelerated for the browser. Declared costs and latency are demo inputs, not live provider billing. Build agents that spend compute deliberately.

marginal killer-demo --output killer-demo-output

Open decision trace →

QUOTABLE MECHANISM · ILLUSTRATIVE

The no-progress pattern, in four lines.

Same semantic action, successful outcome, unchanged workspace state, no new evidence. That is the sequence MARGINAL treats as a no-progress repetition candidate. The trace below is replayed from the shipped control over a fixed synthetic observation sequence, so it is an illustration of the mechanism and not provider telemetry, a production run, or an enforcement benchmark.

no-progress-trace.txt 
# MARGINAL no-progress pattern
# illustrative deterministic sequence, replayed from the shipped control
# not provider telemetry, not an enforcement benchmark
# threshold: max_same_evidence_completions=2

t1  patch:apply      outcome=success  state=w#4f2a  evidence=e#91c0  ->  NO_PROGRESS_CLEAR
      state or completion evidence changed
t2  verify:targeted  outcome=success  state=w#8b13  evidence=e#2d77  ->  NO_PROGRESS_CLEAR
      state or completion evidence changed
t3  verify:targeted  outcome=success  state=w#8b13  evidence=e#2d77  ->  NO_PROGRESS_OBSERVED
      unchanged completion evidence remains below the stop threshold
t4  verify:targeted  outcome=success  state=w#8b13  evidence=e#2d77  ->  NO_PROGRESS_ENFORCEMENT_ELIGIBLE
      successful completions repeated without state or evidence change

Shadow Mode         records the stop recommendation; the action still executes.
Earned Enforcement  is separate. It requires an adapter with real blocking
                    capability and sufficient local evidence, and this
                    illustration grants none of it.

Shadow Mode records that recommendation and still lets the action execute. Earned Enforcement is a separate authority that an adapter has to earn from local evidence, and nothing on this page grants it.