At a glance

Architecture

1. Runtime vs interface

In KDCube, the runtime is not the same thing as the user interface of the service. ReAct v3 is an agent runtime that bundles use on behalf of users. Claude Code ships with its own first-party client surfaces. That distinction changes almost every row in the comparison.

Dimension	KDCube ReAct v3	Claude Code
What it is	A server-side agent runtime that lives inside KDCube service infrastructure and is usually instantiated by a bundle for a specific user conversation or turn.	A workspace-first coding agent product from Anthropic with its own official client surfaces and local workflow assumptions.
Agent-facing interface	No separate first-party React UI. The client is the bundle or app that creates the agent, passes tools/skills/policy, and renders outputs through KDCube communication and widgets. In practice, the bundle is the application surface.	The claude CLI, VS Code and JetBrains IDE extensions, and claude.ai/code web app. All surfaces share the same slash-command vocabulary (/help, /clear, /compact, /model, /cost, /review, and others) and the same per-tool permission prompt UX.
Application shape	Bundles are end-to-end apps: frontend plus backend. The backend contract is Python-native, but the app can also wrap Node services or sidecars behind a Python bridge. The frontend is not limited to one special client technology.	Claude Code is a first-party agent product, not a bundle application model for hosting your own full-stack app slices.
Service runtime	chat-ingress + chat-proc + Redis relay + storage + auth + bundle runtime. It is a hosted, multi-user system.	Local process and local project environment. The product assumes one user on one machine/project context at a time.
Execution runtime	Separate and explicit. Tool/code execution may happen in-proc, in a local isolated subprocess, in Docker ISO runtime, or in distributed Fargate execution.	Primarily the local shell/filesystem environment of the user, optionally constrained by Claude Code's own permission and sandbox features.
Primary state surface	Timeline blocks, turn log, sources pool, ANNOUNCE, logical artifact namespaces, and optional sparse git workspace lineage.	Workspace files, conversation/session history, project settings, CLAUDE.md, and local Claude session state.
Hosting scope	Multi-tenant by design: tenant, project, user, conversation, bundle, and budgets are first-class.	Local, user-scoped by design. Project-level configuration exists, but there is no native multi-tenant server hosting model.

Agent Loop

2. The React v3 loop is timeline-driven, not just tool-call driven

Aspect	KDCube ReAct v3	Claude Code
Loop core	An explicit state machine: decision → tool_execution → decision → exit. Protocol validation and exit rules are part of the runtime, not just prompt text.	An iterative coding loop around model output, tool use, workspace operations, and local session continuation.
Tool-calling protocol	ReAct v3 is not based on provider-native tool-calling models and does not follow the assistant/tool-call/tool-result protocol as its core runtime contract. It uses its own runtime state machine, decision payloads, timeline events, and tool execution surfaces. That also means the agent brain does not have to be a tool-calling model: any model that can follow the ReAct contract can drive the loop.	Claude Code uses Anthropic's native function-calling protocol directly. The model requests tool calls — Bash, Read, Write, Edit, Glob, Grep, WebFetch, WebSearch, and others — and the client executes them against the local filesystem or shell before returning results to the next model turn.
Planning model	Planning is part of the runtime contract through react.plan lineage snapshots plus plan acknowledgements. Plans are first-class timeline citizens.	Planning is part of the Claude Code workflow surface through built-in commands and local planning artifacts rather than a timeline-backed lineage model.
Built-in coordination	react.plan is not just free-form note taking. It is a built-in coordination tool that creates rolling plan snapshots, acknowledgements, and stable plan references that the runtime can surface again through ANNOUNCE and timeline history.	Claude Code has planning-oriented workflow surfaces, but not the same append-only plan lineage and runtime-level plan acknowledgement contract.
Current operational state	The model sees the timeline plus uncached ANNOUNCE. ANNOUNCE carries open plans, authoritative time, workspace status, transient notices, and current-turn live control state such as consumed followup / steer.	The model works primarily from workspace state, history, configured instructions, and the current local interaction context.
Continuation shape	Continuation is timeline-native. Busy-turn followup and steer are accepted into the shared conversation external-event source; an active React turn can consume them live on the same timeline. followup extends the current turn, while steer first triggers an engineering-layer interrupt that can cancel the active generation or cancellable tool phase, then gives React a short bounded finalize pass on that same turn.	Claude Code has explicit continuation semantics: claude --continue resumes the most recent conversation, and claude --resume opens a picker to select a prior session. Both carry forward the same workspace and session state.
Streaming semantics	Channeled output. Decision JSON, code, thinking, followups, and subsystem streams can be routed separately and subscribed to separately while the same round is still running.	Streams tool calls and results inline as they happen. Extended thinking output is shown when enabled. --output-format stream-json produces machine-readable newline-delimited JSON for programmatic consumers, but the underlying model contract is still native tool calling, so generation itself stays inside that protocol shape.

