NetLogo / NetLogo/Netlogo-LLM-Extension

feat: response caching for repeated prompts

Open
#54 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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

  1. Define the cache key: model + provider + full message sequence + temperature + max_tokens + thinking config. Anything affecting output must be in the key.
  2. Decide scope and lifetime — in-memory per session, or on-disk across runs (on-disk is what makes sweeps benefit).
  3. 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.
  4. 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.
  5. Eviction policy and size cap.
  6. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.