DEV Community: bykamo

One $0.001 Price, Two Settlement Models: x402 on Base vs MPP Sessions on Tempo

bykamo — Sun, 14 Jun 2026 21:51:32 +0000

I charged the same $0.001 on two payment rails and measured every call.

On x402 + Base, each settled call incurred $0.00144 in on-chain gas, more than the payment itself, paid by a facilitator relayer I never see. On Tempo with an MPP session, I deposited once, made 100 calls the chain never recorded individually, and the open-plus-close gas was too small to show up in my balance at all. Same price on the invoice, a different machine underneath.

One thing up front, because it changes how you should read this. I tested one x402 configuration (the exact scheme on Base, settled through Coinbase's CDP facilitator) and one MPP session service on Tempo (the official RPC). This is not a universal benchmark of either ecosystem. It's a measurement of two production payment paths an agent can use today, and most of what I can compare cleanly is the buyer's side: cost and latency per call.

TL;DR

The honest framing isn't "x402 vs Tempo." It's x402 (a standard) vs MPP (a protocol) on Tempo (a chain). x402 standardizes the HTTP 402 handshake. MPP, the Machine Payments Protocol co-authored by Stripe and Tempo, optimizes the settlement rail underneath. They sit at different layers, and MPP can wrap an x402-style handshake.
In the x402 exact scheme I tested, every successful call settled on-chain: 30 calls, 30 transactions, ~$0.00144 gas each (measured), paid by a facilitator relayer. At a $0.001 price, the gas is bigger than the sale, which is why hosted facilitators carry a per-call floor.
The MPP session I tested deposits once and spends against an off-chain voucher. Across 100 calls the chain saw two transactions, open and close, and the gas for that pair was below my balance's resolution ($0.000001). For a high-frequency agent loop, that's the difference that matters.
If you're a non-US builder (I'm in Kyoto), Tempo's headline merchant edge, Stripe USD settlement, is US-only today. That one constraint can flip the recommendation back to x402.

A note on fairness. On the x402 side I built the seller endpoint, a Cloudflare Worker. On the Tempo side I paid an existing seller, the official Tempo RPC service, through the tempo CLI. So per-call buyer cost and latency are a clean comparison. How hard the seller is to build is not, because I never built the Tempo seller.

Architecture

The hinge: x402 puts the payment in the request; an MPP session puts the request inside a deposit. In the exact scheme, an x402 call is one on-chain settlement: my 30 calls produced 30 transactions. An MPP session is two transactions, open and close, regardless of how many calls ride between them; I sent 100 and the chain still recorded two.

How it works

Rail A — x402 (the seller, extracted from the production docolumn worker)

The seller answers 402 with payment requirements, then verifies and settles through Coinbase's CDP facilitator. The whole paid path is about 140 lines. The core is the verify-settle round-trip:

// bench/08-x402-vs-tempo/x402/worker.ts  (Cloudflare Worker)
import { createCdpAuthHeaders } from "@coinbase/x402";

// 1) no payment yet -> 402 with requirements (scheme "exact", USDC on Base, "1000" = $0.001)
if (!xPayment) return make402(env);

// 2) client retried with a signed EIP-3009 payload -> verify, then settle
const verifyRes = await fetch(`${env.FACILITATOR_URL}/verify`, { /* CDP auth + payload */ });
if (!verifyJson.isValid) return make402(env, verifyJson.invalidReason);

const settleRes = await fetch(`${env.FACILITATOR_URL}/settle`, {
  body: JSON.stringify({ /* ... */ waitUntil: "confirmed" }),   // <- waits for the Base tx
});
// returns X-Bench-Verify-Ms / X-Bench-Settle-Ms / X-Bench-Tx so the client can record the breakdown

The client is just x402-fetch. wrapFetchWithPayment(fetch, wallet) catches the 402, signs transferWithAuthorization (EIP-3009), and retries. The wallet only signs. It needs USDC but no ETH, because the facilitator submits the transaction.

Rail B — Tempo / MPP (the buyer, via the official CLI)

I didn't hand-roll a Tempo seller. I paid a real one. The tempo CLI is a curl-compatible client that negotiates MPP automatically:

# bench/08-x402-vs-tempo/tempo/rpc-bench.mjs drives this call N times
tempo request -t -X POST \
  --json '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  https://rpc.mpp.tempo.xyz/

The service advertises intent: session at $0.001/call. The first call opens a session, depositing to the MPP escrow precompile (0x4d50500…0000, "MPP" in ASCII), and every call after rides an off-chain voucher against that deposit. The deposit is dynamic; my 100-call run locked about $1.90, and I got all of it back minus the $0.101 I actually spent. Tempo charges gas in the stablecoin itself; there's no native gas token (the account's native balance is a 0x4242… sentinel).

What it cost

Measured directly: x402 over 30 calls, Tempo over 100 ($0.001/call on both, Base mainnet ETH=$1,667). No extrapolation.

