Instrumented build. Every browser API both agents touch is wrapped with high-resolution timestamps, and the log renders on screen — no devtools needed inside a webview.
Attribution comes from the call stack (agent script URL) and falls back to which agents are in flight. Work inside a Worker cannot be patched from the page — worker spans are bounded by new Worker → first message → terminate.
| offset | SEON | Δ vs solo | FP | wall | longest SEON stall |
|---|
If only a narrow band of offsets is slow, that band is the phase of FP's run that holds the contended resource — the single most useful clue for a bug report.
| # | case | wall | FP | start/get | ΔFP | SEON | ΔSEON | timeline | notes |
|---|
| stall @ | length | SEON before | SEON after | concurrent FP / system activity |
|---|
Run a scenario, then pick it here.
| API | actor | calls | total | max | baseline total | baseline max | Δ max |
|---|
Run case 2 (SEON solo) first — it sets the baseline the deltas are measured against.
These call the suspect APIs directly, first alone and then offset ms after Fingerprint's get() starts — the exact condition that breaks case 3. Whichever row blows up is the resource the two agents are fighting over, and it does not depend on SEON internals at all.
| probe | solo | during FP | Δ | Δ% | note |
|---|
| t | Δ | actor | kind | api | ms | detail |
|---|
{ apiKey: "ENBtQILE9DAzCqo0tmlt", region: "us",
endpoints: [ location.origin + "/e265wpihyb/", "https://f.plaid.com" ],
worker: new Worker(...), aggressiveOptimization: true,
extendedSignalCollection: true, modules: [ makeValidationModule() ] }
agent.get({ linkedId })