The important difference is that ReAct v3 is not centered on, and not implemented as, a provider-native assistant → tool → assistant protocol. Its working surface is broader: timeline blocks, source pool, ANNOUNCE, tool events, workspace notices, feedback, and other system-originated events can all become part of what the model reacts to.

Context

3. Context: timeline + sources pool + ANNOUNCE vs workspace + local project memory

Aspect	KDCube ReAct v3	Claude Code
Model-facing context	A system message plus one engineered human message composed from history blocks, current turn blocks, in-turn progress, optional sources pool, and optional ANNOUNCE. When durable user memory is enabled, ANNOUNCE may include a compact [USER MEMORY HOTSET].	Workspace/project instructions, Claude settings, current session history, and the local project environment.
Structured memory	Timeline and turn log are persistent, typed, and queryable. React also has internal memory anchors written with react.write(channel="internal"), indexed react.note retrieval through react.memsearch, and optional durable user memory that is user-visible, scoped, searchable, and reconciliation-ready.	Local Claude Code history and project memory are file/session oriented rather than a hosted timeline artifact plus user-memory model.
Sources and citations	Source pool is a first-class conversation artifact. Citations use structured [[S:n]] tokens and are rewritten during streaming/rendering. The same hosted artifact model also covers binary outputs and file-backed artifacts, not only text snippets.	Claude Code is not built around a comparable platform-level citation/source-pool system.
Logical addressing	Logical namespaces such as fi:, ar:, so:, sk:, ks: when a knowledge space is attached, and tc: let the agent refer to historical files, artifacts, sources, skills, and knowledge deterministically. Bundles can extend this namespace surface with their own resolvers and bundle-specific logical spaces. Resolver-backed navigation URLs make those references traversable across timeline objects instead of reducing everything to raw prompt text.	Primary addressability is the actual filesystem and project-local conventions.
Workspace activation	Sparse by design. Historical materialization is explicit via react.pull; active project seeding is explicit via react.checkout.	The workspace is already the live local project. File operations are direct.

Tools

4. Tools, skills, and permissions

