A model giving me text is useful, but it is not yet an agent backend. An agent needs to send a conversation, receive a structured tool call, run that tool, return the result, and keep going. If a request is cancelled or a tool fails, the next request still needs to work.
CKE has now crossed that boundary in two local CPU workflows. Qwen Code completed bounded file-editing tasks against a Qwen3.8 27B Q4_K_M bundle. The Antigravity SDK completed a separate four-task suite against a Gemma4 E4B Q4_K_M bundle. Both used CKE's generated native model execution behind an OpenAI-compatible endpoint. They are real tasks with checked file and tool results, not just a screenshot of fluent output. They are also bounded results, not a claim that I can already leave ten agents unattended overnight.
From circuit to a client that can do work
CKE starts with a circuit describing the model's computation. A serving declaration links it to a profile. The build resolves that with the actual model artifact, publisher Jinja template, tokenizer, output protocol, hashes, and generated native library into a BUMP bundle. The server loads that resolved identity. It should not guess a publisher format from the model's name. PR #598 established much of this ownership path, and PR #612 made the harness check what bundle and session library were actually loaded.
The distinction between input and output is important. Publisher Jinja renders the incoming conversation and tool declarations into tokens. It cannot, by itself, interpret a tool call emitted by the model. Qwen's tool profile uses a Qwen-specific output protocol; Gemma4 needed a declared gemma4_dsl_v1 parser and publisher-shaped tool declarations. PR #646 added that Gemma path while leaving chat-only as its default. The HTTP request lifecycle, result correlation, identity checks, and generated-C execution remain shared.
In a file-edit task, that means the client asks to read a file, CKE renders the request, the generated model produces a call, the declared parser turns it into a structured response, the client executes it, and the result is sent back for continuation. I care about the file on disk and the validator exit status at the end. A model saying "I edited it" is not enough.
Milestone one: Qwen Code on a CPU endpoint
Early Qwen tool work exposed parser and native-session ownership faults; PR #594 repaired them. PR #608 then made Qwen Code perform a concrete task: read HTML, change the exact heading, run a validator, and summarize. Its acceptance runner checks tool-call IDs, argument/result correlation, order, file contents, and terminal success. The loaded-artifact checks in #612 keep task success separate from proof that the intended generated bundle served the request.
The less visible milestone is recovery. PR #630 improved cancellation and disconnect handling during silent prefill, kept native ownership until a worker actually returned, and treated output-budget exhaustion as incomplete rather than successful. Its retained Qwen tests included cancellation, disconnect, timeout, stale-cancel rejection, follow-up success, and four artifact-certified edit-and-test tasks. PR #649 retained a contention/HTTP 429 attempt as failed or incomplete evidence instead of quietly promoting it to a pass.
The tested Qwen bundle had a compiled capacity of 262,144 tokens. The two cited harness tasks on that bundle used about 7,500 to 8,000 input tokens per turn. This is evidence that the endpoint can run those tasks, not that a 262K-input Qwen Code task was tested. On October 13 the endpoint was reachable during the P3 evidence check; a separate Qwen documentation/SVG job was still active, so I am not counting it as a completed result.
Milestone two: Gemma4 through the Antigravity SDK
Gemma4 exercises the same host through a different declared model protocol. The Antigravity SDK's local-model support allows an OpenAI-compatible server. In this test the SDK used that route to CKE; it did not replace CKE's generated model execution with LiteRT.
The initial 2K-context Gemma4 E4B tool bundle completed bounded SDK tasks, but earlier runs had answer-quality failures even when the tools executed correctly. Later runs passed four checks: read a fresh file value, answer from two files, edit HTML and pass a validator, then recover after a deliberately failed tool call. The runner checked actual tool effects, not just the model's final prose. PR #646 records that first connection and its limits.
A larger bundle found another real defect. Building a local GGUF by filename omitted the sibling publisher tokenizer.json; Jinja could not resolve bos_token, so requests failed before model execution. PR #755 stages that sidecar and rejects conflicting bytes. The repaired Gemma4 E4B Q4_K_M bundle compiled for 32,768 tokens passed chat, budget rejection, cancellation/recovery, and two four-case SDK attempts. A separate 15,025-token input returned the expected answer in 266.5 seconds. That tests 15K input, not the full 32K boundary or an overnight service.
A fresh four-case SDK run on October 13 passed against the repaired bundle while the Qwen service remained available. Its loaded serving identity, native session hash, and server instance matched before and after. The tools were restricted to a disposable workspace. This is an SDK integration result, not a claim that the Antigravity CLI, all Gemma checkpoints, or unrestricted agent access have been certified.
Milestone three: batching is being built, not declared finished
Multiple HTTP requests waiting in a queue are not continuous batching. CKE first added a bounded single-flight FIFO in PR #700. The generated runtime then began separating sequence state while sharing selected weight work: per-sequence KV in #661, a genuine two-row projection in #666, and eventually 18 layers and 72 projection groups in a small Gemma3 diagnostic in #692.
The corrected matched timing for that tiny Gemma3 diagnostic was actually slower: roughly 71 to 77 ms for three two-row steps, versus 59 to 62 ms for six isolated decodes. It established correctness of selected shared work, not a general speedup. Later changes added budgeted slots, request-owned sampling/cancellation, an opt-in two-slot HTTP path, and staged prefill. PR #734 exercised mixed rows on a resolved Gemma3 270M chat-only bundle. That is not the Gemma4 E4B tool bundle above.
Staging also revealed a ten-token ordinary-versus-staged discrepancy. CKE retained prefix and KV captures, used a pinned llama.cpp comparison, and narrowed one captured difference to QK reduction order crossing an FP16 rounding midpoint (#745). That explains the captured boundary under its declared arithmetic; it does not certify every staged trajectory. Qwen3.8 adds recurrent convolution/SSM history as well as KV attention. PR #750 made sequence-local recurrent state explicit, but the existing deployed 27B bundle predates that metadata. It needs rebuilding and numerical comparison before I can call Qwen3.8 a continuously batched multi-agent endpoint.
The evidence I want to keep
CKE is becoming useful to me as a local agent backend. The progress is a reusable serving contract and two client workflows that completed checked tasks on identified CPU bundles. The remaining gates are equally concrete: longer unattended runs with retained failures, a rebuilt Qwen3.8 bundle with recurrent-state isolation, artifact-specific interleaving tests, and fair measurements of throughput, first-token delay, latency, memory, and scheduling fairness. I would rather publish those limits with the working result than erase them from the story.
For implementation detail, start with the CKE serving documentation, the v8 runbook, and the linked PRs. This article reports the retained October 13, 2026 task evidence; it is not a benchmark across CPUs or GPUs.
The PRs behind the milestone
12 selected PRsThese are the source changes most useful for checking the article's claims. The groups are a reading guide, not a certification label. The linked PRs carry the implementation, tests, and remaining limits.
Bundle and protocol contractResolve an artifact, render its input, parse its output, and attest the loaded code.4 PRs
Agent task and recovery evidenceCheck files and tool results, then test the next request after failure.3 PRs
Batching and numerical boundariesSeparate sequence state, share checked work, and keep Qwen recurrent batching gated.5 PRs
- PR #661Isolate generated decoder state for two sequencesd9969a1c
- PR #692Share checked two-row projections across Gemma3 layers; timing was slowera95b397a
- PR #734Test mixed-row HTTP execution on a Gemma3 chat-only bundle2735b08d
- PR #745Pin the captured Gemma arithmetic boundary verdict20b99b0e
- PR #750Isolate recurrent state per generated sequence; shared Qwen execution is still gated3dfd26a9
Source: the linked merged CKE PRs. Merge dates and commit IDs were checked against GitHub. This is a curated reading path, not a complete changelog.
Related Notes
- What Changed in C-Kernel-Engine This September explains the architecture, modality, and evidence streams behind this milestone.
- How to Get Started With C-Kernel-Engine on Linux is the practical entry point if you want to inspect a generated model yourself.
- Qwen3.8 Broke in CKE shows why a live demonstration must become retained regression evidence.
- CKE Vision: Find the First Bad Edge applies the same first-divergence discipline to another modality.