CKE's audio work is beginning to expand beyond Whisper. NVIDIA's Parakeet is now transcribing my complete presentation on an Intel central processing unit (CPU) with no graphics processing unit (GPU), and Cohere Transcribe is doing the same through a different FastConformer circuit. That is useful, but it is also where I need to be careful not to turn successful fixtures into a broad audio-platform claim.

C-Kernel-Engine (CKE) can already run Whisper as part of my practical video workflow. The exact workload in this article is my published 42-minute kernel-engineering presentation, so readers can watch the source recording and judge whether the resulting transcript follows what I actually explained. That workload exposed compiler, audio-tail, threading, and worker-lifecycle problems that were then fixed and retained as regression evidence. Pull request (PR) #504 brought NVIDIA's Parakeet token-and-duration transducer (TDT) 0.6B v3 through its first exact native-kernel trajectory. PR #507 then pushed the same model through my five-minute regression fixture and complete 42-minute recording. PR #508 added a complete short-audio Cohere Transcribe path, and PR #510 has now extended it across the complete recording with text and SubRip subtitle (SRT) output.

This is meaningful because Parakeet is not simply another Whisper checkpoint. It brings a FastConformer encoder, a long short-term memory (LSTM) prediction network, a joint network, and a TDT decoder into CKE. It forces the engine to compose a different family of audio kernels. The long run now completes, but it is not yet competitive with Whisper on this workload, and Parakeet still uses Python orchestration around native kernels rather than a fully generated CKE circuit. Multilingual quality, concurrent sessions, generated-circuit ownership, and speaker diarization remain open.

The Audio Stack Now Has Three Different Boundaries

The first boundary is usable Whisper transcription. CKE's generated Whisper path is already useful enough to process my own recording, produce timestamped text, support editing, and retain a real five-minute nightly regression fixture.

The second boundary is bounded Parakeet transcription. CKE converts the pinned Parakeet safetensors checkpoint into its versioned BUMPWGT5 weight-bundle format, reproduces the short reference trajectory, and now processes deterministic five-minute and 42-minute inputs without importing PyTorch or Transformers during inference.

The third boundary is bounded Cohere Transcribe long audio. CKE converts all 2,104 expected tensors, runs its 48-layer FastConformer encoder and eight-layer cross-attention decoder, imports a pinned voice activity detection (VAD) speech schedule, emits monotonic dynamic time warping (DTW) timestamps, and produces deterministic text and SRT across the complete 42:22 recording. VAD decides which spans contain speech. DTW aligns emitted tokens with positions in the audio. The VAD itself remains external, and timestamp accuracy still needs an independent forced-alignment oracle.

These distinctions matter. A runtime can have strong component-level evidence for a model family without having a complete user-facing transcription command. CKE should report both states rather than compressing them into one compatibility badge.

What Parakeet Added To CKE

Whisper gave CKE a log-Mel frontend, transformer encoder, autoregressive decoder, cross-attention, timestamps, and long-form orchestration. Parakeet reuses some of that numerical foundation but requires a substantially different circuit.

The pinned Parakeet model has a 24-layer FastConformer encoder with width 1,024, a two-layer LSTM prediction network with width 640, and a joint head that emits 8,193 token logits plus five duration logits. Its duration model can advance by zero through four encoder frames, which is different from decoding one ordinary text token at every step.

The bring-up required CKE contracts and providers for grouped channel-major convolution, inference BatchNorm, relative sinusoidal position values, Conformer relative attention, and an LSTM step. It also required explicit handling for the TDT token-duration state machine and the model's Metaspace byte-pair encoding (BPE) tokenizer.

Readers who want to follow that mathematics below the model name can start with CKE's audio-kernel deep dive for waveform-to-log-Mel preprocessing, Conv1D subsampling, attention, and the encoder-to-decoder cross-attention bridge. The Parakeet TDT operation and evidence page then maps the FastConformer, LSTM, joint network, and token-duration decoder to their concrete providers and retained fixtures. These pages separate a reusable kernel from the model circuit that orders and dimensions it.

