Memoized CrewBase methods retain per-instance Agent/Task/Crew in global cache

[suqinghen]

Summary

When @agent, @task, and @crew are used on a CrewBase class, memoized method results are stored in a module-level cache. Repeatedly creating new crew instances (for example, per request) leaves each instance's generated Agent, Task, and Crew objects strongly referenced in CacheHandler._cache, so process memory grows with request count.

Affected versions

• Confirmed in 1.15.2
• Re-checked in 1.15.20 (wheel/source) and still present

Evidence in current implementation

• crewai.project.utils defines global cache = CacheHandler()
• crewai.project.annotations wraps agent, task, crew decorator outputs with memoize(...)
• CacheHandler uses an internal plain dict without TTL/size bounds and stores entries as strong references

Reproduction (minimal)

1. Define a CrewBase class with at least one @agent, @task, and @crew method.
2. In a loop, create many new crew instances and touch cached methods.
3. Inspect cache._cache and object liveness after gc.collect().

Expected: old instance results can be reclaimed when user code drops references.
Observed: results remain in cache even after instance refs are removed.

Why this breaks long-running services

Some services build crews per request for isolation. Under steady request flow this cache behavior causes global accumulation of per-instance runtime objects (including nested clients and state), and RSS continues to rise across completed requests.

Suggested fix direction

• Make memoization cache scoped to the CrewBase instance rather than module scope, or
• Add an explicit invalidation/lifecycle API for CrewBase-bound memoized values, and call it when crews are discarded, while preserving backward compatibility for existing singleton-style usage.

If this behavior is expected for static class-like usage, documenting it would still help; however this makes per-request crew construction unsafe for memory-bounded processes.

[suqinghen]

We're using CrewBase in a web server (FastAPI)

[modelpath-dev]

I will take this issue. Please assign it to me.

The problem is that memoized results for @agent, @task, and @crew are stored in a global cache, leading to memory growth. I will first examine crewai.project.utils and crewai.project.annotations to confirm how memoize(...) interacts with CacheHandler. My plan is to scope the cache to each CrewBase instance. This should allow old instance results to be reclaimed when no longer needed. I will test this by creating and discarding multiple crew instances and verifying that memory usage stabilizes.