NetLogo / NetLogo/Netlogo-LLM-Extension
feat: response caching for repeated prompts
Nobody has claimed this yet.
- Dominant language
- Scala
- Stars
- 1
- Forks
- 0
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 4
Description
Roadmap priority: B5
Summary
Return a cached reply for an identical prompt + model + parameters combination, instead of re-calling the provider.
Why it matters
BehaviorSpace parameter sweeps repeat prompts heavily — the same system prompt and the same early-tick observations recur across every run in the sweep. Each repeat is currently billed and waited on again. Caching is a direct cost and wall-clock saving for exactly the workflow researchers use most.
Note: mesa-llm has no caching at all (verified — grep for lru_cache|redis|memoize across their package returns zero hits), so this is a differentiator rather than catching up.
What needs to be done
- Define the cache key: model + provider + full message sequence + temperature + max_tokens + thinking config. Anything affecting output must be in the key.
- Decide scope and lifetime — in-memory per session, or on-disk across runs (on-disk is what makes sweeps benefit).
- Opt-in config key (
enable_cache), off by default. Caching changes semantics for any model relying on sampling variation, so it must never be silently on. - Interaction with
temperature > 0— cache hits eliminate the intended randomness. Either refuse to cache when temperature is non-zero, or make that an explicit modeler choice. - Eviction policy and size cap.
- Optional: report hit/miss counts so the saving is visible.
Open questions
- On-disk cache location — model directory, or a user-level cache dir? Model directory is more portable for sharing a reproducible run.
- Does this overlap enough with record/replay to be one feature? (See B6.) Replay is exact-sequence playback; caching is content-addressed. Related but not identical.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by tracing the provider call and configuration path, then compare the proposed cache scope with the record/replay feature in B6. Done means an opt-in cache has a complete key, defined lifetime and eviction cap, explicit temperature behavior, and optional hit/miss reporting without changing default behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100