Zeruoclaw Standalone Deployment Lacks Centralized Terminal Management List, Low Efficiency for Multi-Terminal Operation

[55144053]

Zeruoclaw is deployed as a standalone single-node instance on site with more than ten IoT terminals connected. The system does not provide a unified device list. Users have to log into each terminal separately to view data and adjust configurations, which leads to cumbersome switching operations and time-consuming manual verification and modification device by device.

It is recommended to add a unified terminal management page to centrally display the status of all Zeruoclaw terminals, support batch configuration and unified model management, so as to improve operational efficiency.

[Audacity88]

@55144053 thanks, this is useful deployment feedback. This fits the existing fleet/node management track rather than a separate new tracker.

The closest existing issue is #6346, which covers a unified node/device management surface: centralized node/device list, labels, health/status, dashboard management, and CLI parity. Two narrower follow-ups are #6390 for zeroclaw node add/list/remove and #6391 for real node heartbeat/status tracking.

Your “10+ IoT terminals” case is a good concrete validation point for that work. Before batch configuration or unified model management, the important first step is a reliable inventory and liveness source of truth: which terminals exist, which are online/stale/offline, and which daemon/node owns each one.

Could you add a little more detail here?

• Are these terminals separate ZeroClaw daemon nodes, or devices connected to one standalone ZeroClaw daemon?
• What status fields do operators need in the central list?
• Which batch operations matter most: config edits, model/provider selection, restart/reload, health checks, or something else?
• Does “unified model management” mean one model setting for all terminals, per-terminal overrides, or grouping terminals by role?

We can keep the main project tracking on #6346, but this discussion is a good place to capture the real deployment shape so the issue does not stay too abstract.

[55144053]

@Audacity88 Thank you very much for your reply. The process daemonization and low memory footprint features of ZeroClaw perfectly match the edge AI requirements of the terminal devices in my experimental project. The actual business requirements combine the capabilities requested in Ticket #6346 and Ticket #6390. Below are the Q&A details:

Q1: Are these terminals separate ZeroClaw daemon nodes, or devices connecting to a single shared ZeroClaw daemon instance?

A: We are currently running an experimental environment, and the production deployment will involve far more terminals. Our solution adopts independently deployed, isolated ZeroClaw daemon nodes running on each terminal.

This architecture is designed to fully leverage edge AI computing power to execute complete local business logic on-site. Once local processing is finished, only final results are uploaded to the central control platform, which significantly reduces data processing and transmission overhead on the central side.

The architecture is built based on the standard edge-agent paradigm with enhanced capabilities. Instead of being lightweight monitoring processes only responsible for device status collection and heartbeat reporting, these nodes retain full capabilities for local AI inference and autonomous offline business execution. If they were simplified to mere monitoring agents, core advantages of edge AI including low latency, offline self-operation and central computing offloading would be completely lost.

Q2: What core status fields do operators need to view on the central terminal list?

A:

1. Unique terminal ID / Device Serial Number / Device IP address
2. Online/Offline connection status + Timestamp of the latest heartbeat report
3. Currently active AI model and its corresponding model provider

Q3: Which type of batch operation carries the highest priority: configuration modification, model/provider switching, service restart/reload, health inspection, or other operations?

A:

1. Batch health inspection + bulk acknowledgment of fault alarms (Highest priority; core daily operation for operators to monitor overall system stability)
2. Batch configuration modification (for skills & tool modules) to adapt terminals serving different business scenarios
3. Secondary auxiliary batch operation: Batch cleanup of offline terminals

Rationale: Operators prioritize grasping the overall health status of all devices first. Root cause analysis will be triggered immediately once faults are detected. Fault recovery and minor configuration adjustments are routine tasks with lower urgency.

Q4: What does "unified model management" cover? Does it refer to one unified model setting for all terminals, per-terminal custom overrides, or terminal grouping by business roles?

A: Definition of Unified Model Management (3-Tier Hybrid Control Architecture)
This function supports all three management modes with hierarchical override priorities instead of a single fixed mode:

1. Global baseline configuration: A universal default model/provider configuration serving as the fallback for all ungrouped terminals (lowest priority).
2. Business role group override: Terminals are classified into groups by business scenarios with dedicated model configurations that overwrite the global baseline settings.
3. Per-terminal independent override: Exclusive model configurations for individual devices with the highest priority, overriding both global baseline and group-level settings.

