An early DS4 harness attempt by a CKE contributor against C-Kernel-Engine (CKE) barely worked with the models tested. A model could answer a prompt, yet the harness could not reliably carry a coding task through tools and back into a second model turn. That frustrating start was useful: it exposed how much sits between a model and an agent. Token IDs, publisher chat templates, output delimiters, tool schemas, client permissions, session state and replay all had to agree. A server could return HTTP 200 while the agent still failed to do the work. I wrote about the contributors' broader work on CKE's server separately.
At first it was tempting to treat that as one broken endpoint. It was not. A later Qwen Code probe made one tokenizer failure measurable: the native path saw 304 tokens where the reference saw 7,773. CKE contributors helped repair the underlying serving contracts, including publisher-template and tool-token work in PR #594. Then bounded Qwen Code tool tasks, bundle-identity checks and repeated harness acceptance became separate PRs. Muse and Instella forced different fixes again. The early DS4 attempt is an exploratory starting point, not a retained DS4 benchmark; the linked PRs below are the evidence for the later implementation.
This article follows that progression. At 40,000 feet, it explains how a harness asks a model to use a tool and how the observation returns. At code level, it shows where CKE binds a model's tokenizer, Jinja template and declared tool protocol, and where it refuses to guess. Qwen Code with Qwen and Muse Code with Muse are specific compatibility paths to test, not a rule that every model must use a branded harness. One successful pairing does not automatically certify every client, model artifact or tool task.
Here is the question that guides the article: what exactly crossed each boundary, and what evidence says it survived? I will use a file-read turn to establish the shape, then two CKE tests to show how apparently small compatibility details determine whether the next turn can happen at all.
First, what is a harness?
In this context, a model computes a continuation. A server turns client requests into model sessions and returns structured results. A harness runs the outer task loop: it assembles instructions and context, advertises tools, asks the model what to do, checks whether a proposed action is permitted, executes the tool, returns the observation, and decides whether to continue. A coding harness can also own the workspace, terminal, approvals, retries, budgets and a conversation history. Qwen Code and OpenHands are harnesses in this sense. A model does not open a file just because its output contains something that looks like a file-read request.
The distinction matters because a proposed tool call is not a side effect. The server must expose the call in the API shape the client expects; the client must recognize it, authorize it, perform it and send the result back. If any step is lost, the model can appear intelligent in a single response while the agent does nothing useful.
A useful test question
Did the model merely print a plausible read_file string, or did the client receive a valid call ID and arguments, read the file under its own permissions, return the file contents, and receive a coherent model continuation? Those are different levels of evidence.
One file read, six boundaries
Consider a bounded request: “Read this HTML file and tell me what its heading says.” Qwen Code advertises its read_file tool and sends the task to an OpenAI-compatible endpoint. The CKE HTTP layer renders the conversation with the selected chat template; the native session tokenizes that rendered prompt and runs the generated model. If the model proposes read_file, the server parses and validates the declared tool protocol, returns a structured call, and stops that turn. Qwen Code then decides whether the call is allowed, reads the file, sends the result back as a new message, and the model produces the final answer.
A failure can hide in any of these boundaries. A tool may be absent from the advertised set. The model may emit a call in a different syntax from the configured parser. The server may stream half of a call before it knows whether the JSON or XML envelope is valid. An output cap may be larger than the compiled context capacity. A file result may be returned with the wrong role or call ID. A server may continue stale KV state from another task. These are not all “model quality” failures; many are systems failures.
The second turn is the real test
A one-turn test can miss the most damaging class of bugs. Imagine that a model emits reasoning, then tool call A, then more reasoning, then tool call B. After both tools run, the next request must reconstruct the previous assistant turn and the corresponding results in the form expected by that model's template. Combining both reasoning spans into one block and moving both calls after it changes the sequence, even if every word and every tool argument survives. The model no longer sees the same causal order.
CKE's Qwen Code acceptance work in PR #608 deliberately correlated harness arguments with the terminal result instead of stopping at a model-emitted tool string. The repeated local harness acceptance work in PR #649 went further: retain the identity, classify token failures and run a matrix against one server instance. Neither PR proves every model's interleaved, multiple-tool replay. It does establish the right unit of evidence: a complete client-to-model-to-tool-to-model task with the versions and artifact pinned.
This is why I want one clear owner for each transformation. The template decides how a model reads prior messages; the parser identifies current reasoning and tools; the API adapter serializes those structured pieces. The acceptance artifact should capture both the emitted event trace and the next rendered prompt. Otherwise a correct first response can hide a broken continuation.
Why a common API does not erase model differences
It is tempting to say that everything speaks the OpenAI API and therefore every model should work with every harness. The API standardizes the outside shape, not every byte the model consumes or emits. Each converted model bundle has a tokenizer, special tokens, chat template, stop conditions and possibly a tool syntax. A Qwen tool call expressed as XML-like tags is not automatically the same as a different model's JSON or channel-delimited call. The server must know which parser applies to the exact bundle. It should not guess from a name that happens to contain “Qwen” or “Muse.”
The model and harness are also not permanently married. Qwen Code can use a configured provider endpoint, and OpenHands has configurable model profiles. The practical unit of testing is a client version + model artifact + serving profile + task, not a marketing pair such as “Qwen always needs Qwen Code.” A reusable server contract should support many pairs where their capabilities align; the profiles and acceptance tests capture the differences that remain.
| Layer | What must be exact | What can be reused |
|---|---|---|
| Native runtime | Model graph, weights, tokenizer and state layout | CKE session ABI and generated execution pattern |
| Serving profile | Chat template, stop policy, tool protocol and capacity | HTTP routes, request validation and session lifecycle |
| Client harness | Tool names, schemas, permissions and continuation behavior | The outer agent loop and workspace management |
| Acceptance | Pinned versions, real model, exact task and retained result | A common ladder of evidence across integrations |
Where CKE enforces the contract in code
The 40,000-foot path is harness request → resolved model bundle → rendered prompt → native token IDs and generation → parsed API event → harness tool → new request. None of those arrows can be replaced by “the model supports tools.” The exact artifact and template matter more than a model-family label.
| Step | CKE owner | Why it exists |
|---|---|---|
| Resolve the bundle | resolve_serving_bundle_v8.py | Collect the publisher's default and named Jinja templates, tokenizer files, compiled libraries and hashes. A selected template belongs to this bundle, not an arbitrary server default. |
| Admit and render | server/live.py | Select the effective template for a tool-bearing request, map declared roles, validate schemas and reject tools when the selected protocol is undeclared. |
| Execute the model | ck_serve_v8.py and ck_session_v8.h | Pass the rendered prompt across the session boundary. Native tokenization, generation, stop handling and detokenization use the generated model's declared capabilities. |
| Return a tool event | server/live.py and its protocol tests | Parse only the declared output format and return a validated call name, arguments and ID. A template mentioning tools is not permission to invent a parser. |
| Prove the second turn | Muse HTTP tests and Qwen harness acceptance | Check that a harness can return a tool observation under the same call ID and obtain a coherent continuation, with each test scoped to its actual model or test double. |
The server's documented bundle contract is deliberately strict: a converted bundle needs its BUMP, generated libraries, tokenizer and template sidecars. The chosen tool_protocol.json records the selected template's SHA-256 and a declared parser such as qwen_code_xml; a mismatch fails startup. The HTTP layer fails rather than silently switching prompt format if Jinja rendering fails. That is the practical lesson from the early harness attempts: the model publisher's template is part of the executable interface, not decorative prompt text.
The tokenizer bug that made the abstraction real
One CKE Qwen Code investigation exposed a particularly instructive failure. A 33,379-byte tool-bearing prompt was reduced by the native BPE path to 304 tokens while an independent GGUF tokenizer counted 7,773. That is not a small stylistic difference in prompt formatting. It means the model was effectively being asked a different question. The rebuilt model, engine and tokenizer libraries then matched all 7,773 input IDs in the bounded probe and completed a cached read_file continuation. Replacing only one library under an older generated model would not have been a safe fix.
Another Qwen path exposed a different mismatch: a delimiter that the upstream tokenizer treats as one special token could be split into ordinary CKE tokens. A bounded Qwen Code task can still succeed while that native-template token-ID gap remains unresolved for the specific artifact. These two observations are why I avoid saying “the Qwen harness is solved.” One retained task result establishes that task on that bundle; it does not certify every prompt, context length, template or client version. The CKE v8 serving runbook records the exact limitations.
Side note: context size is a contract, not a slogan
Advertising a 262K-token window does not mean a compiled runtime can accept an arbitrary prompt plus an arbitrary output reservation. The server needs to count the fully rendered prompt, reserve the requested output, and reject a request that exceeds the generated capacity before native execution. A large configured window is not proof of a successful long-context agent run.
Prompt identity is part of the runtime
Agent turns resend instructions, tool definitions and conversation history. In CKE, the first question is not whether a cache can reuse that prefix; it is whether the selected model bundle renders and tokenizes the same conversation the harness intended. A changed tool schema, role policy or chat-template variant changes the actual input. The Qwen compatibility work in PR #594 selected the effective publisher template and preserved its tool tokens. Muse PR #778 preserved developer instructions in the resolved serving path. Those are correctness fixes before they are performance questions.
CKE's next optimization work should measure repeated prefill on a pinned bundle only after prompt IDs, rendered roles, tool declarations and output reservation agree. A fast request built from the wrong prompt is not progress. The model artifact, tokenizer, template and serving profile have to travel together as one identity.
Tool calls are a protocol, not free-form text
For Qwen Code, CKE currently uses declared tool-protocol variants rather than treating any text resembling a function as executable. The serving bundle carries a selected template and protocol identity; mismatches fail startup. The server validates advertised tool names, argument schemas and call IDs before returning a call. If the client disables parallel calls, a multiple-call response must not be silently truncated to the first call. If an edit argument contains code or HTML, its whitespace and delimiters matter. The compatibility parser has an explicit edge case for a literal closing </parameter> inside a parameter body; calling that out is more honest than pretending an XML-like format is arbitrary-string safe.
Streaming adds a second tension. A text-only answer can be emitted token by token. A tool-bearing answer should not send an incomplete action to a client that may execute it. CKE buffers tool-bearing output until it can be validated, while keeping the connection alive; this prioritizes correct actions over showing every partial token. It is a serving decision, not a change to the mathematical model.
CKE's buffered approach is a conscious trade: the harness learns about the action only after the server has a validated complete call. Early dispatch could eventually reduce the time before a tool runs, but it would need a parser that proves a call is complete and a client that understands that event. A future benchmark should measure time from complete call to client action, without weakening fail-closed behavior for malformed, duplicate or unadvertised calls.
The server must recover after a bad request
An agent does not send one perfect prompt and exit. It retries, cancels, exceeds limits, and submits a new task after the previous one fails. A development server is useful only if request B cannot inherit broken state from request A. CKE's PR #606 tested recovery after native completion and failure; PR #612 bound acceptance to the loaded model bundle and its effective settings; and PR #633 added artifact-bound HTTP lifecycle acceptance. These PRs are about making a successful result attributable to the model actually loaded, and making failure observable rather than silently contaminating the next turn.
Concurrency adds another contract. PR #700 introduced bounded FIFO admission for the ordinary single-flight path. PR #715 added an opt-in two-slot generated HTTP decode path, and PR #734 retained a mixed-row Gemma3 HTTP acceptance tied to request IDs. That is not a claim of arbitrary concurrent agents or production multi-tenancy. It shows that queueing, native slots, response ownership and terminal delivery each need their own test before a second user can be treated as just another request.
The client shapes the request before CKE receives it
A server can implement a route correctly and still see a weaker agent because the client selected the wrong model profile. A harness profile can change instructions, context budget, output truncation, reasoning options, advertised tools and parallel-call behavior before HTTP begins. CKE's Muse Code work makes this concrete: PR #783 added namespace function-tool validation and a test for the client's output-budget cap. Those are not changes to Muse's mathematical graph; they are changes to what the client is allowed to ask and what the server can safely return.
For CKE, I would record the client version and selected client profile alongside the model bundle. The server already reports its generated context length and default output allowance through its model endpoint, but a complete acceptance test must also inspect what the harness actually sent: rendered tools, reasoning setting, prompt length, requested output and any tool-result truncation. API schema compliance alone cannot prove that the harness used the intended policy.
The CKE serving PR trail
CKE's server documentation describes a development HTTP server backed by a generated native session ABI. Stores are process-local and non-durable; ordinary serving admits one generation at a time, with a separate experimental opt-in two-slot path for generated KV-only batch-capable models. There is no built-in authentication or durable queue. That is a useful development boundary, not yet a multi-tenant service.
On a pinned Qwen3.8 Q4_K_M path, retained tests include a server-issued Qwen Code read_file continuation and a bounded read_file-then-edit task. A write_file request was correctly rejected when Qwen Code had not advertised that tool. Those runs do not certify general file creation, shell execution, arbitrary edits, cancellation recovery or concurrent sessions. Gemma has a separate bounded Antigravity SDK acceptance runner; that is not evidence that every Gemma or every harness behaves alike.
Muse Glimmer is now more than a name on a candidate list. PR #770 repaired publisher JSON rendering, PR #771 declared and parsed ATEM turns, PR #773 exposed that declared protocol through the serving CLI, and PR #783 tightened Muse Code namespace-tool admission. PR #775 separately fixed imported tokenizer splitting for numeric and Unicode text. That sequence shows why a new model family needs template, tokenizer, role, parser and client-schema work, not merely a model-name alias.
Instella has a different boundary. PR #776 linked its circuit to a publisher chat-serving contract, while PR #780 validated the captured OpenCode 1.19.1 tool schemas and exclusive numeric bounds without enabling Instella tools. PR #787 repaired MLA prefill history across chunks. These are real integration steps, but the serving coverage inventory still marks tool protocol and round trip as unassessed for Muse Glimmer and Instella. OpenHands is not the same client as OpenCode; this article does not claim a completed OpenHands acceptance.
Case study: the request must be admitted before generation
OpenCode 1.19.1 sends a captured set of ten tool schemas. One field expresses a timeout with an exclusive lower bound: zero is invalid, one is valid. That is ordinary JSON Schema behavior, but a server that only understands inclusive minimum can reject an otherwise well-formed harness request or apply the wrong bound. In CKE PR #780, the test first verifies that all ten captured schemas fit the server's supported subset and that exclusive bounds are actually enforced.
exclusiveMinimum: 0
value 0 -> reject
value 1 -> accept
OpenCode request + Instella bundle with no tool protocol
-> HTTP 501, tool_protocol_undeclared
-> no template render, no model generation
Next plain-chat request
-> HTTP 200, model returns OKThe second half is the important part. Schema validation is not permission to invent a tool parser for Instella. The captured OpenCode request reaches a deliberately undeclared-protocol boundary and fails before model work; then a plain chat request still succeeds. The test uses a controlled session, not a live Instella/OpenCode agent run. It proves safe admission and recovery, not that Instella can operate OpenCode's tools. That distinction is exactly why CKE's coverage inventory keeps the tool gate unassessed.
Case study: a tool call must survive the next turn
Muse has another problem: its emitted ATEM/channel syntax must become API objects without leaking raw delimiters to the client. PR #771 added protocol parsing, and PR #783 exercised Muse Code's namespaced tools. In the HTTP test, a controlled session emits a muse.read_file invocation for /tmp/a. The Responses endpoint returns one structured function call with namespace muse, name read_file, and JSON arguments. The client then submits a result tied to the call ID; the second prompt contains that result, and the controlled session answers that the file says cobalt.
Turn 1: request tools=[muse.read_file]
native text contains ATEM function-call markup
API returns function_call(id, namespace, name, arguments)
Turn 2: function_call_output(call_id, "cobalt")
next rendered prompt contains the observation
API returns the final answerThat test runs both streamed and non-streamed HTTP paths and checks that raw channel delimiters do not escape into the API response. It also checks that malformed namespaces and unsupported forced tool choices fail before generation. But its native output comes from a test double, not a generated Muse model under the Muse Code CLI. It certifies the server's parsing and continuation contract; model-emitted tool reliability and a real client task still need separate retained acceptance.
What happens after a harness receives a tool event?
The model's output is still only a proposal. Suppose it emits read_file({"path":"server/live.py"}). CKE checks that the call fits the declared protocol and advertised schema, then returns a structured call and ID. The harness matches that ID to its own pending turn, checks whether read_file is permitted, resolves the path inside its workspace, reads the bytes, and may truncate or summarize the result according to its client policy. The harness submits the observation with the same call ID in a new request. CKE renders that new conversation, tokenizes it, and runs the next model turn. The native model never directly opens server/live.py.
This separation creates three independent failure surfaces. Server validation can reject a malformed or undeclared call. Harness policy can deny a valid call because the tool or path is not allowed. Continuation can fail if the result is attached to the wrong call ID, role, or template position. A successful HTTP response at the first surface proves nothing about the other two. The sequence diagram above places each handoff in order; its steps are not measured milliseconds.
What if the harness opens another agent?
A delegated agent is another harness task loop, not a new kernel inside the model. Imagine a parent coding assistant asked to review CKE serving. It might delegate a narrow question: “Inspect Muse tool parsing in server/live.py and its HTTP tests. Report the accepted protocol, one negative test, and any unassessed live-client gate. Do not edit files.” The parent chooses that objective, the files or excerpts to include, the allowed tools, and an output budget. The child may call the same CKE endpoint or a different model endpoint, but it sends its own request and receives its own response stream.
agent-delegation.dot, rendered to SVG with Graphviz.The parent should not assume the child inherited its full conversation or credentials. A bounded handoff can carry: the precise subtask, relevant source paths or excerpts, repository revision, tool allowlist, workspace boundary, output format, and deadline or token budget. The child can gather evidence and return a report with file/line references and uncertainty. The parent then decides what to trust, what to verify itself, and which part of that report to put into its next model prompt. Raw secrets, broad filesystem permission and unrelated conversation history should not be copied into a child merely for convenience.
| Boundary | What crosses it | What does not happen automatically |
|---|---|---|
| Parent to child | Selected objective, context, tools and limits | The child does not inherit all parent memory or authority |
| Child to CKE | A separate model request with its own rendered prompt | CKE does not know that this request is a “subagent” unless a client records that relationship |
| CKE to child | Text or validated tool-call events | The server does not execute the child's workspace tools |
| Child to parent | Findings, citations, artifacts and failures | The parent does not have to replay every child token |
Because ordinary CKE serving admits one generation at a time and its two-slot path is experimental and model-limited, spawning two harness tasks does not imply two simultaneous native generations. The harness may queue work; the server's admission policy decides what can run. CKE's current PRs establish pieces of the serving and tool contracts, but this particular parent-child workflow is an explanatory pattern, not a retained CKE multi-agent acceptance result.
How the server contract was built
9 selected PRsThese are distinct gates, not nine proofs of a production-ready agent service. Open a PR to inspect the implementation and retained tests; the merge link pins the code revision.
Qwen harness acceptanceTemplate identity, real tool task, loaded artifact and repeatability.4 PRs
- PR #594Select the effective Qwen publisher template and preserve tool tokens191335eb
- PR #608Correlate Qwen Code tool arguments with a bounded task resulta2b220c1
- PR #612Bind harness acceptance to the loaded bundle identity0f0b6f8d
- PR #649Retain repeated local harness acceptance and classify failuresac48018c
Request lifecycleBound admission before experimenting with two generated slots.2 PRs
New model and client protocolsSeparate server-side parsing from live harness certification.3 PRs
Source: selected CKE merges on main. The register is a reading path, not a full serving changelog.
For the implementation itself, start with server/live.py for request validation and tool protocol handling, then ck_serve_v8.py for the HTTP/native session boundary. The two controlled examples above live in the OpenCode schema test and the Muse HTTP protocol test. Read each test with its PR rather than treating a file's presence as a completed client integration.
The evidence ladder I want CKE to enforce
- Load: pin the exact weights, tokenizer, template, generated C and native libraries. Fail if the bundle identity changes underneath a running server.
- Tokenize: compare full prompt token IDs against an independent reference, including special tokens and tool-bearing turns.
- Chat: prove one complete text request with correct roles, stops, usage and context accounting.
- Parse: validate real model-emitted tool calls against the advertised tools and schemas; reject malformed or unauthorized calls.
- Continue and replay: run an actual harness tool, return its observation, inspect the model continuation and check the next rendered prompt for ordered reasoning, calls, results and the intended thinking policy.
- Repeat: run bounded tasks repeatedly with a pinned client version and preserve failures, not only the best screenshot.
Every result should retain model and bundle hashes, client version and profile, prompt identity and token count, tool set, output cap, runtime capacity, server log, task event stream, next-turn rendered prompt and final artifact. For performance tests, add time to first token, time until a complete tool call, harness execution time, and time until the model can resume. This makes a failure diagnosable: was it a tokenizer disagreement, a parser mismatch, a client permission rule, a mutated prefix, an expired request, or a model that simply made a bad decision?
Why this matters beyond one CLI
I am building CKE to make model execution inspectable and adaptable to the compute I actually have, including CPUs. If the native runtime is correct but no real client can use it reliably, the work stops at a benchmark. If the client appears to work but its prompts tokenize incorrectly, the apparent success is fragile. The serving and harness layer is where mathematical correctness meets practical work.
The longer direction is to let Antsand configure who may use which model, which parameters and tools are available, which CKE worker should serve a request, and what evidence is logged. A future C/ZMQ router can carry that policy to local CKE servers without placing the Antsand website in every token stream. The Linux accessibility work is a particularly good first client: it needs predictable controls, permissions and logs, not merely fluent text. That gateway is a plan, not a deployed CKE feature today.
The lesson I keep returning to is simple: the model is not the product by itself. The tokenizer, bundle, server contract, harness and measured task all have to agree. CKE's difficult serving work matters because it makes those agreements visible, testable and eventually reusable across more than one model or machine.
Related reading
- Someone Else Built CKE's Server for the contributors' server work and PR history.
- What Is The C-Kernel-Engine? for the broader project.
- How exact C functions and numerical contracts connect for the native execution side.
- How Ericsson edge routers shaped CKE for the control-plane analogy.
- CKE local server documentation for its current supported subset and limits.
- CKE serving coverage inventory for assessed and unassessed model-family gates.
