AIClaw already had one of the more useful operational surfaces in a self-hosted agent runtime: execution steps are not hidden behind a raw trace file or an opaque debug mode. They are part of the product.
The latest repository change, fix: localize execution step labels, improves that surface in a practical way. The chat view and the execution log view now render more of the plan and step metadata through the shared i18n layer instead of hard-coded mixed-language labels.
Project: https://github.com/chowyu12/aiclaw
Why this matters
A lot of agent products can show you a final answer. Fewer are good at showing what happened between the prompt and the answer:
- which plan item was running;
- which tools were called;
- what input a tool received;
- what output came back;
- how long each step took;
- where channel-specific metadata came from.
AIClaw has already been shipping that execution detail in both chat and the dedicated logs page. The new localization pass makes the same information more readable for operators switching between Chinese and English UI modes.
That is not cosmetic in the trivial sense. If a product wants execution logs to be part of normal operations, the labels around those logs have to be consistent.
What changed in the current repo
Today’s commit touches three frontend files:
web/src/stores/i18n.tsweb/src/views/chat/Index.vueweb/src/views/log/Index.vue
The concrete change is straightforward:
- move execution-step labels, plan labels, timing labels, file labels, and log-table labels into shared translation keys;
- remove hard-coded strings from the Chat page and Logs page;
- keep the execution-step structure the same while making the UI language-aware.
Examples of newly localized UI copy include:
- execution step counts;
- total duration;
- child step counts;
- started / ended / duration timestamps;
- input / output / error section labels;
- channel labels;
- untitled conversation fallback text;
- execution log table headers and empty-state text.
So the feature story here is not “AIClaw added logs today.” The real story is that AIClaw’s existing execution-log workflow became easier to operate in multilingual environments.
The bigger design behind it
This repository is opinionated about observability.
From the current README:
- AIClaw persists conversations, execution steps, generated files, and plan state.
- The web console includes chat and execution logs.
- Tool output is visible through execution steps instead of disappearing into an internal harness.
That design shows up directly in the UI:
- the final assistant message can carry a plan snapshot;
- execution steps can be expanded under a reply;
- tool-only intermediate rounds are hidden from the normal timeline to reduce noise;
- the detailed step trail still remains accessible under the final reply and in the dedicated logs view.
This is a good operational choice.
If every internal tool round is dumped directly into the visible conversation stream, the chat becomes hard to read. If those rounds are hidden completely, debugging becomes painful. AIClaw splits those concerns:
- the conversation stays readable;
- the execution trail stays inspectable.
What you can actually inspect in AIClaw
In the current product, execution steps can expose details such as:
- step type, such as LLM, Tool, Agent, or Skill;
- tool name, including special handling for
web_search; - step status;
- duration;
- input;
- output;
- error text;
- provider and model metadata;
- channel metadata;
- nested sub-agent depth and child steps.
That means the logs are useful for more than debugging crashes. They help answer normal operating questions:
- Why did this answer take 18 seconds?
- Did the agent use external web search or a normal tool?
- Which sub-agent branch produced the result?
- Was the failure in the LLM call, the tool call, or the surrounding workflow?
Why I picked this topic for today
There is a concrete new commit behind it, but it also points to a broader product surface that deserves a deeper article: AIClaw treats execution logs as a first-class UX, not as an afterthought.
Recent AIClaw writeups already covered configurable web search, the built-in scheduler, generated file attachments, and Runtime Plan State. Today’s change is a good reason to focus on another core surface in that rotation: tool execution logs and operator-facing observability.
A practical example
Imagine an agent that:
- receives a prompt from web chat or a messaging channel;
- creates a small runtime plan;
- calls
web_search; - delegates a verification task to a
sub_agent; - returns a final answer with attached artifacts.
In AIClaw, the operator can inspect that run without reading backend code:
- the plan panel shows which item ran and which item failed or completed;
- the execution steps show tool inputs and outputs;
- the logs page lets you inspect the same conversation later;
- language-aware labels reduce friction for multilingual teams.
That is the kind of product detail that determines whether an agent system is usable in real operations.
The takeaway
The newest AIClaw commit is small in scope, but it improves an important part of the platform: the execution-log interface that operators actually use when they need to understand agent behavior.
If you care about self-hosted agents, the interesting thing is not just that AIClaw can run tools. It is that AIClaw keeps those tool runs visible, structured, and now more consistently localized across the main inspection surfaces.
Install or update:
curl -fsSL https://raw.githubusercontent.com/chowyu12/aiclaw/master/install.sh | bash
Top comments (0)