Aefinity AI

L10 Mixed Q4 · Agent records and their cost

What receipts cost on a real agent episode

QuestionHow much slower and heavier does an AI agent get when every step carries a verifiable receipt?

Run by us; no unaffiliated reproduction

01Why it matters

Integrity checks are not free. A claim that every step is verifiable means little without its cost next to it.

02Method, step by step

  1. Run one three-step agent episode with receipts on the i5-5200U machine and time it.
  2. Time a plain 72-token decode of the same prompt.
  3. Verify the receipt locally on the i5-5200U machine and through a single-worker daemon on the Celeron N4020.
  4. Re-run on the i5-5200U machine once more to read peak memory and CPU-package energy.

Method as recorded

One agent episode (scenario1-tool-use: 3 steps, 24-token budget per step) on a pinned BitNet-2B artifact triple. one machine is an Intel i5-5200U (AVX2/FMA); the other is a Celeron N4020 (no AVX2/FMA), which verifies only through a gateway daemon with a single background worker (the Celeron N4020 never runs 2B generation). The phone was unreachable and was not tested. Peak memory and energy come from a separate re-run on 2026-09-23 of the identical command on the i5-5200U machine. Run by us.

03Results, exact and sourced

  1. R1On the i5-5200U machine, the 3-step episode with receipts took 44.74 s wall-clock. A plain single-pass 72-token decode of the same prompt took 17.84 s (2.51x). The receipt is 1,599 bytes. Local verification took 40.08 s and passed. The source calls 2.51x an upper bound on receipt cost, not a clean measurement of the receipt code, because the episode loop also re-prefills at every step and the plain decode does not.

    | box1 (aefinity-box) | 44.74s wall (`agent_trace gen`, K=3 N=24) | 17.84s wall (`cis_decode`, N=72, same prompt) | 1599 bytes | 40.08s wall, PASS (local, direct) |

    Verbatim source cis2-spec / 2026-09-22-RECEIPT-OVERHEAD-TABLE.md

  2. R2On the Celeron N4020, the daemon returned ALLOW (PASS) about 12 min 13 s after it was sent to the daemon. This figure is bounded by polling at 20 s intervals and is not a precise wall-clock time. An earlier run of the same scenario shape through the same daemon took about 7.5 min.

    ~12m13s submit-to-ALLOW

    Verbatim source cis2-spec / 2026-09-22-RECEIPT-OVERHEAD-TABLE.md

  3. R3On the i5-5200U machine, a separate 2026-09-23 re-run of the same command (45.94 s elapsed) had a peak resident set size of 1,309,996 KB. Its energy was 369.45 J, measured on the CPU package only (RAPL package-0), over a window of about 46 s. The source says to read this as a lower bound on whole-system energy.

    | box1 (aefinity-box) | 1,309,996 KB | 369.45 J (RAPL package-0 only, ~46s window) |

    Verbatim source cis2-spec / 2026-09-22-RECEIPT-OVERHEAD-TABLE.md

  4. R4The Celeron N4020 timing was not controlled for other queue activity. The daemon serializes all verify work through one worker, so the source reports the two Celeron N4020 timings as observed rather than as a single figure.

    no attempt was made to control for other daemon-queue activity

    Verbatim source cis2-spec / 2026-09-22-RECEIPT-OVERHEAD-TABLE.md

04What it does NOT show

A clean measurement of receipt cost (the two timed runs are different workloads), repeat statistics, wall-power energy, or any phone result (the phone was unreachable).

05Scope and caveats

  • One episode, one run per cell, wall-clock; no repetition statistics.
  • The two timed runs are different workloads: a 3-step tool-use loop that re-prefills at each step, versus a plain 72-token single-pass decode. The source says the 2.51x is an upper bound on receipt cost, not an isolation of the receipt code. A separate earlier single-step (K=1) run is reported in the source as 31.2% overhead, 946 bytes per receipt and 14.865 s verify. That figure is cited in the source only, with no link to its own page.
  • Celeron N4020 timing is polling-bounded (20 s poll interval) and depends on daemon queue activity. Two observations were 12m13s and an earlier ~7.5 min. Celeron N4020 memory and energy and all phone results are n/a (the Celeron N4020 never runs 2B generation, no energy meter on the Celeron N4020, phone unreachable).
  • Peak memory and energy come from a separate re-run (45.94 s, 1,309,996 KB). The original run's peak RSS is inconsistent within the source: the prose says 1,406,336 KB and the source's own note says 1,463,176 KB. The source itself says the prose figure appears to predate the committed log.
  • Energy is CPU package only (RAPL), not wall power.
  • Underlying logs are committed in a repo that is not public; only the summary page is publicly checkable.
  • Run by us; no unaffiliated reproduction.

06Outcome

Mixed

Some parts held, some did not, or we corrected ourselves.

07What we learned

Receipts are not free. In this episode the receipt loop took 2.51x the plain decode, and the source calls that an upper bound. On old hardware, verification took 40 s on the i5-5200U machine and minutes on the Celeron N4020. The cost should be reported next to every integrity claim. These are single runs, not a benchmark.

08Check it yourself

Read the result page. The underlying logs are in a repo that is not public.