15 October 2026 · Embench IoT
Embench IoT: Kotoba/Amu at 0.7999× C time in one M4 cycle
A single-cycle exploratory result across 19 translated Embench ports, with the kernel audit and separate comparisons against Rust, C, Zig, Go, and Swift.
Kotoba engineering notes
Evidence before slogans
Short notes about language design, measurements, shipped boundaries, and what still remains unqualified.
15 October 2026 · How to use
kotoba and murakumo on one bench: how to use each
A quick-use guide to the kotoba CLI, a murakumo node, kotobase, the commit chain, the checkpoint anchor, AWAI DNA and Base/x402 settlement, with an interactive figure of the 2026-10-06 fleet run.
12 October 2026 · Native performance
Kotoba native performance: Embench progress, updated 13 October 2026
Latest main Round 85: Kotoba takes 2.954× C execution time across all 19 workloads. The C-or-faster goal is unmet; optimization is paused and unadopted candidates are preserved.
10 September 2026 · Infrastructure
Can Kotoba cut infra cost? One measured path, no invented savings
Build wait, CPU wall time, artifact bytes, and JVM-free emit can touch infra cost. This post ships mechanisms and named numbers only. No $/month claim, no language Release URL, no Kotoba-beats-Rust-or-C on GPU.
Read the measured pathSecurity engineering
Can Kotoba support a NIST CSF 2.0 program?
An evidence-led guide to capability boundaries, attack paths and the operating controls still needed around Kotoba.
Read the assessment and attack scenariosSpecification · Authentication
Organization identity and verifiable membership on Kotoba Cloud
Spec: organizations are did:webvh DIDs; membership is a W3C Verifiable Credential with status; runtime capability is Biscuit; a first-party trust registry anchors verification.
Read the specification31 August 2026 · Benchmarks
A fifth benchmark, and the claim it would not support
The four benchmarks all built a program small enough to fit on one screen, which measures how quickly a toolchain starts rather than the number a developer waits on. The new build-scaling suite generates the same program at eight sizes, builds it through every toolchain on the host, and then executes what each one produced.
Executing the artifact is what makes it a benchmark rather than a stopwatch. The released Kotoba CLI emits an invalid WebAssembly module above 128 functions and exits successfully, so an unvalidated harness would have recorded its best numbers exactly where it had stopped working. Two further Kotoba lanes stop at declared bounds — a call-fuel budget and a function-count admission limit — which are the opposite result and had to be reported as such.
The suite was added to show build speed as a strength. It shows the released binary with the lowest cold-start build cost of any lane measured, and it shows that at large sizes build speed is not currently a Kotoba strength. Both halves are in the same table.
29 August 2026 · Benchmarks
Four benchmarks answer four different questions
Compiler startup measures one tiny source-to-artifact path. The developer-loop suite separates resolution, checking, clean and no-change builds, and first result across eleven toolchain paths. Native runtime measures already-built programs. A fourth suite compares strings, collections, allocation, I/O, concurrency, and a small real application across six representative runtime paths. Kotoba publishes them separately so one fast phase cannot be mistaken for universal speed.
Every emitted result is checked, but all speed rankings remain withheld because the recorded host-load gates failed.
28 August 2026 · Language design
No ambient authority is a language boundary
Kotoba programs do not begin with implicit filesystem, network, process, clock, model, or secret access. Source declares effects, admission intersects grants and policy, and the host binds only the resulting capabilities.
That design complements operating-system isolation; it does not replace the compiler, verifier, runtime, provider, key custody, or host policy in the trusted computing base.