> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anonalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# A shelf of standing questions

> Not one self-updating briefing — a dozen, listed, edited, cleared and retired as the work moves.

[← All use cases](/use-cases/overview)

<div className="uc-examples"><a className="uc-api" href="/api-reference/models">API reference</a></div>

## The scenario

[A briefing that keeps itself current](/use-cases/self-refreshing-briefing)
covers making one. In practice you end up with a dozen — one per account, per
service, per ongoing question — and then you have a collection to manage rather
than a document to read.

**What this recipe shows that no other does:** the full lifecycle of memory
models, including the two operations people reach for late and wish they had
known about — clearing content without losing the definition, and editing the
question without rewriting the answer.

## Step 1 — See the shelf

```python theme={null}
shelf = client.list_memory_models(space_id="accounts", limit=50)
for m in shelf["items"]:
    flag = "stale" if m["is_stale"] else "current"
    print(f"{m['name']:30} {flag:8} {m['last_refreshed_at']}")
```

`is_stale` across the whole shelf is the view worth having: it tells you which
standing answers have drifted from the memories underneath them.

## Step 2 — Group them with tags

```python theme={null}
client.list_memory_models(space_id="accounts", tags=["quarterly"])
```

## Step 3 — Sharpen the question without losing the answer

```python theme={null}
client.update_memory_model(
    space_id="accounts",
    model_id=mid,
    query="What is blocking the Acme renewal, and who owns each blocker?",
)
```

Editing the definition deliberately does **not** trigger a rewrite. Refreshing
costs credits, and most edits are a sharpened question or a typo — you choose
when to pay.

## Step 4 — Clear content, keep the definition

```python theme={null}
client.clear_memory_model(space_id="accounts", model_id=mid)
```

This is the one that is hard to discover and exactly right after a correction:
when the underlying memories were wrong and have been
[superseded](/use-cases/correct-a-memory), the model's text is built on the old
belief. Clearing wipes the answer and keeps the question, so the next refresh
starts clean rather than editing its way out of a wrong premise.

## Step 5 — Retire it

```python theme={null}
client.delete_memory_model(space_id="accounts", model_id=mid)
```

Delete really deletes — it is not an alias for clear. The definition goes too.

## Evals

1. Create three models, refresh them, confirm all three read `current`.
2. Write a memory that contradicts one. Only that one should turn `is_stale`.
3. Clear it, then read it — content gone, name and query intact.
4. Refresh and confirm the new text reflects the correction rather than
   blending it with the old answer. Blending is the failure that clearing exists
   to prevent.

## Guardrails

<Warning>
  **Refresh costs credits and is charged when submitted, not when it succeeds.**
  A shelf of twenty models on `refresh_on_new_memories` over a busy space is a
  standing bill. Trigger on the cadence you actually read them.
</Warning>

* **A newly created model has no content** until its first refresh completes.
  Render that state rather than an empty string that reads like an answer.
* **Deleting is owner-only**, like every other space-configuration call.
* **Stale is not wrong.** It means the memories moved, not that the text is
  false — often it is still the best answer you have.