The source checkpoint contains 723 tensors. CKE maps 699 inference tensors and explicitly excludes 24 BatchNorm training counters. That inventory is part of the evidence: an unexplained tensor should not disappear simply because the final sentence looks plausible.

What The Short Fixture Proves

At CKE commit 909a2c164, the retained 7.435-second LibriSpeech fixture produced the same 50 token IDs and the same 50 duration decisions as the pinned Transformers 32-bit floating-point (FP32) reference. The recorded warm Ryzen run spent 0.069 seconds in the frontend and 1.027 seconds in the encoder.

The transcript was:

Well, I don't wish to see it any more, observed Phoebe, turning away her eyes. It is certainly very like the old portrait.

This proves that the converted weights, frontend, FastConformer encoder, prediction network, joint network, duration decisions, and tokenizer can form one coherent native trajectory. It does not prove arbitrary long audio, silence handling, multilingual quality, streaming, or diarization.

I also rebuilt the native libraries and repeated this fixture after pulling current main at commit 107fc0740. It passed every retained frontend, encoder, source-consumption, token, duration, transcript, timestamp, and decoder-consumption check in 1.97 seconds, a real-time factor (RTF) of 0.265. RTF is processing time divided by audio duration, so values below 1.0 are faster than real-time playback. The report marked the checkout dirty because the Ryzen workspace already contained unrelated profiling files and a modified llama.cpp submodule, so this is a current-head smoke confirmation rather than the clean provenance artifact used for certification.

python version/v8/scripts/run_parakeet_native_v8.py \
  --model .ck_build/parakeet-tdt-0.6b-v3 \
  --audio version/v8/test_assets/parakeet_tdt_0_6b_v3/2086-149220-0033.wav \
  --fixture docs/notes/artifacts/parakeet_tdt_0_6b_v3_2086-149220-0033_fp32.npz \
  --engine build/libckernel_engine.so \
  --audio-lib build/libckernel_audio.so \
  --decode \
  --output .ck_build/parakeet-tdt-0.6b-v3/native-e2e.json

The complete acquisition, conversion, and reproduction commands are in the CKE Parakeet runbook.

For ordinary use, PR #507 also connects Parakeet to CKE's shared audio entry point:

version/v8/scripts/cks-v8-run audio \
  hf://nvidia/parakeet-tdt-0.6b-v3 \
  --wav recording.wav \
  --output build/parakeet-transcript.json \
  --resume

The front door pins the model revision, creates the FP32 BUMP bundle, builds the required native libraries, and selects bounded long-audio execution. --resume may reuse only completed windows recorded by the output report. The dedicated native runner remains valuable for exact short-fixture diagnosis.

The Five-Minute Result: It Works, But Whisper Is Better Today

The retained fixture contains exactly 300 seconds and 4,800,000 mono samples at 16 kHz. Its SHA-256 is cca3c7d...d1a23ab. A manually curated 690-word transcript makes this a real quality gate rather than a comparison against an older model output.

WER means word error rate. It is calculated as substitutions plus deleted words plus inserted words, divided by the number of words in a manually corrected reference transcript. Lower is better. A WER of 5.65% means the transcript required about 5.65 word-level edits for every 100 reference words. Peak RSS means peak resident set size: the largest amount of physical memory attributed to the process during the measurement.

On this one English recording, Whisper Base was both more accurate and dramatically faster. Parakeet full attention took slightly longer than the recording itself. The bounded overlapping-window path processed five minutes in 3:51, improved WER by 3.18 percentage points relative to the single full-attention pass, and ran about 1.30 times faster than real time. It still remained slower and less accurate than Whisper Base.

The comparison is not perfectly symmetrical. Whisper's default persistent-worker mode failed before inference with a dynamic-module pickling error, so the retained Whisper result used its supported per-window fallback. That failure should be fixed, but it did not prevent the matched Whisper transcription from completing. Parakeet used Python orchestration over native CKE kernels. The data therefore answers which tested path worked better for this fixture; it does not isolate model architecture from runtime maturity.

