Zhipu to Offer a No-Retention Option on Its MaaS Platform

A workspace upload, then a policy note

The order of events is easy to follow. Developers examining ZCode found the tool bundles a user’s entire workspace and sends it upstream. Days later, in a Sunday evening post on its WeChat public account, Zhipu said its Model-as-a-Service platform would add a ‘no content retention’ feature. Enterprise and developer accounts can apply for it through the MaaS console. The announcement offered no date beyond ‘in the near term.’

The company’s wording is narrow: no static copy of what customers send to a model, or get back from it, will be kept. Data is used for the call in progress and for nothing else.

What the promise covers

The mechanics are simple enough. Prompts and generated results sit in server memory while inference runs, then disappear when the request completes. Nothing is written to disk, and nothing is folded into the corpus for later training runs.

Those two halves — no storage, no training reuse — are what enterprise buyers ask about first, often before benchmarks come up. The reasoning is practical. Code, logs, incident notes and internal documents are the material teams most want to hand a model as context, and also the material that needs a paper trail if it leaves the building. A tool that packages a whole workspace and uploads it compresses a set of vague worries into one concrete action, which is what made the ZCode finding circulate.

Worth separating too: zero retention describes how long data stays on the provider’s side, not who touches it. The platform still has to process the request. It just doesn’t keep the content afterward.

The two exceptions

Zhipu named two situations where retention happens anyway.

The first is storage the product cannot work without. Batch API and Files API are the examples given. Batch jobs have to wait in a queue before and between runs; the file interface exists so that files can be referenced across calls. Wipe everything the moment a request returns and neither can function. That is an engineering constraint rather than a policy choice, and in practice it becomes a question of which endpoints a given workload touches.

The second is compliance. Zhipu says it may retain data for 30 days or longer when national laws and regulations require it, or when it needs to investigate suspected abuse or violations of its terms of service. This one carries more weight. Thirty days is a floor, not a cap, and the two stated purposes cover a wide range of situations, so a customer cannot reliably predict when they would apply. Clauses like this tend to belong in a security review rather than on a product page.

What to check before turning it on

Zero retention answers a narrow question: whether prompts and outputs get persisted and reused for training. It says little about what happens while a request is in flight, or who inside the provider can see it in memory. Those concerns sit with other controls — access policy, audit logging, contractual terms.

For a team weighing whether to enable the feature, the useful part of Zhipu’s announcement is the edges, not the headline: which APIs fall outside the promise, how the compliance window is documented, and whether 30 days is negotiable in an enterprise agreement. Workloads built around batching or file handling will still leave data on the provider’s side by design, and that has to be priced in early. Those details decide whether a given workload can move onto the platform far more than a line about not storing user data.