Aspect	KDCube ReAct v3	Claude Code
Tool surface	React-specific runtime tools such as react.read, react.pull, react.checkout, react.write, react.patch, react.memsearch, react.hide, and react.plan, plus SDK tools, bundle-local tools, and MCP tools. The same react.write surface also supports internal memory anchors on the internal channel.	Built-in tools cover the local filesystem (Read, Write, Edit, Glob, Grep), shell (Bash), web (WebFetch, WebSearch), and subagent delegation (Task). MCP-connected servers extend this surface. The full available tool list is visible and configurable per project.
Self-doctoring and cost control	react.hide lets the agent intentionally hide recent garbage or no-longer-useful material behind a replacement marker while keeping a path-based route back to it. That is both self-cleanup and a money saver, because it trims distracting tail material without losing recoverability. The runtime also guards this with a three-point cache layout: previous-turn tail, pre-tail checkpoint, and tail checkpoint. Hide is bounded by the pre-tail checkpoint, so the agent cannot wipe arbitrarily deep history just to chase a shorter prompt.	Claude Code can steer around bad local state in its own way, but it does not expose the same timeline-native hide contract over hosted conversation artifacts.
Skills	Skills are a first-class subsystem. They are reusable instruction bundles injected into generators and filtered per consumer/agent.	CLAUDE.md files are the primary instruction layer, loaded hierarchically: global (~/.claude/CLAUDE.md), project root, and per-directory files for scoped context. Custom slash commands can be defined as markdown files under .claude/commands/ — each file becomes a reusable command available in any Claude Code surface.
Where permissions live	Server enforcement. The bundle decides which tools to attach when it creates the React agent for a user conversation or turn. Per-user tool selection is app-configurable, because the client is the bundle/app, not React itself.	Each tool call prompts the user to allow, deny, or always-allow. Persistent rules can be written to settings.json (allowedTools / blockedTools arrays). The --allowedTools and --disallowedTools CLI flags override per invocation. --dangerously-skip-permissions disables all prompts for fully automated pipelines.
What “per-user tools” means	React does not ship a built-in tool-picker UI. But a bundle can store user preferences and pass a user-specific tool catalog at agent construction time. That makes tool selection per user if the application wants it.	The user controls which tools are available through the built-in permission prompt and settings files. There is no separate app-layer tool picker needed — the product provides this directly. For CI/automated contexts, the tool allowlist can be fixed via CLI flags at invocation time.
MCP	Supported in the tool subsystem and bundle runtime.	MCP servers are configured in user-level or project-level settings.json under the mcpServers key. Both local stdio-based servers and remote HTTP/SSE servers are supported. Scope (user vs project) determines which sessions see the server.

Execution

5. Execution runtime: this is where KDCube is materially different

Aspect	KDCube ReAct v3	Claude Code
Default execution model	Platform-controlled execution runtime. Generated code can run in isolated subprocesses, Docker ISO runtime, or remote distributed execution, depending on policy.	Local shell and local filesystem operations in the user's own environment.
Isolation	Docker ISO runtime uses a supervisor/executor split. Untrusted code runs without network and with a locked-down writable surface. Distributed execution snapshots work/out state explicitly.	Claude Code relies on local environment permissions, sandboxing modes, and user approvals rather than a KDCube-style remote ISO execution substrate.
Distributed execution	Yes. KDCube can move execution to Fargate while keeping the logical tool result contract stable for the agent.	Not the native product shape.
Execution as a platform capability	The exec/runtime subsystem is not only for React. The platform exec tool can also be reused by other agents or tools.	Claude Code execution is part of Claude Code itself, not a separable general-purpose execution substrate for other hosted agents.
Tools inside execution	In isolated execution, code may call built-in non-React tools and custom tools through the tool subsystem. React-only workspace/timeline tools remain loop-level primitives rather than arbitrary child-runtime globals.	Claude Code operates directly with its own built-in local tool surface instead of routing through KDCube's isolated execution contract.

Streaming

6. Streaming and channel listeners

One of the most under-described parts of KDCube is that the stream itself is programmable. The channeled streamer can publish multiple logical channels, and subscribers can listen to those channels while generation is still in progress. That means the platform can react before the turn is over.

Claude Code also streams, so the distinction here should be precise. Claude Code has real live output and a real machine-readable event stream. But Claude Code still uses the tool-calling protocol with the model, which means the generation is fundamentally shaped as assistant/tool activity in that format. React's model is different: the runtime can define separate lanes such as thinking, validated decision JSON, raw code, widget streams, and other custom channels, and different downstream consumers can subscribe to those lanes independently during the same generation.

That matters especially for code. In React, code can be requested and streamed as code. It does not need to be squeezed into a tool-call JSON argument or flattened into assistant text first, which is a much worse fit for long or indentation-sensitive output such as Python.

Aspect	KDCube ReAct v3	Claude Code
Transport	SSE and Socket.IO over a Redis relay, with session-scoped fanout and communicator envelopes.	Claude Code's own local product streams to its first-party client surfaces.
Channel shape	Thinking, answer, followup, JSON decision channels, code channels, subsystem streams, canvas streams, and custom typed events can coexist. The runtime chooses these lanes explicitly.	Single primary product stream to the terminal or IDE panel, with tool calls and results shown inline. Machine-readable output via --output-format stream-json produces a newline-delimited JSON event stream, but it is not the same thing as arbitrary runtime-defined output lanes such as separate code, widget, and decision channels.
Mid-stream listeners	Yes. Subscribers can parse a channel and act before the overall turn ends. Widgets already do this for live exec/code panels; the same mechanism can feed other agents or workflows.	Claude Code has its own local streaming/product behavior, but not KDCube's channel-subscriber relay model where different downstream consumers independently listen to different channels of the same generation.