Parakeet's two five-minute full-attention runs produced identical token IDs, duration decisions, transcript text, and 1,296 timestamps. Two chunked runs produced the same 700-word selected trajectory. That repeatability matters even when the performance is not yet good.

How The 42-Minute Path Works

My complete source is a 2,542-second mono 16 kHz pulse-code modulation Waveform Audio File Format (PCM WAV) recording containing 40,672,000 frames. Instead of constructing one unbounded attention sequence, CKE uses seventeen 180-second full-attention windows with 30 seconds of overlap.

Encoder and decoder state reset for every window. In each overlap, a word belongs to the window whose ownership region contains the word timestamp's midpoint. Timestamp offsets are then moved back into the recording's global timeline. This is deterministic chunk reconciliation, not Parakeet local attention.

The Ryzen 9 9950X3D completed all seventeen windows in 2,154.18 seconds, or 35 minutes 54 seconds. The RTF was 0.847, approximately 1.18 times real time. The report retained 7,225 selected words, finite outputs, monotonic word timestamps, and exact coverage from 0.0 through 2,542.0 seconds. A resume replay completed without rerunning finished windows and left the selected-word trajectory unchanged.

No full-track WER is claimed because the 42-minute recording does not have a completely aligned human reference transcript. This run proves bounded execution, source coverage, resumability, finite output, and timestamp ordering. It does not independently prove every word.

The Full 42-Minute CPU Comparison

I reran Whisper Base after the Parakeet measurement to make sure the earlier 2:18.73 result had not quietly regressed. On the same P3 test node, an Intel Core i7-14700T with 20 physical cores, the same 42:22 WAV, and the current CKE source, Whisper completed in 2:24.24. It produced the exact same transcript and exact same 9,870-token trajectory as the retained PR #482 run. The 5.51-second difference is 3.97%, which is ordinary run variation rather than evidence of a regression.

Using the fresh number, Parakeet is currently 14.79 times slower than Whisper on this recording. That does not mean the Parakeet model is inherently 14.79 times slower. It means CKE's current Parakeet path is far less mature than its Whisper path.

There is also a memory-reporting inconsistency to fix before publication. PR #507 and the generated documentation state 3.29 GiB peak RSS, while both the retained full report and compact certification currently contain 138,936,320 bytes. The likely risk is that resume replay replaced a full-run process maximum with the lightweight resumed process value. Until the evidence generator preserves the original aggregate peak correctly, I am withholding the 42-minute memory claim. A green certification should not require readers to guess which number is authoritative.

Why NVIDIA Calls Parakeet High-Throughput

NVIDIA's model card describes Parakeet TDT 0.6B v3 as a high-throughput 600-million-parameter model. It also says the model and software are designed for NVIDIA GPU-accelerated systems. Its long-audio capacity statement names an A100 80 GB GPU: up to 24 minutes with full attention or three hours with local attention. That is not a CPU throughput promise and the model card does not provide an apples-to-apples CKE benchmark.

CKE currently uses Python orchestration around native CPU kernels, reset-per-window full attention, and overlap reconciliation. It does not yet use Parakeet's local-attention path or a fully generated CKE circuit. The checked-in ownership inventory still lists three open model/layout operations and three open runtime/planning boundaries, including NumPy transposes and copies, mask fills, Python TDT state progression, request-scoped state allocation, and planner ownership. The measured P3 result of 35:33 and Ryzen result of 35:54 for 42:22 of audio therefore describe the maturity of this CKE implementation, not the speed ceiling of Parakeet's architecture.

The P3 stage timings identify the immediate target precisely: frontend processing took 38.09 seconds, FastConformer encoding took 2,025.22 seconds, and TDT decoding took 69.06 seconds. The encoder consumed 94.9% of total runtime. The process averaged only 8.58 CPU-core equivalents on a 20-physical-core machine, while Whisper averaged 11.13. Parakeet is therefore slow mainly because its current encoder performs expensive full-attention, convolution, and layout work without sustaining the available CPU parallelism. Python orchestration matters, but optimizing the 3.2% decoder or 1.8% frontend first cannot close a 14.79-times end-to-end gap.

