Scheduled LLM curation is the least glamorous agent workload you run.
A cron job wakes up at 3am, reads a pile of memory, asks a model to dedupe it, summarize it, re-rank it, and writes the result back.
Nobody is watching.
There's no chat window, no streaming tokens, no human to click a button.
It just has to work, quietly, every night.
That "nobody is watching" part is exactly what makes the cloud-versus-local decision harder than it looks.
When you have a human in the loop, a failed API call throws an error you can see and retry.
In a headless cron context, the same failure turns into a job that hangs on an approval prompt no one will ever answer, or a pod that curated three months of context into an that vanished on restart.
I've run curation both ways: nightly jobs hitting a hosted API, and the same logic pointed at a local model on my Kubernetes cluster.
Both work.
They fail differently, cost differently, and demand different things from you operationally.
Here's the actual tradeoff, not the marketing version.
The decision point You reach this fork once your agent memory stops being a toy.
Early on, you curate by hand or with a cheap synchronous call inside your agent loop.
Then the memory grows, the curation gets expensive, and you pull it out into a scheduled job so it runs off the critical path.
Now you're paying an API on a timer, and two things start to bug you.
First, the data.
Curation reads your entire memory store to make decisions.
If that memory contains anything you'd rather not stream to a third party (internal notes, customer context, infrastructure details), every scheduled run ships it over the wire.
I wrote about the general version of this problem in privacy-routed LLM inference, and scheduled curation is the workload where it bites hardest, because it touches everything, repeatedly, forever.
Second, the cost shape.
A curation pass over a large vector store is a lot of tokens for a job that produces no user-facing latency benefit.
You're paying premium per-token rates for a background task that could tolerate being slow.
Local models answer both.
They also hand you a completely new category of operational problems.
That's the trade.
Option A: Cloud APIs A hosted API for curation is the path of least resistance.
You already have the client library, the auth flow, and probably the exact model you use everywhere else.
Point your cron job at it and you're done in an afternoon.
Where it shines.
Quality and zero infrastructure.
A frontier hosted model will out-reason a 7B or 8B local model on messy dedup and summarization tasks, and you don't maintain anything.
No GPU, no node affinity, no image pulls.
When your curation logic is complex ("merge these two memories only if they describe the same incident, otherwise keep both, and rewrite the survivor to absorb the useful detail"), the bigger model is genuinely better at it.
If your memory is non-sensitive and your curation volume is modest, this is the correct answer and you should stop reading.
Where it hurts.
Three places.
The token bill scales with your memory size, and memory only grows.
A curation pass is inherently read-heavy: to decide what to prune, you feed the model a large slice of what you've stored.
That's a lot of input tokens on a recurring schedule.
Every run exports your data.
There's no way around it.
If the curator reads a memory, that memory left your network.
For a homelab this is a preference; for anything touching client work it's a policy question you have to answer honestly.
And the failure mode is retry-and-pray.
Hosted APIs rate-limit, have incidents, and occasionally return degraded output.
Your 3am job is at the mercy of someone else's uptime.
That's usually fine.
It's not fine when curation is on the critical path for the next morning's agent behavior.
Model transitions add a smaller, sharper annoyance.
Moving between provider model versions (say a to style bump) sometimes forces an OAuth re-authentication to unlock specific tool c