Yapin API / 28 October 2026 UTC
5 clients.
One protocol baseline.
Read latency, client lifecycle costs and write workflows across Rust, Node.js and Python. A comparison of recorded client performance, with the data behind every result.
Explore the cohort dataSeparate modes, separate comparisons.
Compare within a mode
Live API calls include network and server behavior. Proxy and replay exercise deterministic local fixtures. The charts never average latency across these environments.
Check coverage and failures
Read matrix coverage depends on the selected run settings. Workflow files and listener readiness are reported where present; missing files and failed steps are kept distinct from successful measurements.
01 / Client comparison
Latency relative to Direct HTTP
Unweighted mean of matched cohort median differences. Each cohort is compared with Direct HTTP in the same benchmark mode, endpoint, lifecycle and retry mode.
Reused clients
Median difference (%)The axis adjusts to the selected mode and lifecycle. Left of zero = lower observed latency. Right of zero = higher observed latency. This is an observed difference, not an isolated measure of framework overhead.
Matched results
| Client | Reused | New |
|---|
Aggregates use available matched cohorts; each cohort has equal weight. Missing client or lifecycle results appear as a dash.
How comparisons are calculatedCompare new and reused client medians Lifecycle difference, in milliseconds
Mean of available within-client, matched new-minus-reused cohort medians. Includes connection setup and run variability; external clients also include process startup. This is not a direct measurement of startup time.
02 / Read endpoints
A closer look at the read suite
Reused clients, no-retry setting. Sample counts are listed in the cohort explorer and chart descriptions. Bars start at zero. P95 uses observation ceil(0.95 × n) and remains sensitive to slow calls, especially for small n.
03 / Write workflows
From individual steps to complete runs
For clients with complete workflows, stacked bars show the sum of per-operation medians, including timed failures. Failed-only or partial workflows are listed without a latency bar. The table separately reports the median sum of operation times for complete, successful workflows. Direct HTTP has no write workflow baseline.
| Client | Complete / attempted | Operation errors | Median sum of times | P95 sum of times |
|---|
Operation sums exclude gaps between calls and do not represent wall-clock workflow duration. Hover or focus a segment for its operation median and sample count.
Listener readiness in the selected mode
Readiness and empty polls are not event-arrival latency. These artifacts are separate from measured read samples and workflow operations.
| Client | Readiness | Elapsed, ms | Events available |
|---|
04 / Cohort data
Inspect the measured results
All 180 cohorts are read requests across live, proxy and replay. The mode filter initially follows the chart selection. Exports follow the current filters and sort order. Expand a row for its source and timing details.
| Details |
|---|
All cohort latency statistics include timed failures. Percent differences use the corresponding median or P95 of the matched Direct HTTP cohort. A dash indicates missing data. † marks unverified live external-adapter comparisons; see the destination caveat in Methodology.
05 / Methodology & limitations
What these measurements can tell you
Timing and comparison
Full-call timing uses a monotonic clock and includes body transfer and client decoding. New external clients include process startup; reused clients retain an adapter process. IPC remains part of external adapter timings.
Percent differences are 100 × (client / baseline − 1), matched by benchmark mode, endpoint, client lifecycle and retry mode. Aggregates are unweighted means of cohort percentages, not pooled request statistics.
Medians and P95 use nearest rank: ceil(p × n) after sorting. The paired timing gap subtracts the recorded response metric from each full-call sample. For native clients the response metric ends at headers; SDK observations can include retries and waits. For external adapters the runner accepts header timing or falls back to adapter elapsed time. These boundaries differ, so the gap cannot isolate DTO decoding or support a direct cross-client comparison.
Scope and uncertainty
These are recorded observations from Benchmark 2026-10-28. Each subdirectory declares its benchmark mode. Proxy and replay are local fixture comparisons, not measurements of live backend latency. Mode names alone do not prove the destination used by every adapter.
Read destinations were validated locally before publication. Public downloads contain aggregate statistics, approved workload settings and classified errors. Private identifiers, machine details, destination URLs and filesystem paths are excluded.
Proxy and replay use the same local HTTP fixture implementation: replay is a repeat, not an independent method. Worker concurrency can influence latency. Read and workflow sample budgets are independent; check sample counts before interpreting P95.
Small differences do not establish a speed advantage; there are no confidence intervals or repeated-run significance estimates. Incomplete workflows cannot support successful transaction timings.
Listener files record readiness and empty-poll behavior only, not event-arrival latency. Missing workflow files are shown as missing, not successful or unsupported. The current yapper.js and yapper.py helpers use fetch and urllib; these results do not establish language-wide or vendored-SDK rankings.
| Mode | Read samples | Workflow files | Recorded OK / total | Run summary |
|---|
Data quality
Success and failure, reconciled
22,500 is a record count, not a count of successful or timed HTTP requests. The untimed errors are retained in the overall success denominator.
| Observation type | Records | OK | Errors |
|---|---|---|---|
| Read cohort samples | 18,900 | 18,899 | 1 |
| Timed workflow operations | 3,600 | 3,598 | 2 |
| Untimed workflow errors | 0 | 0 | 0 |
| Unsupported workflow records | 0 | 0 | 0 |
| All recorded results | 22,500 | 22,497 | 3 |
All-mode accounting: success is 99.99% among timed observations and 99.99% among all read/workflow records. Listener readiness records and cursor state are excluded from these denominators. Per-mode coverage above identifies missing artifacts; an absent run summary does not invalidate verified cohort files.
Source artifacts & declared capabilities
The build validates each cohort’s statistics and success counts against its measured JSONL samples. The report data download includes public artifact identifiers, hashes of published records, aggregate statistics, classified workflow errors and listener readiness. Private runtime metadata and local source paths stay on the benchmark machine. Totals reflect only files present at build time. Capability flags describe the adapters’ declarations, not measured coverage.
| Client | Read | Messages | Resources | Moderation | Events |
|---|