The Intel and AMD Parakeet runs produced the exact same 7,225 selected words, transcript hash, and timestamped word trajectory. That is an important positive result: the slow path is deterministic across two CPU vendors. CKE can now profile and optimize it while requiring every change to preserve that retained output, rather than trading correctness for an unexplained speedup.

Can I Actually Use The Parakeet Result To Edit A Video?

Yes, as a review aid rather than an automatic editor. I recovered the retained full report and converted its 7,225 timestamped words into 741 SubRip/Web Video Text Tracks (SRT/VTT) subtitle cues, 145 filler candidates, and 77 silence candidates longer than 750 milliseconds. The transcript begins at 1.52 seconds and its final word ends at 2,536.96 seconds, so it covers the spoken presentation rather than producing only an aggregate pass result.

The transcript is coherent from the introduction through the final discussion of backpropagation. It follows the presentation's main order: activation kernels, GEMM and GEMV, normalization, softmax, RoPE, quantization, attention, recurrent state, CPU execution, model composition, and training. It is not publication-ready without review. For example, Parakeet rendered some technical terms as reluct, CLU, and Swigloo. Whisper also made domain mistakes such as activation colonels and swigloo. Both need a technical glossary or human correction pass.

After lowercase and punctuation normalization, the complete Parakeet and Whisper transcripts have 91.25% sequence similarity. If Whisper is temporarily treated as a comparison transcript, their word-edit disagreement is 12.02%. That is not a true accuracy score because Whisper is another model output, not a human transcript. It does show that two different CKE audio paths recovered broadly the same 42-minute talk.

A literal comparison against the Reveal.js notes is much weaker and should not be reported as WER. The prepared notes contain roughly 4,400 normalized words, while I spoke more than 7,000. I added explanations, repeated ideas, corrected myself, and went into an unscripted closing discussion. The useful notes test is therefore topic and ordering coverage, not verbatim agreement.

Parakeet also proposed more verbal-disfluency markers. Its full transcript contains 24 instances rendered as um, 19 as uh, and 80 as you know; the Whisper transcript contains no exact um or uh tokens and 43 instances of you know. This does not prove that Parakeet heard the fillers correctly. A hesitation, clipped syllable, pronunciation, noise, or misrecognized technical term could become um or uh, while Whisper may suppress the same sound. These timestamps are therefore ASR-proposed review markers that must be checked against the original audio, not automatic cuts or an accuracy advantage. A pause may also exist because a Reveal.js animation is playing.

How Whisper And Parakeet Should Be Compared

Wall time alone will not tell us which transcription path is more useful. The comparison should use the same normalized samples and report at least:

• Complete source-frame consumption and final audio timestamp.
• Wall time, real-time factor, stage timing, average process CPU, peak RSS, and page faults.
• Word error rate on a manually curated excerpt.
• Technical-term accuracy for kernel, GEMV, SwiGLU, RMSNorm, CKE, AVX-512, and model names.
• Missing, duplicated, or hallucinated phrases around silence and chunk boundaries.
• Punctuation, capitalization, segment timing, and word timing where supported.
• Determinism across repeated runs under the same artifact and execution contract.

The comparison between my prepared speaker notes and my final transcript can measure topic or ordered-word coverage, but it is not WER because I do not read every presentation verbatim. A publishable WER number requires a human-curated transcript of what I actually said.

The five-minute reference contains 690 words. Whisper Base made 39 word edits, or 5.65% WER. Parakeet's one large full-attention pass made 72, or 10.43%. Parakeet's overlapping-window path made 50, or 7.25%. In plain English, all three recovered most of the talk, Whisper was the cleanest draft, and chunking made the current Parakeet path substantially better than sending all five minutes through one attention sequence.