Multi-agent

7. Multi-agent: platform composition vs built-in subagent product

Aspect	KDCube ReAct v3	Claude Code
Built-in posture	React v3 itself is not presented as a hard-coded “coordinator spawns React workers” product feature. The platform composes multi-agent flows at the service/bundle/channel level.	Claude Code officially supports subagents with separate prompts, tool permissions, and context windows.
How composition happens	Separate agents, bundles, or workflows can subscribe to the same session/channel activity and react to it. Because channel subscribers can act during streaming, composition can be pre-completion, not only post-hoc.	Subagents are spawned by the main agent via the Task tool. Each subagent runs with its own prompt, tool permissions, and context window, separate from the parent. The parent agent coordinates results when each Task completes.
Shared collaboration surfaces	Agents can collaborate by contributing events onto the same timeline, because timeline contribution is a real runtime interface. They can also collaborate through ANNOUNCE, which has its own contribution interface and can therefore carry shared operational state between rounds, including compact current-turn live event state.	Claude Code collaboration is centered on its own subagent/session model rather than a shared hosted timeline plus ANNOUNCE contract.
What this enables	One agent can contribute progress, plan state, notices, or other event blocks to the timeline while another agent reads that evolving state. The same applies to ANNOUNCE when agents need to react to fresh, uncached operational signals immediately.	Claude Code subagents collaborate through Claude Code's own conversation and delegation model.
Timeline is not agent-only	The shared timeline can also be populated by external events such as alerts, feedback, followup-style signals, steer-style inputs, and other service or operator-originated events. Those controls are retained as real context, including preserved visibility through pruning and compaction, which is exactly why the timeline works as a real event bus for collaboration rather than just a memory transcript.	Claude Code's collaboration model is centered on its own product/session structures rather than a hosted shared event timeline that outside systems can also populate.
Why this matters	KDCube treats agent composition as platform architecture: comm, relay, APIs, bundles, storage, and execution runtimes are the coordination substrate.	Claude Code treats subagents as a feature of the coding agent product itself.

Infrastructure

8. Economics, remote control, and product hosting

Aspect	KDCube ReAct v3	Claude Code
Remote control	Built in by virtue of being a hosted service with APIs. Bundles extend the service API, can be reconfigured remotely, and their properties or versions can be changed centrally.	Claude Code is primarily a user-local product with its own local client workflows.
Accounting	Per-turn accounting, budget enforcement, and spend attribution are native platform concerns.	Usage visibility exists in Claude Code, but it is not the same as a multi-tenant platform economics engine.
Audit and storage	Timeline, turn log, binary and text artifacts, relay events, resolver-backed navigation URLs, and storage layers are all part of the hosted system model.	Local session continuity and local project state are the primary persistence model.
Custom UI and APIs	Bundles can expose widgets, operations, public APIs, admin APIs, scheduled APIs via @cron(...), tool surfaces, bundle storage-backed state, and custom communication flows.	Claude Code does not try to be a hosted bundle application platform.
Agent mix inside one app	A single bundle app can combine React, Claude Code, and custom self-made agents for different jobs. The app decides which agent owns which task and how they collaborate through the platform surfaces.	Claude Code can be one strong agent product, but it is not itself the hosted application shell that composes multiple agent runtimes into one product.

This is one of the places where KDCube is larger than “an agent framework.” A bundle can collaborate with a user through widgets and APIs, persist preferences or job definitions in bundle storage, and then execute recurring server-side logic later. The schedule may come from plain user-facing configuration, from a bundle-specific DSL, or from agent-assisted planning; the platform contributes the scheduling and exclusivity contract. The same app can also mix multiple agent runtimes instead of forcing one universal agent shape for every task.