Axis	x402 exact / Base / CDP (N=30)	MPP session / Tempo RPC (N=100)
Seller can safely release the response	settle p50 1,569ms (p95 2,349)	voucher p50 554ms warm (p95 831)
verify (validity check only)	p50 269ms (p95 594)	folded into the voucher
HTTP response (wall)	p50 1,863ms (p95 2,757)	warm p50 554ms; cold/idle first call 3,163ms
On-chain transactions	every call (30 calls = 30 tx)	2 total (open + close), for all 100
Per-call gas	$0.00144 (gasUsed ~86,278, paid by a relayer)	~$0 (open+close gas below $0.000001 in my balance)
Who pays the gas	a facilitator relayer (you hold no ETH)	you, in stablecoin, on open/close
Attempts / failures	30 calls, 0 failed	100 calls completed; 1 cold-start attempt failed (1 of 101 paid attempts)

Three numbers, not one, because "fast" depends on what you mean by done.

verify confirms the payment is valid. In x402 that's quick (p50 269ms), but the funds haven't moved yet.
Seller is covered is the one that matters for billing. In x402 that's settle (p50 1,569ms): USDC has actually moved on-chain and the call is final. In the MPP session it's the voucher (p50 554ms warm): an accepted voucher backed by funds already in escrow, not a per-call on-chain settlement. These are different assurance mechanisms, not just different speeds.
On-chain finality is per-call for x402 (same as settle) and happens once, at close, for the session.

Compared on the same definition (seller is covered), the Tempo session was about 3x faster per call: 554ms vs 1,569ms. The x402 latency is dominated by waitUntil: "confirmed", which makes each call wait for a Base block (settle p50 1,569ms, p95 2,349ms).

On cost, the gap is starker. x402 settles on-chain every call, so the relayer pays ~$0.00144 of gas each time, on top of moving a $0.001 payment. The MPP session paid that gas only twice, at open and close, and even then it was too small to register against my balance. I completed 100 calls, but the cold-start failed once and was retried, so 101 paid vouchers were charged in total: $0.101 in service fees. The unused remainder of the dynamic deposit was refunded on close.

One caveat I won't paper over: I billed myself 30 x402 calls, not 100, and the Tempo "~$0 gas" is a balance-delta measurement, not a per-tx receipt readout. It means the open/close gas is below $0.000001 in my wallet, not provably zero.

What broke

Recorded while wiring both rails. This is the part you can't get from docs.

x402: every call 402'd, and it wasn't the balance or the keys. It was self_send_not_allowed. I'd wired the bench with the payer and the payTo set to the same wallet. The CDP facilitator rejects from == to before it checks balance, so every call failed with a generic 402. The fix was one line: print the 402 body so the invalidReason surfaces, then split the addresses. The deeper lesson is a real property of the rail. A hosted facilitator structurally blocks self-dealing, so you can't quietly settle your own $0.001 against yourself for free.
Tempo: the first paid request died on an "untrusted escrow contract." The CLI rejected the session challenge because the escrow it was handed (0x4d50500…0000) wasn't in its trust list; it wanted 0x33b9010…24f25. That address is the real MPP escrow precompile, and the deposit genuinely lands there, so this wasn't a malicious server. It was a stale CLI extension. The retry auto-updated tempo-request to v0.5.2 and the same call went through. Mainnet-early tooling churn, caught live.
Tempo: the cold first call of a session is slow and can fail. Across 101 paid attempts, exactly one failed: the cold first call, with KeyAlreadyExists in a keychain precompile during gas estimation. It took 3.2s before the retry succeeded, and the other 100 calls went through. The access key was already provisioned, but opening the session tried to register it again. Worth knowing if you script this: budget a retry for the first call, and expect an idle session's next call to run 2–3s before it warms back to ~554ms.

Which rail to build on

The measurements only matter if they change a decision. Here's the framework I'd use, and the short version is: it depends on how often your agent pays.

If your situation is…	Lean	Why
One-shot charges (a webhook, a report, an occasional inference)	x402	per-call settlement is fine; the gas overhead matters less when calls are infrequent or higher-priced
Tens-to-hundreds of small calls in a loop (LLM inference, metered tools, streaming)	MPP session	the session amortizes the chain to ~$0/call and lands at ~554ms
Non-US business, can't use Stripe's US-only stablecoin settlement	x402	Tempo's biggest merchant edge doesn't apply to you
You want multi-chain optionality (Base, Polygon, Arbitrum, World, Solana)	x402	broader chain support today
You're building closer to an agent marketplace than a single endpoint	MPP session	payment QoS and pre-funded sessions fit that shape

The honest Kyoto-builder conclusion: for my setup, where I already run a production x402 worker, x402 was the shorter path to monetize this quarter, and the per-call gas overhead is acceptable at the prices I charge. To bet on the high-frequency agent loop, the MPP session model is genuinely a different machine, and the numbers back it up, but its loudest selling point (Stripe USD settlement) is US-only right now. I measured two production payment paths. Which one fits is a decision about your billing shape and your geography, not about which logo wins.