Those figures describe only this microphone, speaker, subject, and runtime configuration. They do not prove that Whisper is universally more accurate than Parakeet. A broader comparison needs held-out recordings with clean narration, room noise, technical vocabulary, silence, music bleed, accents, and multiple speakers.

The retained Parakeet term audit also explains why human review still matters for my videos. It recognized kernel, general matrix multiplication (GEMM), and rotary positional embedding (RoPE) exactly where they appeared in the reference, but it missed the exact forms of CKE, the SwiGLU gated activation, softmax, and PyTorch. General matrix-vector multiplication (GEMV), root mean square normalization (RMSNorm), and the AVX-512 CPU vector-instruction family were not present in this particular reference excerpt, so the report correctly records them as not applicable instead of treating them as passes. A project glossary may help post-processing, but it must correct terminology without inventing speech.

Diarization Is A Separate Problem

Automatic speech recognition (ASR) asks, what was spoken? Speaker diarization asks, who spoke when? NVIDIA's NeMo diarization documentation keeps that distinction explicit.

NeMo describes two broad designs. An end-to-end system such as Sortformer accepts audio and predicts speaker activity over time. A cascaded system combines voice activity detection, speaker embeddings, clustering, and optionally target-speaker VAD. The end-to-end path can be easier to optimize and deploy. The cascaded path can be less constrained by speaker count and session length, but it has more independent boundaries to validate.

CKE should not attach a speaker label to ASR text until both timelines have their own evidence. A sensible first contract is a list of speaker segments containing start time, end time, anonymous speaker identifier, confidence, and overlap state. The ASR result can then be aligned with those segments without pretending the transcriber itself identified the speaker.

My 42-minute presentation is mostly one microphone and one speaker. It can prove that a diarizer does not invent constant speaker changes, but it cannot certify multi-speaker discrimination. We need an independently licensed fixture containing at least two speakers, turn-taking, interruptions, overlap, silence, and different microphone conditions. NeMo can initially serve as the independent oracle while CKE develops its own bounded providers and timeline comparison.

Where Cohere Transcribe Actually Stands

Cohere Transcribe 03-2026 is a two-billion-parameter encoder-decoder speech model with a 48-layer FastConformer encoder and an eight-layer cross-attention decoder. A FastConformer is the part that turns a long sequence of audio features into a shorter sequence of context-aware audio representations. It combines subsampling, feed-forward transformations, attention, convolution, normalization, activations, and residual connections. It is an encoder, not a complete transcription system; a decoder and tokenizer still have to turn those representations into words.

Parakeet already forced CKE to implement several of those operation families. Cohere is now a concrete reuse test rather than only a proposal. Its declared circuit reuses the audio frontend, convolution, normalization, activation, relative-attention, residual, dense, and argmax foundations while adding its own 48-layer ordering, tensor contracts, tokenizer, causal decoder state, and encoder-decoder cross-attention path. Parakeet has 24 encoder layers followed by an LSTM prediction network and token-duration transducer head; Cohere has 48 encoder layers and a materially different cross-attention decoder.

The latest CKE documentation now makes this stack visible from two directions. The Parakeet TDT page shows the 24-layer FastConformer, LSTM prediction network, joint head, TDT state machine, host-math ownership, and exact fixture boundaries. The Cohere kernel-family page expands the seven FP32 Conformer frontend providers and the native 48-layer encoder to eight-layer cross-attention decoder path. Together they show what was reused and where Cohere still required its own circuit, tensor inventory, decoder state, and evidence.

At the kernel level, the important pieces are not branded “Parakeet kernels” or “Cohere kernels.” They include log-Mel preprocessing, channel-major grouped convolution, inference BatchNorm, relative sinusoidal positions, Conformer relative attention, scaled residual addition, LSTM state updates, causal attention, encoder-decoder cross-attention, and token selection. The CKE kernel catalogue records those providers, while the model and kernel evidence matrix shows which model families currently exercise them.

CKE's model contract already describes a complete expected inventory of 2,104 tensors: 24 global tensors, 39 required suffixes for each of 48 encoder layers, and 26 required suffixes for each of eight decoder layers. The converter fails closed when a tensor is missing, undeclared, or when required layer-count metadata is absent.

