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.

A circuit selects a serving profile and publisher assets; a resolved bundle identifies generated native code, tokenizer, input renderer, and output parser; the common API connects distinct Qwen Code and Antigravity SDK clients.
What became reusable: the circuit and resolved bundle define how a model is served. Qwen and Gemma use the same host, not an assumption that they speak the same tool protocol.

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.

Three distinct stages: serial FIFO serves one request at a time; Gemma3 diagnostic two-row decode shares weight traversal but keeps per-sequence KV state; experimental mixed-row execution pairs staged prefill and decode. Qwen3.8 recurrent batching remains unverified.
These are different contracts. A queue, shared two-row generated work, and mixed prefill/decode must not be reported as one completed feature.

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

Evidence ladder from bundle identity and protocol parsing, through correlated tool results and checked file edits, then cancellation recovery, repeated tasks, and only later artifact-specific batching parity and measured throughput.
Each step answers a different question. A successful file edit does not prove runtime parity, and a compiled context limit does not prove a full-window task.

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.

Selected implementation trail / September-October 2026

The PRs behind the milestone

12 selected PRs

These 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
  1. PR #598Resolve circuit-owned publisher profiles into BUMP bundlesd7a7b565
  2. PR #612Bind harness acceptance to the loaded bundle identity0f0b6f8d
  3. PR #646Declare the Gemma4 tool protocol for the common servere44f1ec8
  4. PR #755Bundle local GGUF tokenizer metadata for servingb643c8e3
Agent task and recovery evidenceCheck files and tool results, then test the next request after failure.3 PRs
  1. PR #608Certify a bounded Qwen Code edit-and-test taska2b220c1
  2. PR #630Recover disconnected streams and label output limitsdb8e18f3
  3. PR #649Retain repeated Qwen and Gemma harness evidenceac48018c
Batching and numerical boundariesSeparate sequence state, share checked work, and keep Qwen recurrent batching gated.5 PRs
  1. PR #661Isolate generated decoder state for two sequencesd9969a1c
  2. PR #692Share checked two-row projections across Gemma3 layers; timing was slowera95b397a
  3. PR #734Test mixed-row HTTP execution on a Gemma3 chat-only bundle2735b08d
  4. PR #745Pin the captured Gemma arithmetic boundary verdict20b99b0e
  5. 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