Appendix — reproduce this

Everything that produced the numbers above. Nothing here is paywalled — the worker, the client, the gas/latency scripts, and a results writeup are in a public gist: https://gist.github.com/bykamodev-web/e66ab462b7c727b60410dea9a5fe52c8

At a glance:

x402   30 calls · 30 Base txs · 0 failed · gas mean $0.00144 · settle p50/p95 1,569/2,349 ms
MPP    100 calls (101 paid attempts, 1 cold-start fail) · 2 Tempo txs · voucher p50/p95 554/831 ms · ~$0 gas

Commands:

# x402 seller = Cloudflare Worker (exact scheme, USDC on Base), client = x402-fetch + viem
npx wrangler dev --port 8787
N=30 node --env-file=.env bench.mjs      # per-call wall / verify / settle
node gas.mjs <tx hashes>                  # gas + from per tx

# Tempo buyer = tempo CLI against the official RPC service (intent=session)
N=100 node rpc-bench.mjs                  # latency percentiles + balance-delta gas accounting

Environment:

Measured 2026-06-14, ETH ≈ $1,667.
x402: exact scheme, USDC on Base mainnet, Coinbase CDP hosted facilitator.
Tempo: mainnet chain 4217, tempo CLI v1.8.2, tempo-request extension v0.5.2, token USDC.e.

x402 ran 30 settlements on Base, all submitted by relayer 0x93f6601151ccb08f333ab4b1cccfb1e188c0be44, gasUsed ~86,278 each (full tx hashes are in the bench output / EXPERIMENT-LOG). Tempo ran one 100-call session whose only on-chain transactions were open and close; the cooperative close receipt is 0x4875a71e7427b1ee2b5d6d553cbdccd446bdd63ab6329203678a980534c296d0 on explore.tempo.xyz. Service spent: $0.101 (101 paid vouchers — 100 calls plus one failed cold-start that still consumed a voucher); the unused remainder of the dynamic deposit was refunded on close.

I'm KAMO, a developer in Kyoto. I write implementation logs: working code, real costs, what broke. No theory I didn't run myself.

Get every log: https://bykamo.substack.com
Reproduce it (free): the bench — worker, client, gas/latency scripts, and a results writeup. Not paywalled.
Kits (in progress): https://ko-fi.com/bykamo
Portfolio: bykamo.dev

I Made 8 Book Trailers for $9.98 (They're Not Perfect, and That's the Point)

bykamo — Sun, 14 Jun 2026 02:20:22 +0000

I had eight short mystery novels and no budget for video. So I built a pipeline: turn each storyboard frame into a 5-second clip with PIKA's image-to-video, then do all the cutting, panning, titling and cross-fades locally with ffmpeg. PIKA gave me 1,500 trial credits. I burned through all of them, topped up twice at $4.99, and shipped eight 17-second trailers. Total cash out of pocket: $9.98. The ffmpeg half cost nothing.

Up front, so nobody feels misled: these trailers are not flawless. Look closely and you'll find a frame where a hand isn't quite right, or a background detail that shimmers. Every one of the eight has a rough spot or two. The point of this post isn't "AI makes perfect video now" — it's the opposite. AI makes flawed video, predictably, in specific places, and the whole game is knowing where it breaks and routing around those spots for $0 instead of burning credits trying to force perfection. That's how eight trailers cost ten dollars instead of a hundred.

See for yourself — here's one of the eight (Book 6, 17 seconds):