The independent CrispASR lane retains 51 accepted comparison checkpoints around the Mel frontend, all 48 Conformer block outputs, final encoder boundaries, and decoder attention. The merged certificate reports a layer-47 root mean square error (RMSE) of 0.0000407 and exact agreement for all 32 generated token IDs, the transcript, and the end-of-sequence (EOS) decision. That gives the implementation agent places to find the first numerical divergence instead of judging the entire model from one sentence.

I independently replayed that merged path on the P3 at commit 047d79a0f. A fresh conversion consumed all 2,104 expected tensors. The native run completed the 7.435-second fixture in 12.11 seconds, reached EOS, and reproduced the certificate's exact 32-token trajectory and transcript. Peak RSS was about 7.78 GiB. Despite a 20-thread policy, the process averaged only about 5.09 CPU-core equivalents, so this is correctness evidence rather than competitive performance evidence.

huggingface-cli download cstr/cohere-transcribe-03-2026-GGUF \
  cohere-transcribe.gguf --local-dir cohere-transcribe-source

python version/v8/scripts/convert_cohere_transcribe_gguf_to_bump_v8.py \
  --gguf cohere-transcribe-source/cohere-transcribe.gguf \
  --output-dir cohere-transcribe-bump

CK_NUM_THREADS=20 CK_AUDIO_NUM_THREADS=20 OMP_NUM_THREADS=20 \
python version/v8/scripts/run_cohere_transcribe_native_v8.py \
  --model cohere-transcribe-bump \
  --audio recording.wav --decode --language en \
  --output cohere-transcript.json

Well, I don't wish to see it any more observed phoebe turning away her eyes. It is certainly very like the old portrait.

The fresh BUMP bundle's manifest and config hashes match the retained Ryzen certificate, but the weights file is four bytes smaller and has a different whole-file hash. Because the final trajectory remains exact, this does not invalidate the run, but CKE should still explain and eliminate that cross-host bundle-byte difference before claiming deterministic conversion artifacts.

The short path runs at about 0.61 times real time on P3. PR #510 then makes long audio bounded and resumable instead of feeding silence or an unbounded sequence directly into the model. It imports speech slices from a pinned Silero VAD export, resets model state for each slice of at most 30 seconds, aligns token times through monotonic dynamic time warping, atomically retains each completed slice, and emits JSON, plain text, and SRT.

PR #510: Cohere Goes End To End On My Complete Recording

The retained Ryzen certification processed all 123 scheduled speech slices from my 42:22 kernel-engineering presentation. Of the 2,542-second source, 2,288.04 seconds were classified as speech and 253.96 seconds were intentionally skipped. This matters because Cohere can fabricate text on silence; VAD is a correctness boundary here, not merely a speed optimization.

The Ryzen CKE run emitted 10,207 tokens and 729 SRT captions in 646.48 seconds of raw runner time, about 3.93 times real time. Against CrispASR running the same model, the retained implementation differs by one word out of 6,889: CKE keeps a fourth spoken it's that CrispASR's generic repetition filter removes. This is excellent implementation parity, but it is not human-reference WER and should not be presented as universal transcription accuracy.

I then repeated the complete run independently on the Intel P3 at merged commit c24f01fd2. It passed all 123 slices in 1,613.67 seconds, or 26:53.7, approximately 1.58 times real time. It averaged 12.15 CPU-core equivalents under a 20-thread policy and used about 8.15 GiB peak RSS. The selected token array, caption array, transcript, plain-text file, and SRT file all match the Ryzen run exactly.

Cohere is currently 24.4% faster than Parakeet on this P3 workload, but still 11.2 times slower than Whisper. P3 is also about 2.50 times slower than Ryzen for the same exact Cohere trajectory. That makes CPU-provider utilization and cross-instruction-set architecture (ISA) profiling immediate optimization targets. The result is nevertheless practical: CKE can now produce a coherent editable transcript and SRT faster than the recording plays, on CPU only, with exact reproduction across two processor vendors.

