Over the past few days, three notable events emerged in rapid succession across the AI-assisted coding landscape. Desktop programming software from Zhipu silently scanned local code and complete version control histories in the background, bundling and encrypting them into a queue bound for cloud storage. Meanwhile, an independent benchmark swapped the outer execution harness while holding the underlying large language model fixed, revealing a twofold (~2x) difference in billing expenses. Elsewhere, a Microsoft engineering team showcased a practical prototype that restructured an architecture previously dependent on multi-model conversational loops into a single-model approach that directly ingests operational specifications.
These three events differ entirely in nature, each representing a security controversy, an empirical benchmark, and an architectural prototype. The quantitative figures making headlines actually measure only a specific, localized link within a complex system chain. No matter how high a task success rate appears on a benchmark dataset, it cannot answer how high actual bills will run in production; saving half the model calls does not necessarily mean total compute consumption is genuinely lower; and even if software claims to be open source or a model is deployed offline, that alone cannot guarantee private code never leaves the machine. When evaluating AI coding tools, discerning which processing layer a specific metric actually reflects is often far more critical than the magnitude of the number itself.
ZCode, a desktop coding assistant developed by Zhipu, performed two
things in the background: before every question you asked, it took a
complete snapshot of the entire project along with its history; and once
encrypted, this snapshot waited in a queue to be uploaded to Alibaba
Cloud storage. On 2026-09-18, independent developer ferstar published an
investigation report on ZCode, disclosing that the desktop client
silently packages and attempts to upload users’ workspace contents to
the cloud in the background. September 18 was merely the date the report
was publicly released to the community; the software had already
exhibited this behavior long before the report appeared. An examination
of deep data-flow traces reveals that as long as the client remains
logged in, it continuously runs a background upload channel alongside
routine conversational interactions. Whenever a user prepares to submit
a prompt, or when a task tagged with repo-wiki-update
finishes, the program performs a comprehensive scan of the current
workspace to generate a file manifest, compresses the whole package, and
applies standard encryption techniques. The decryption key remains in
the vendor’s cloud; neither you nor the local client software itself can
decrypt this file on your own hard drive. The resulting encrypted
archive then enters a local queue to wait, while the client requests
temporary credentials from the
zcode.z.ai/api/v1/snapshot/upload-credential endpoint,
bypassing routine business gateways to upload the file directly to
Alibaba Cloud Object Storage Service (OSS), before finally registering
it with the backend system via a callback. The entire upload logic
requires only a valid logged-in session, with no pop-up prompts or user
confirmation dialogs anywhere in the interface. Readers can verify the
primary evidence of these network calls in ferstar’s
published investigation report and the corresponding English
analysis.
Later, several developers discovered the same background activity on
their own computers. In feedback issue
#707 on GitHub, multiple developers successively posted packet
captures and directory inspection logs. Packet capture records on
the NodeSeek forum showed that a Windows user counted 32 workspaces
where snapshots had been generated on a single machine. In Elliot’s
forensic analysis of Mac version 3.12.3, snapshot directories
consumed 894MB of disk space in total, with version control directories
accounting for as much as 98.9% of the manifest. Meanwhile, the privacy
audit report from community tool zcode-tui completed a static audit
of Linux builds, confirming that this mechanism spanned all three major
desktop operating systems. The local encrypted archive awaiting upload
displayed by the researcher reached 313,070,842 bytes; faced with such a
large size, however, one must strictly distinguish: pending upload does
not equal already uploaded. The failureCount: 564 recorded
in metadata has two technical readings: ferstar interpreted it as 564
failed upload attempts for a single package, while Elliot, after
reverse-engineering the code, considered it an accumulated failure count
across tasks. Both readings record failed uploads, and neither
represents a successful upload (with up to 62 capture events recorded in
a single session lifecycle).
What raised even greater concern among engineering teams was the
specific distribution of content within the packaging manifest. In the
researcher’s own sample of the plaintext manifest listing 42,411 files
presented by ferstar, internal objects under the .git
directory accounted for 86.6%, which included 196.1MB of LFS cache
(56.8%), 102.2MB of Git object database (29.6%), and 0.6MB of reflog
commit backtracking logs (0.2%), while regular source code and
documentation from the active workspace actually made up only 13.4%.
These version history objects may contain unredacted credential
configuration files left behind in earlier commits, unpushed internal
feature branch names, and internal enterprise GitLab hosting addresses.
When encountering .git paths, the client program bypassed
sensitive keyword filtering rules entirely, and supplementary manifests
would even hitchhike ZCode global configurations across workspaces for
exfiltration. Many developers attempted to block this behavior through
client preference settings, but the
optimizeAgentExperienceEnabled toggle in the settings UI
controls only whether data is used for model training, and the
repoSnapshotIndexingEnabled toggle controls only whether
the server builds code indices against the snapshots. Both the author of
#707 and Elliot confirmed through empirical test logs that even if users
toggled both switches off in the interface, full local snapshots
continued to be generated as usual.
Regarding whether those encrypted snapshots ultimately reached the
cloud, three independent sources observed the
lastAcceptedManifestHash field in the client’s local
records. Reverse engineering confirmed that the client writes this hash
value only after a file has finished successfully uploading to OSS.
However, this remains a unilateral client-side write flag: a client-side
record does not equal a server-side receipt, and cannot be used to
confirm that the server has received and retained the files. In response
to intense community concern, according to IT Home’s report on the
official statement, the company attributed this pipeline to codebase
indexing features, stating that it was designed to support session
checkpoint recovery, historical version rollback, and Repo Wiki, while
claiming that once knowledge base pages are generated in the cloud,
“relevant uploaded data is destroyed immediately and will not be
retained.” The official statement explained that “this feature was
enabled by default during its initial rollout, causing some users to be
affected,” emphasized that “the relevant issue has now been fixed,” and
promised to open-source the client to the community, invite third-party
audits in the future, and provide affected users with a one-time weekly
quota reset.
A notable discrepancy exists between the vendor’s official narrative and the technical evidence currently in the public domain. The latest entry in the ZCode official changelog remains at version 3.12.3 dated 2026-09-17, containing no mention whatsoever of fixes regarding snapshot packaging or privacy logic. The only publicly available text in official materials touching on snapshot transmission appears in the Linux x64 latest.yml manifest built on 2026-09-16, where the bug fixes section notes “optimized memory usage for repository snapshot uploads”—a performance tuning for memory overhead rather than a declaration disabling or shutting down the upload feature. Statements claiming immediate destruction of cloud data likewise lack any independent third-party verification, while the official ZCode Repo Wiki documentation mentions that Wiki uses a dedicated reading view and scans files independently of other features, which conversely substantiates the presence of multiple parallel file-scanning paths inside the system. A review of all 52 open-source repositories under the zai-org organization on GitHub reveals no open-sourcing of the client codebase itself; official personnel have provided no manual replies across the four GitHub feedback threads #707/#709/#711/#715, and the current privacy policy lacks explicit disclosure of snapshot uploading behavior. Divergent samples also exist in community reports: for instance, the feedback record from Hacker News user weiran shows that prolonged usage never produced any snapshot directories locally, and Linux user zax0rz similarly reported never triggering the packaging process, indicating that this behavior did not affect every single device. Auditing programming tools demands step-by-step verification along network request and file I/O paths: “not used for training” and “not indexed” neither individually nor together imply “not uploaded.” Key observation points left for the future include when the vendor’s fix logic will appear in official versioned release notes, whether independent third-party validation certificates can be produced for cloud data destruction, the progress on fulfilling the client open-source pledge, and a definitive ruling from an external independent security agency on the precise semantics of failureCount.
Where do mature harnesses like Claude Code and Codex actually outperform minimalist agents, and what are users really paying for? The widespread default expectation is that complex engineering designs should translate into superior task performance. On 2026-09-16, the Arena blog and the project team jointly released the HarnessTax comparative benchmark, launching the project homepage on the same day and sparking a high-profile discussion on Hacker News that scored 209 points. Data published by the authors provides a direct answer: plugging the exact same underlying model, Claude Fable 5, into the official Claude Code and the minimalist Pi harness to run the identical 30 code-repair tasks yielded virtually identical scores (97.8% vs. 96.7%), yet the average cost per attempt differed by about 2x (~2x, $1.33 vs. $0.67). Providing only four basic tools—read, write, edit, and bash execution—without heavy preset context or supplementary features, Pi matched the performance stride for stride.
This study was not confined to a single pair. The team plugged seven mainstream models into three frameworks (Claude Code, Codex CLI, and Pi), testing 30 tasks repeated 3 times each across two standardized benchmarks—SWE-bench Lite (focused on code repair) and Terminal-Bench 2.0 (focused on terminal operations). All frameworks ran in their official, native default configurations under high-effort mode with a per-run cap of 100 turns, yielding 21 combinations in total; turn definitions were not unified across frameworks, and strict network isolation was explicitly deployed in only one of the two benchmarks. Even more surprising was the pairing dynamic between models and their first-party frameworks: the authors noted that “your Claude models may not need Claude Code,” with the highest success rate across twelve comparisons spanning six Anthropic and OpenAI models on two benchmarks occurring on a third-party harness in nine out of twelve cases, directly answering whether developers truly need to pair official models with official harnesses.
Was this $1.33 spent only when successfully solving a task? Far from it. This figure represents the per-attempt expense calculated under the 2026-09-01 official price list with failed attempts amortized in; it is divorced from subscription pricing, is not a cost-per-successful-task, and excludes enterprise administrative overhead. Thicker initial rules and instructions serve as a candidate explanation but lack causal ablation, and a difference of 1.1 percentage points cannot be asserted as statistically significant nor equivalent.
One cannot rashly conclude from these numbers that complex frameworks are useless. The authors explicitly outlined their research boundaries: evaluations were conducted on only two public benchmarks, which may have contaminated training sets; when facing hard challenges at the frontier of model capability (such as scientific discovery work cited by the authors), complex harnesses with stronger structured scaffolding may still be indispensable. Furthermore, values that benchmarks cannot capture—such as administrative management and cross-session collaboration—are by no means rendered worthless by this study. As the authors concluded: “Harness choice has little effect on task success rate, but can significantly affect the cost on the benchmarks we test.” The critical follow-up observation point lies in when the full profiling traces promised by the authors (the original text states they “will publicly release our profiling traces,” which as of 2026-09-17 remains a public commitment) will be officially opened for download to scrutinize every detail.
In the architectural design of multi-model collaboration, engineering teams often intuitively assume that reducing orchestration tiers inevitably lowers overall resource consumption, yet real-world engineering measurements frequently reveal the exact opposite. On 2026-09-16, Microsoft Cloud Solution Architect Tommaso Stocchi published an in-depth technical post on the official Microsoft developer blog titled “From Specialist Agents to Distributed Skills over MCP,” reviewing the architectural evolution of a ski resort advisory agent based on his ski resort advisory system code committed to GitHub on 2026-09-10. The original system was built on an Agent-to-Agent (A2A) architecture: upon receiving a composite query from a user, the primary concierge model dispatched domain-specific tasks to remote specialist services. In the legacy design, each remote specialist service was a sub-agent with its own embedded model loop. Taking the weather specialist as an example, after the concierge dispatched the query, the weather specialist’s internal model first analyzed intent and decided which meteorological tool to invoke; once meteorological data was fetched, the specialist model synthesized the response, generated a summary, and sent it back to the concierge. For a single user inquiry, the old system frequently had to trigger 6, 6, or even 7 independent large language model calls sequentially.
The new solution refactored the entire system into a distributed skills architecture. Four domain services remained independently deployed remotely, with their underlying business logic code and data query interfaces fully preserved; the key change was removing the model inference loops previously embedded inside each specialist. Each distributed service exposed three standardized assets to callers: a one-line skill index concisely summarizing its capabilities, a Markdown operation manual named SKILL.md, and a set of tool definitions following the Model Context Protocol (MCP) with strict parameter schemas. When handling a user inquiry, the concierge model read the index summaries of each service in the first call to identify the service modules needed for the task; the host application then pulled the corresponding manual via protocol and dynamically registered the full suite of tools exposed by that service; in the second call, guided by the manual, the concierge issued standardized instructions to invoke tools and fetch business data; by the third call, the concierge integrated the returned structured data to produce final recommendations. Model calls for the same advisory task were compressed from a typical 6 down to 3 (6→3). What the refactoring truly eliminated was merely the intermediate model reasoning inside each specialist previously used to decide what to query and how to phrase output, leaving business code, deployment locations, and data queries untouched; for the open-ended web research agent, both old and new designs retained it, demonstrating that multi-step exploratory tasks remain well-suited for dedicated models. In the subtitle, the author emphasized the core design principle: “Keep your domain services distributed. Move the specialist’s instructions, not another model, into the orchestrator.” As the author wrote in the blog: “A distributed skill is not an agent wrapped in Markdown.” The collaboration paradigm transformed accordingly: the primary model gained direct access to operational tools and business guidelines rather than “delegating a task to another reasoner versus giving the current reasoner a competence and access to its operations.”
The author ran paired tests using three identical queries, uncovering two metrics that diverged in opposite directions. Facing identical advisory questions, the legacy architecture required 6, 6, and 7 model calls across the three test pairs, while the new architecture steadily held at 3 calls; end-to-end average latency dropped from 15.480s to 6.348s (15.480s/6.348s), cutting overall waiting time by more than half. In terms of total token consumption, however, the old architecture consumed a total of 11,134 tokens across the three trials, whereas the new architecture reached 13,533 tokens (11,134/13,533)—an increase of about 22% (+22%) in total token usage. The author emphasized this in bold in the blog: “It did not use fewer total tokens.” One plausible explanation is that stuffing previously distributed domain manuals into the primary model’s context forces every subsequent interaction turn to carry the penalty of this bloated context overhead. Nor did the author shy away from the experiment’s limitations, explicitly pointing out that “This is a three-pair illustration, not a controlled performance or quality study.”
When addressing system security and protocol specifications, this
architecture marks equally unambiguous boundaries. Loading an
instruction manual into an LLM’s context is by no means equivalent to
granting execution authorization to the system; the system reading
instructions is a process of progressive disclosure of
information—loading is not authorization (“Loading is progressive
disclosure, not authorization”). The sample code was able to
automatically register tools upon loading without confirmation approvals
only under the premise that all tools in the demo were read-only query
operations; the project documentation explicitly warned that “adding
write operations requires revisiting approvals.” In terms of concrete
protocol implementation, the skill discovery mechanism relied upon by
the sample code was based on skill://index.json and
skill://<name>/SKILL.md, paths originating from the
earlier SEP-2640 draft specification; the final specification merged on
2026-09-13 switched entirely to skills/list and
skills/get interfaces, with the legacy protocol URI schemes
no longer appearing in normative definitions, meaning developers must
verify the evolution of interface specifications before adoption.
Deciding whether to deploy an independent specialist model or an
instruction-based skill hinges on whether a scenario’s decision
complexity involves divergent multi-step exploration or convergent
single-turn querying, as well as trust boundaries and rule update
frequencies between services. The core takeaway this architecture leaves
for the engineering community is whether repeatedly stuffing vast
external specifications back into a single primary model can withstand
ballooning context costs while maintaining reasoning accuracy as tool
registries and rule manuals expand aggressively.
An encrypted snapshot packed an entire version control history and attempted background delivery to cloud storage. A framework evaluation swapped outer execution harnesses and found virtually identical task success rates, yet uncovered a ~2x difference in billing costs. An architectural redesign eliminated intermediate specialist models, halving call counts and latency, yet increased total token consumption by more than 20% (+22%).
None of the numbers are false, but each number answers only the question posed at its own stage. Discerning exactly which segment of the chain a metric measures is far more substantive than staring at the number in isolation.