[https://youtube.com/shorts/EZp40yhB_rs?si=ADccBnDbspgNGdAQ]

Rough spots and all.

TL;DR

Eight book trailers, end-to-end AI pipeline: image → PIKA image-to-video → local ffmpeg.
The animation prompt is the whole trick: "extremely subtle motion only" — let steam, light and petals move, freeze everything else. The moment a character's hands move, PIKA melts them.
Real cost: 1,500 free trial credits + $9.98 in top-ups. ffmpeg = $0.
Audio: an original score I composed, added with the free OSS editor OpenCut — $0.
They're not perfect. Each trailer has 1–2 visible rough spots. The method is about containing that, not eliminating it.
The honest part is in What broke: melted fingers, a face that turned into a horror shot, and an ffmpeg sample-aspect bug that stretched every tilt clip 2% wide until I caught it.

What this method does and doesn't do

Because the framing matters before you read a single command:

It does: produce watchable, atmospheric 9:16 trailers cheaply and repeatably, with every deterministic decision (timing, framing, text, transitions) under your control in ffmpeg.
It doesn't: make PIKA stop mangling hands, faces, and small props. That limitation is real and this pipeline does not fix it. What it does is give you a $0 escape hatch — animate the still instead of the motion — so a broken shot costs you nothing and never spirals into a re-roll bill.

If you want broadcast-perfect output, this isn't it. If you want eight decent trailers for the price of a sandwich, read on.

Architecture

  novel text (.md) + storyboard (.png)
            │
            ▼   [ image generation — done separately, Codex-driven,
   8 still scenes              one character sheet as the consistency anchor ]
   (941×1672 portrait
    or 1672×941 land.)
            │
            ▼   PIKA: upload_asset → R2 PUT → md5 verify
   generate_video
   (image_to_video, pika 2.2, 1080p, 5s,
    prompt = "extremely subtle motion only")
            │
            ▼   download each clip
   ┌─────────  LOCAL ffmpeg  ─────────┐
   │  Ken Burns (zoompan / crop)       │
   │  normalize SAR (setsar=1)         │
   │  concat 8 clips                   │
   │  burn captions (drawtext ×4)      │
   │  cross-fade to cover (xfade 0.8s) │
   └───────────────────────────────────┘
            │
            ▼
   final .mp4  (≈17–19s, 1080p30, silent)

The hinge is the split: PIKA only animates; it never composes. Every cut, pan, caption and transition is deterministic ffmpeg I can re-run for free. That's what keeps the variable cost near zero — I only pay PIKA for motion, and I pay it once per shot.

Note on the upstream image step (done in ChatGPT, outside the ffmpeg kit): I first define the cast on one character sheet — every recurring character in a single image, which becomes the consistency anchor. Then I ask for a vertical storyboard: eight numbered panels, each with a 9:16 frame, a timecode (0:00–0:02 …), and a scene / action / camera note. Then I have each panel rendered as a still. The storyboard is the spec for everything downstream — framing, order and duration are all decided there. This post picks up where the eight stills exist and need to move.

How it works

One book = 8 clips. PIKA returns 5-second 1080p clips; ffmpeg trims each to 1.8s (the final shot to 2.4s) → a 15.0s body, then a 0.8s cross-fade into the cover for ~17s total.

Step 1 — Animate each still on PIKA

I drive PIKA through its MCP server, not the REST API directly — so the steps below (upload_asset → R2 PUT → md5 verify → generate_video) are MCP tool calls an agent makes on my behalf, which is why the whole thing is scriptable from a chat session. Each still goes in as one image with an image_to_video call (pika 2.2, 1080p).

The per-shot prompt isn't hand-written — it's generated one cut at a time by reading three things together: the storyboard panel (scene / action / camera / on-screen text), the actual still (looked at directly — who's wearing what, what's in frame, what's in their hands), and the story beat from the manuscript (where this moment sits emotionally). Out of that comes a four-part instruction that follows the same template every time:

[what's in the frame, read from the image]
+ [the ONLY things allowed to move: steam / light / petals / water]
+ [what must stay frozen: people still, hands stable, objects unchanging]
+ [one word of tone, from the story beat]

Here's a real one — Book 6, the shot where a note is tucked against a cup:

A held, still moment: a young woman in a yellow cardigan gently
tucks a small folded note against a paper cup among a row of
leaf-latte cups, Aoi watching quietly behind, the cat nearby.
Her hand and the note stay completely still and stable, the
paper unchanging. The ONLY motion is faint steam rising and a
soft flicker of warm lamp light.

Notice the balance: almost every word tells PIKA what not to move. That's the opposite of normal video prompting, and it's deliberate — PIKA's image-to-video gets worse the more motion you ask for, so the prompt's real job is to fence off everything fragile (hands, small props, faces) and leave only steam, light, petals and water free. The negative prompt does the same defensively: deformed hands, extra fingers, melting hand, morphing note, warping paper.

One hard rule: camera moves never go to PIKA. Pans, tilts and zooms — the storyboard's CAMERA column — are added later in ffmpeg (zoompan/crop, Step 2). Ask PIKA to move the camera and it warps the whole composition, so PIKA only ever adds ambient micro-motion in place; every deliberate camera move is a deterministic ffmpeg pass. Same thesis as before — the generative model does the one thing it's good at, ffmpeg does everything that has to be repeatable.

Step 2 — Ken Burns each clip (portrait example)

zoompan gives a clean slow push and, importantly, comes out at SAR 1:1:

ffmpeg -y -i c2.mp4 -t 1.8 -filter_complex \
"[0:v]fps=30,scale=1380:2400,setsar=1,\
zoompan=z='min(zoom+0.0009,1.11)':d=1:\
x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)':s=1080x1920:fps=30[v]" \
-map "[v]" -an -c:v libx264 -pix_fmt yuv420p -r 30 p2.mp4

Mind the quotes. The min(...) expression contains a comma, and inside -filter_complex an unquoted comma is read as a filter separator — zoompan=z=min(zoom+0.0009,1.11) fails with No option name near '1:x='. Single-quote every expression value (z='...', x='...', y='...') and the comma is safe. (I verified this whole sequence end-to-end on the real frames before publishing; the unquoted version genuinely does not run.)

For a tilt-up (river surface → café) I use crop with a time-driven offset — but crop quietly poisons the sample aspect ratio, so it gets re-normalized immediately (see What broke #SAR):

ffmpeg -y -i c1.mp4 -t 1.8 -filter_complex \
"[0:v]fps=30,scale=1380:2400,setsar=1[b];\
[b]crop=1080:1920:(in_w-1080)/2:(ih-1920)*(1-(t/1.8)):1[v]" \
-map "[v]" -an -c:v libx264 -pix_fmt yuv420p -r 30 p1.mp4
ffmpeg -y -i p1.mp4 -vf "setsar=1" -c:v libx264 -pix_fmt yuv420p -r 30 -an p1fix.mp4

Step 3 — Concat the 8 clips

printf "file %s\n" p1.mp4 p2.mp4 p3.mp4 p4.mp4 p5.mp4 p6.mp4 p7.mp4 p8.mp4 > cl.txt
ffmpeg -y -f concat -safe 0 -i cl.txt -vf "setsar=1" \
-c:v libx264 -pix_fmt yuv420p -r 30 -an body.mp4

Step 4 — Burn captions, one pass per line

Stacking multiple drawtext filters in one -vf string kept blowing up in the shell. So each caption is its own pass, daisy-chained — pass 1 reads body.mp4 and writes s1.mp4, pass 2 reads s1.mp4, and so on, four captions = four passes. Each caption's alpha fade window is set to the duration of the cut it sits under, with a hand-rolled fade-in/hold/fade-out:

FONT="/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf"
ffmpeg -y -i body.mp4 -vf \
"drawtext=fontfile=$FONT:text=Some words travel quietly.:\
fontcolor=white:fontsize=46:x=(w-text_w)/2:y=h-460:\
shadowcolor=black@0.8:shadowx=2:shadowy=2:\
alpha='if(lt(t,3.7),0,if(lt(t,4.3),(t-3.7)/0.6,if(lt(t,5.2),1,if(lt(t,5.7),(5.7-t)/0.5,0))))'" \
-c:v libx264 -pix_fmt yuv420p -r 30 -an s2.mp4

Two portability gotchas here: drawtext only exists if your ffmpeg was built --enable-libfreetype (some minimal builds ship without it — check ffmpeg -filters | grep drawtext), and the fontfile path is OS-specific (the DejaVu path above is Linux; on macOS point it at something like /System/Library/Fonts/Supplemental/Georgia.ttf). The alpha='...' value is single-quoted for the same reason as the zoompan expressions — those commas would otherwise split the filter.

Step 5 — Cross-fade into the cover

A portrait cover (1600×2560) is height-fit and center-cropped to fill 9:16 with no black bars, then xfaded over the last 0.8s of the body:

ffmpeg -y -loop 1 -i cover_v.png -t 2.8 -filter_complex \
"scale=-1:1920,setsar=1,crop=1080:1920:(in_w-1080)/2:0,\
zoompan=z='min(zoom+0.0003,1.03)':d=1:x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)':s=1080x1920:fps=30" \
-c:v libx264 -pix_fmt yuv420p -r 30 -an cover_clip.mp4

ffmpeg -y -i body_text.mp4 -i cover_clip.mp4 -filter_complex \
"[0:v]settb=AVTB,fps=30,format=yuv420p,setsar=1[a];\
[1:v]settb=AVTB,fps=30,format=yuv420p,setsar=1[b];\
[a][b]xfade=transition=fade:duration=0.8:offset=14.2[v]" \
-map "[v]" -c:v libx264 -pix_fmt yuv420p -r 30 -an final.mp4

What it cost

PIKA image-to-video: 1,500 free trial credits, fully consumed, then 2 × $4.99 top-ups = $9.98.
ffmpeg (all editing): $0 — runs locally, no per-render charge.
Image generation (upstream): ran on a separate Codex-based workflow; not billed into this number.
Music: $0 cash — every trailer carries an original score I composed myself. No licensing, no library fees. ffmpeg locks the silent video; then I drop the track on in OpenCut, a free open-source editor, and export. So the whole audio layer is $0 too: free tool, own music.

Total cash out of pocket: $9.98 for eight finished trailers. I won't pretend the trial credits were worth literally nothing, but the only money that left my account was the two top-ups.

(One honest gap: PIKA's API response doesn't return a per-job credit charge, so I can't give you a clean cost-per-clip. What I can count is generations — roughly 8–9 video calls per book, because a couple of shots per book got re-rolled or rescued, not animated.)

What broke

This is the part that actually transfers. None of these got fully "solved" — they got contained. That distinction is the whole method.

Moving hands and props melt. The single most frequent failure. Handing over a coin, lifting a spoon to the mouth, slipping a folded note into a cup — fingers morph and the object duplicates or smears. A Gemini pass on the output flagged it severe ("fingers fuse, the note becomes a warped block"). Fix: for that one shot, don't animate it at all — drive the original still through ffmpeg Ken Burns (zoom only). The hand never moves, so it can't break, and it costs zero extra credits. That's the trick that kept the bill at $9.98 instead of a re-roll spiral.
A face eating head-on turns into a horror shot. One book had an elderly woman lifting a spoon while facing the camera; the animated version was genuinely unsettling. Swapped the source frame to a profile and it resolved. Lesson: for an emotional close-up, a side angle is safer than a front angle.
crop silently sets SAR to 46:45 and stretches everything 2% wide. The worst bug because it's invisible until you compare side by side. zoompan clips come out 1:1; crop-based tilt clips don't. Fix: force setsar=1 on every clip and verify the concatenated result with ffprobe (sample_aspect_ratio=1:1) before titling. Never trust the concat to inherit it.
Multiple drawtext filters in one -vf string die in the shell (returncode 234) — the commas and quoting collide. Fix: one caption per ffmpeg pass (four captions = four passes). And any comma inside the text has to be escaped \\, or it's read as a filter separator.
A landscape title card in a 9:16 frame = black bars. Fixed by using the portrait cover, scale=-1:1920 then center-crop, so it fills the frame. Rule I added: always extract the final frame and eyeball it — captions and cover text get clipped in ways the timeline doesn't show.
What I couldn't contain. Being straight about the leftover rough spots: a couple of shots still have a slightly-off hand or a background element that shimmers under motion, even after routing the worst offenders to the still-image escape hatch. At trailer speed (1.8s per shot, lots of cuts) most viewers don't catch them, but they're there. I decided eight watchable trailers today beat zero perfect ones next month. Your call on where that line sits.

Why this matters

There's a lot of "I made a video with AI" content, and almost none of it tells you where the seams are. The seam here is specific and reusable: let the generative model do only the thing it's good at — ambient motion — and move every deterministic decision (timing, framing, text, transitions) into ffmpeg, where it's free and repeatable. That division is why eight trailers cost ten dollars instead of a hundred, and why the failures were containable: when a shot broke, I had a $0 escape hatch (animate the still instead) sitting right there.

It's also just the texture of building things in Kyoto on a shoestring — eight little mystery novels set in a riverside café, given motion by a trial account and a text editor full of ffmpeg one-liners.

Want the scripts?

I packaged the whole thing — the parametrized make_trailer.sh (portrait + landscape), the PIKA shot-by-shot prompt recipes, the SAR-verification script, and a README that lays out which shots to animate vs. route to the $0 still-image escape hatch — into a kit. It assumes the same honest premise as this post: it won't make PIKA flawless, it'll help you ship watchable trailers cheaply and skip the failures I already paid for.

→ ffmpeg Book Trailer Kit on Ko-fi: https://ko-fi.com/s/a637e3c118

I'm KAMO, a developer in Kyoto. I write implementation logs — working code, real costs, what broke.

Get every log: https://bykamo.substack.com
Portfolio: bykamo.dev

I Made My Website Charge AI Crawlers with HTTP 402. In 30 Days, 5,811 Came and 5 Paid.

bykamo — Fri, 12 Jun 2026 06:48:03 +0000

I run a content site, do-and-coffee.com. Like everyone else, it gets scraped by AI crawlers. Instead of blocking them, I did something else: I put a paywall in front of the site that returns HTTP 402 Payment Required to bots, with machine-readable payment instructions. If a crawler pays a cent in USDC, it gets the article. If it doesn't, it gets the 402 and nothing else.

Then I let it run for 30 days and watched. Here's what actually happened — and it's not the number you'd put on a pitch deck.

TL;DR

A Cloudflare Worker sits in front of the site. AI crawlers get 402 + x402 payment requirements; humans and search bots pass through free.
Payment is USDC on Base, $0.01 per article, verified and settled through Coinbase's CDP facilitator.
30-day result: 5,811 crawler requests, 5 paid, 5,806 served a 402. Revenue at $0.01/article ≈ $0.05.
The interesting part isn't the revenue. It's who paid: GPTBot paid 4 times out of 48 requests; ClaudeBot paid once out of 651.

Architecture

do-and-coffee.com/blog/article/*  ─▶  x402 Worker (Cloudflare)
                                       │
   has X-PAYMENT-RESPONSE? ───────────┤─▶ yes ─▶ proxy origin (200)
   KV cache hit (payer:url)? ─────────┤─▶ yes ─▶ proxy origin (200)
   no X-PAYMENT? ─────────────────────┤─▶ 402 + payment requirements
   has X-PAYMENT? ────────────────────┘
        │
        ├─▶ CDP /verify   (is the signed payment valid?)
        ├─▶ CDP /settle   (waitUntil: confirmed — on-chain)
        └─▶ on success: KV.put(payer:url, receipt, ttl 24h) ─▶ proxy origin

The worker speaks the x402 protocol: a 402 response carries an accepts array describing exactly how to pay (scheme exact, network base, asset USDC, amount, payTo wallet). A compliant agent reads that, signs a USDC payment, and retries with an X-PAYMENT header. The worker verifies and settles it through Coinbase's facilitator, then proxies the real article.

How it works

The 402 response

When there's no payment, the worker builds the requirements and returns 402:

function buildPaymentRequirements(resourceUrl: string, env: Env): PaymentRequirements {
  return {
    scheme: "exact",
    network: "base",
    maxAmountRequired: "10000", // 0.01 USDC (6 decimals)
    resource: resourceUrl,
    description: "Access to Do and Coffee premium article content",
    mimeType: "text/html",
    payTo: env.RESOURCE_WALLET_ADDRESS,
    maxTimeoutSeconds: 60,
    asset: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base
    extra: { name: "USD Coin", version: "2" },
  };
}

Verify, then settle

When a payment does arrive, the worker decodes the X-PAYMENT header, then calls the CDP facilitator twice — once to verify the signature is valid, once to settle it on-chain:

const settleRes = await fetch(`${env.FACILITATOR_URL}/settle`, {
  method: "POST",
  headers: { "Content-Type": "application/json", ...settleHeaders },
  body: JSON.stringify({
    x402Version: 1,
    paymentPayload,
    paymentRequirements: reqs,
    waitUntil: "confirmed", // block until the chain confirms
  }),
});

Don't charge twice

A paid payer is cached in Workers KV for 24 hours, keyed by payer:url, so a crawler that re-fetches the same article within a day isn't billed again:

await env.PAID.put(`${settleJson.payer}:${targetUrl}`, receipt, {
  expirationTtl: 86400,
});

What it cost / earned

Worker + KV: within Cloudflare's free tier at this volume — $0.
Facilitator: Coinbase CDP, no per-call fee at this scale.
Revenue over 30 days: 5 payments × $0.01 = ~$0.05 (the dashboard tracks counts, not USD; this is the configured price × paid count).

So: net a few cents. As a business, this is nothing. As a measurement, it's the whole point.

The 30-day numbers

Window: May 14 – June 12. Source: the worker's own crawl-stats dashboard.

	Count
Total crawler requests	5,811
Paid	5
Served 402	5,806

Per crawler:

Crawler	Requests	Paid
Claude-SearchBot	1,536	0
PetalBot	1,502	0
ClaudeBot	651	1
Amzn-SearchBot	444	0
OAI-SearchBot	337	0
GPTBot	48	4
Other (long tail of minor UAs)	1,293	0
Total	5,811	5

Most-hit paths: /blog/article/* (1,633), /robots.txt (1,575), /sitemap.xml (840).

What broke / what I learned

Almost nothing pays. 0.086% of requests resulted in a payment. The overwhelming default behavior when an AI crawler meets a 402 is to leave. If you're imagining passive USDC income from agentic traffic, the live data says: not yet, not at this volume.
The crawlers that can pay still mostly don't. GPTBot paid on 4 of 48 requests (~8%); ClaudeBot on 1 of 651 (~0.15%). Treat exact attributions cautiously — these are user-agent strings, which can be spoofed — but as a first-party observation, the agents presenting OpenAI's GPTBot UA were by far the most likely to actually complete an x402 payment. Everything else (search-indexing bots like Claude-SearchBot, PetalBot, OAI-SearchBot) just hammered /robots.txt and /sitemap.xml and bounced off the 402.
The origin has to trust the paywall. The worker proxies to my real site, so my site needs to know "this request was paid." I had it mint a short-lived HMAC access token (signed {payer, resource, exp}) and pass it as an Authorization: Bearer header, plus spoof a browser User-Agent so the origin returns full HTML instead of its own bot treatment. Without the browser UA, the origin's own anti-bot logic fought the paywall.
Settling synchronously costs latency. waitUntil: "confirmed" blocks the response until Base confirms the transfer. It's the safe choice (you serve content only after the money is real), but it adds seconds to a paid request. For a $0.01 article that's fine; for a high-frequency API it would be the first thing I'd revisit.
URL normalization matters for verify. The resource in the payment requirements has to match exactly on the retry, so I strip operational query params (__x402, id) before composing it. A mismatch there silently fails verification.

Why this matters

There are a lot of essays about the "agentic web" and machines paying machines. There are very few sites actually returning 402 to real crawlers and reading the receipts. This is one of them, and the honest takeaway is: the rails work — verify, settle, USDC on Base, all fine — but the demand side isn't here yet. The number that matters today isn't the $0.05. It's the 5-out-of-5,811, and the fact that one vendor's bot pays 50× more often than another's. That ratio is the thing worth watching as this evolves.

I'll keep it running and report the curve.

I'm KAMO, a developer in Kyoto. I write implementation logs — working code, real costs, what broke.

Get every log: https://bykamo.substack.com
Portfolio: bykamo.dev

I Bought a $100 Hat for $0 — Proving an AI Agent Was Human-Backed with World AgentKit

bykamo — Fri, 12 Jun 2026 05:46:26 +0000

A $100 hat showed up at my door in Kyoto. I paid nothing for it — not for the hat, not for shipping. $0.00.

It wasn't a coupon I found or a sale. The store, humanrequired.shop, only gives that discount to AI agents that can prove a real human is standing behind them. So I made my agent prove it, on-chain, with a zero-knowledge proof. The discount it got back was 100% off. Here's the whole path, because the design held together far better than I expected.

TL;DR

World Foundation's AgentKit lets you prove on-chain that an agent is "human-backed."
humanrequired.shop hands a human-only 100%-off discount to verified agents — once per World ID.
The official Claude Code plugin (worldcoin/agentkit-shopify-demo) ships the whole flow as skills.
Result: one "Human in the Loop" Hat, $100 → $0, shipping included, delivered to Japan.

Architecture

[Claude Code]
   ├─ plugin: agentkit-shopify
   │   ├─ skill: shopify-agent-discount  (SIWE signature → World discount API)
   │   └─ skill: shopify-storefront       (Shopify product JSON → cart URL)
   │
   ├─ Agent Wallet (local Ethereum keypair)
   │   └─ registered in AgentBook (on World Chain) = the human-backed proof
   │
   └─ Shopify (humanrequired.shop)
       └─ /api/verify gate (Worldcoin's verification endpoint)

The key idea: you don't give the agent a World ID. A human delegates the agent's public key on-chain. The private key never leaves the machine.

How it works

Step 1 — Install the plugin

/plugin marketplace add worldcoin/agentkit-shopify-demo
/plugin install agentkit-shopify@worldcoin-agentkit
/reload-plugins

Step 2 — Generate an agent key

uv run --with eth-account python3 -c "from eth_account import Account; print(Account.create().key.hex())" > .agent-key
chmod 600 .agent-key

Check the wallet address:

uv run --with eth-account python3 -c "from eth_account import Account; print(Account.from_key(open('.agent-key').read().strip()).address)"
# => 0xC56A...

Step 3 — Register in AgentBook (the human-backed proof)

In a separate terminal (it shows a QR code):

npx @worldcoin/agentkit-cli register 0xC56A...

Scan the QR in the World App.
Your Orb-verified World ID generates a zero-knowledge proof.
The AgentBook contract on World Chain writes agent_address → human_nullifier.
Worldcoin's relayer covers the gas, so you pay nothing to register.

Step 4 — Call the discount API

get-coupon.py does four things:

Signs a SIWE message (Sign-In with Ethereum, EIP-4361) with the key in .agent-key.
Base64-encodes the signature into an agentkit: HTTP header.
POSTs the product URL to https://discount-app.worldcoin.org/api/verify.
The server checks AgentBook — if the agent maps to a registered human, it returns a discount code.

PRIVATE_KEY=$(cat .agent-key) ./get-coupon.py https://humanrequired.shop/products/human-in-the-loop-hat
# => WORLD-ID-ced1a8fe6682

Step 5 — Build the checkout URL

No special API needed on the Shopify side — the plain product JSON endpoint is enough.

curl -s "https://humanrequired.shop/products/human-in-the-loop-hat.json" | jq '.product.variants[0].id'
# => 46991516106914

Shopify's standard cart permalink finishes it:

https://humanrequired.shop/cart/<variant_id>:<qty>?discount=<code>
https://humanrequired.shop/cart/46991516106914:1?discount=WORLD-ID-ced1a8fe6682

What it cost

The hat: $0.00
Shipping to Kyoto: $0.00
Gas to register on World Chain: $0.00 (Worldcoin's relayer paid it)
Total out of pocket: $0.00

What broke

npx ...register needs its own terminal. It draws a QR code; running it inside Claude Code's Bash mangles the output. Run it in a real terminal.
Don't do a test run. The discount code is derived deterministically from your nullifier hash, so "let me just call it once to see" spends your one real code. I held off on hitting the API until the checkout URL was fully assembled.
Strip query params off the product URL. A trailing ?variant=123 can make the discount API treat it as a different product.
/reload-plugins did nothing in my setup. The skills are just bash scripts under ~/.claude/plugins/marketplaces/worldcoin-agentkit/skills/, so I ran them by hand and the flow still completed.

Why this matters

A few design choices stood out, and they're the reason I bothered writing this down:

The discount code appears to be deterministic. The tail of WORLD-ID-ced1a8fe6682 matched the tail of the nullifier hash from registration (0x2fd8701b...a8fe6682). I can't see the server, but that match strongly suggests the code is derived from the nullifier rather than from a stored counter or random value — which would mean "one human, one code" is enforced cryptographically, not by a database row.
The private key never goes over the wire. Auth is a SIWE signature; the server does ecrecover to get the signer address, then looks up the human link in AgentBook.
The MCP turned out to be unnecessary. The plugin registers a Shopify Storefront MCP, but the shopify-storefront skill just curls Shopify's public product JSON. Easy to miss, and the right call.

I spend a lot of time watching the supplier side of agentic commerce — sites that gate AI traffic. This was the rare chance to be the consumer passing through one of those gates, and the gate's logic is positive: not "block AI," but "let human-backed agents through." Claude Code + plugin + external MCP + a local private key + a ZK proof + an on-chain registry, all meshing cleanly. The hat is the souvenir.

I'm KAMO, a developer in Kyoto. I write implementation logs — working code, real costs, what broke.

Get every log: https://bykamo.substack.com
Portfolio: bykamo.dev