The remaining Cohere boundaries are narrower now: CKE still depends on external VAD; DTW timestamp accuracy is not independently scored; multilingual, quantized, generated-circuit, and concurrent-session behavior remain open; and conversion-byte reproducibility still needs explanation. Those are meaningful next gates, but long-audio execution itself is no longer hypothetical.

The Next Audio Gates

1. Parakeet five-minute gate: passed for full attention and deterministic overlapping windows on one curated English recording.
2. Parakeet long-audio gate: passed for bounded execution, exact source coverage, resumability, and monotonic timestamps; full-track WER remains open.
3. Memory evidence repair: preserve aggregate full-run peak RSS across resume instead of publishing contradictory values.
4. Generated-circuit ownership: move remaining NumPy model arithmetic into declared CKE operations and planned memory.
5. Broader quality gate: expand beyond one five-minute English recording and compare Whisper and Parakeet on held-out audio.
6. Cohere Transcribe short-audio gate: passed with complete conversion, tokenizer integration, one exact 32-token trajectory, and retained 48-layer X-Ray evidence.
7. Cohere Transcribe long-audio gate: passed across the complete recording with bounded VAD slices, resumability, monotonic DTW timestamps, and exact Intel/AMD text and SRT.
8. Cohere Transcribe hardening gate: explain the four-byte bundle discrepancy, move VAD into CKE, independently score timestamps, then add multilingual, quantized, generated-circuit, concurrent-session, and profiling evidence.
9. Diarization gate: a versioned segment application binary interface (ABI), independent NeMo evidence, multi-speaker fixtures, diarization error rate, overlap checks, and ASR alignment.
10. Nightly gate: keep short exact trajectories mandatory and schedule longer practical workloads without making ordinary pull requests wait for them.

Why This Direction Matters

Most software I build eventually needs to become useful in my own work. Antsand has powered my websites and content workflow for years. CKE is beginning the same transition from architecture research into a tool that can transcribe recordings, help edit videos, inspect models, and eventually serve other Antshiv Robotics workflows on owned CPU compute.

Whisper proved that one CKE audio path can become practical. Parakeet tests whether the same kernel, circuit, memory, and evidence architecture can support a materially different speech model. Cohere Transcribe has now reused part of that foundation while requiring a different decoder, and both its short trajectory and complete long-audio outputs reproduce exactly. Diarization adds another model family and another timeline, but it should arrive as an explicit subsystem rather than an unchecked feature bolted onto transcript text.

The goal is not to collect model names. The goal is to make each new architecture reveal the smallest genuinely missing kernel, composition, state contract, or runtime policy, then retain enough evidence that the next change cannot quietly break it.

Implementation And Evidence

• PR #503: Parakeet TDT inventory and reference boundary
• PR #504: native Parakeet TDT end-to-end path
• PR #507: deterministic five-minute and 42-minute Parakeet hardening
• PR #508: native Cohere Transcribe short-audio path
• PR #510: bounded Cohere Transcribe long audio
• Cohere Transcribe complete-recording certification
• The complete 42-minute source video used for these transcriptions
• CKE audio kernels: preprocessing, Conv1D, attention, and cross-attention
• Parakeet TDT circuit, kernel inventory, and retained evidence
• Cohere family kernels and Transcribe Conformer architecture
• CKE Parakeet TDT reproduction page
• Matched five-minute Whisper and Parakeet evidence
• Parakeet 42-minute certification
• CKE model and kernel evidence matrix
• NVIDIA Parakeet TDT 0.6B v3 model card
• NVIDIA NeMo speaker diarization overview

Related Notes

• I Used CKE To Transcribe My Video. It Found A Bug In My Compiler
• What CKE Fixed Today: Honest Evidence and Faster CPU Whisper
• Qwen3.8 Broke In CKE: Our Regression Tests Needed To Catch It
• How CKE Brought Up Qwen3.8 Flash Next