Configuration priority (descending order): Per-terminal custom settings > Business group settings > Global unified default model settings.

Operators can freely adjust management granularity, including unified control over all devices, segmented group-based management, and independent customization for single terminals.

TOML Configuration Example

# Global unified baseline configuration (lowest priority, fallback for all ungrouped terminals)
[global.model_default]
provider = "deepseek"
model = "deepseek-v3"
api_key = ""
temperature = 0.7
max_tokens = 2048

# Business role group configuration (medium priority, overrides global defaults)
[[terminal_group]]
group_id = "follow_up"
group_name = "Terminal Group"
provider = "deepseek"
model = "deepseek-medical"
api_key = ""
temperature = 0.5
max_tokens = 1024

[[terminal_group]]
group_id = "consult"
group_name = "Terminal Group"
provider = "openai"
model = "gpt-4o-mini"
api_key = ""
temperature = 0.8
max_tokens = 3072

# Per-terminal independent override configuration (highest priority, overrides group & global settings)
[[terminal_override]]
sn = "TERM-20260704-001"
provider = "deepseek"
model = "deepseek-medical-pro"
api_key = ""
temperature = 0.3
max_tokens = 4096

[[terminal_override]]
sn = "TERM-20260704-002"
provider = "qwen"
model = "qwen-medical-long"
api_key = ""
temperature = 0.6
max_tokens = 2048

Hierarchical Configuration Loading Rules

1. When loading configurations, a terminal first checks whether a matching terminal_override custom configuration exists for its device serial number; if matched, this configuration takes effect directly.
2. If no per-terminal override is found, the terminal loads the configuration bound to its affiliated terminal_group.
3. If the terminal is not assigned to any group or its group has no dedicated configuration, the system automatically falls back to the global.model_default global baseline configuration.

Supporting Sub-Configuration for Model Providers

[providers]
[providers.models]
[providers.models.deepseek]
[providers.models.deepseek.default]
api_key = ""
model = "deepseek-v4-flash"

[Audacity88]

@55144053 thanks, this is exactly the kind of deployment detail that makes the node-management work easier to scope.

This confirms that the main target is a fleet of isolated ZeroClaw daemon nodes, not many passive devices behind one daemon. That matters because each terminal still needs to keep its local AI/runtime autonomy, while the central surface should give operators inventory, liveness, health, and controlled rollout tools.

I would route the pieces this way:

• [Feature]: zeroclaw node CLI + dashboard health & management (follow-up to #3448) #6346 remains the main fleet/node management issue.
• [Feature]: zeroclaw node add <url> CLI — register a remote daemon #6390 covers the zeroclaw node add/list/remove CLI path for registering daemon nodes.
• [Feature]: real heartbeat tracking for daemon nodes — derive Online/Stale/Offline from last WS message #6391 covers the liveness foundation: heartbeat, last_seen, and Online/Stale/Offline state.
• Your batch health inspection and alarm-ack workflow belongs under the [Feature]: zeroclaw node CLI + dashboard health & management (follow-up to #3448) #6346 health/operations surface once [Feature]: real heartbeat tracking for daemon nodes — derive Online/Stale/Offline from last WS message #6391 gives us reliable node state.

The model-management part is useful, but it needs a separate design pass before it becomes a config shape. The hierarchy you described makes sense as operator policy: global baseline, business-role group override, then per-terminal override. The key constraint is that ZeroClaw should not duplicate provider/API-key/model configuration in a second terminal-management table. The fleet policy should reference the canonical provider/model aliases and apply them to nodes through a clear ownership path, otherwise central policy and per-node config will drift.

So I would treat your TOML as a requirements sketch, not as the final schema yet. The requirements I would carry forward are:

• central list needs terminal ID/serial/IP, Online/Stale/Offline plus last heartbeat, and active model/provider;
• first batch operation priority is health inspection plus alarm acknowledgment;
• second priority is grouped skills/tools configuration rollout;
• model rollout needs three levels: global default, group override, terminal override;
• terminals must still be able to run complete local business logic offline.

That gives us a good implementation order: inventory and heartbeat first, then node registration/CLI parity, then batch health operations, then grouped configuration/model policy.

[55144053]

@Audacity88 Thank you to the R&D team for arranging the development schedule. We greatly anticipate the release of the new product iteration.