@cron(
    alias="digest-rollup",
    expr_config="apps.news.routines.digest_cron",
    span="system",
)

Bundles can define scheduled hooks with @cron(alias=<job name>, expr_inline=<cron>, expr_config=<bundle property path>, span=process|instance|system). Either an inline expression or a config-backed expression may be used; if both are provided, the config-backed value wins. This makes it natural to build hosted scenarios where users maintain recurring jobs over time and the bundle executes them on their behalf.

Integration

9. Claude Code inside KDCube is an agent integration, not a tool wrapper

In KDCube, Claude Code is not integrated as “just another tool.” It is hosted as an agent with workspace policy, session policy, communicator-backed streaming, and accounting.

Aspect	KDCube Claude Code integration	Why that matters
Binding	The bundle creates a ClaudeCodeAgent for the current request context and binds it deterministically to user + conversation + agent name.	KDCube maps its own conversation model to Claude session continuity instead of treating Claude Code as a stateless subprocess.
Workspace	The bundle chooses the workspace root. KDCube can bootstrap Claude's session root locally or from a git-backed per-conversation session store.	This is how Claude Code continuity becomes hostable at scale across KDCube deployments.
Turns	KDCube exposes regular, followup, and steer shapes over the Claude runner, while keeping resume semantics tied to the stable Claude session id.	The integration is conversation-aware, not just “run one CLI prompt.”
Streaming	Claude Code deltas are translated into KDCube communicator events and therefore flow through the same SSE/Socket.IO/session relay infrastructure as the rest of the platform.	Claude Code becomes a native participant in KDCube messaging infrastructure.
Accounting	Model, usage, cache activity, and cost are captured as accountable LLM usage with runtime="claude_code".	The hosted Claude agent inherits KDCube's economics and observability model.

Features

10. Feature matrix

Capability	ReAct v3 / KDCube	Claude Code	Comment
Hosted multi-tenant runtime	Yes	No	This is core to KDCube and outside the main Claude Code product shape.
First-party local client UX	No	Yes	React is driven by the app/bundle; Claude Code ships with its own UX.
Timeline + ANNOUNCE + source pool	Yes	No equivalent	This is a foundational KDCube context model, not a thin prompt wrapper.
Skills subsystem with per-consumer filtering	Yes	Different product model	KDCube skills are explicit platform/runtime infrastructure.
Bundle-defined tools, widgets, and APIs	Yes	No equivalent	Bundles extend the service itself.
Bundle-defined namespace resolvers	Yes	No equivalent	Bundles can extend logical namespaces and teach React how to resolve bundle-specific refs.
End-to-end app bundles	Yes	No equivalent	Bundles are full app slices with frontend plus backend, not only prompt extensions.
Mix React, Claude Code, and custom agents in one app	Yes	Different product model	KDCube apps can compose several agent runtimes side by side and route tasks between them.
Scheduled bundle APIs (@cron)	Yes	No equivalent	Bundles can schedule app-owned logic with inline or config-backed cron expressions and process|instance|system exclusivity.
Storage-backed recurring scenarios	Yes	Different product model	Bundles can store user preferences or bundle-specific job DSL and execute them later through scheduled hooks.
Bundle-scoped custom @venv(...) helpers	Yes	No native equivalent	Selected bundle functions can run in cached custom Python environments layered on top of the platform runtime.
Isolated/distributed code execution runtime	Yes	No native equivalent	KDCube supports local isolation, Docker ISO, and Fargate execution.
Direct real filesystem editing	Indirect / explicit workspace activation	Yes	Claude Code is naturally stronger on direct local repo editing.
Per-user/project permission UI	App-defined	Built in	KDCube can expose it through the bundle client; Claude Code ships it natively.
Official subagents	Platform-composed multi-agent flows	Yes	KDCube composes at the platform level; Claude Code exposes subagents directly.
Mid-stream listeners that can act before completion	Yes	Not the same architectural contract	This is one of the sharpest KDCube differentiators.
Hosted Claude Code agent with accounting and workspace bootstrap	Yes	Not applicable to standalone Claude Code	KDCube hosts Claude Code as an agent, not as a plain tool.

When to use which