Generative Agents Behavior Simulator
A notebook-based, locally runnable simulation of human-like behavior in a D&D town setting.
- Source repo
- mkturkcan/generative-agents
- Stars
- ★ 997
- Last updated
- 1y ago
- License
- MIT
- Primary language
- Jupyter Notebook
- FA score
- 36/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free, no paid service needed
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- A researcher with local GPU hardware who wants to run an implementation related to the model type described in the Generative Agents paper.
- Not a fit if
- Users without a 16GB-VRAM GPU or local GPU
- Teams needing documented install steps and dependency versions
- Teams needing an API, CLI, or production deployment interface
- Source review
- 36/100 · Major gaps 4 safety controls not found
What does this agent do, and when should you use it?
This is a working implementation of the kind of model described in Generative Agents: Interactive Simulacra of Human Behavior. It is distributed as notebooks that can run locally or on Google Colab, with JupyterLab recommended for local use. The stable model is in notebook/Release, work-in-progress models with newer features are in notebook/WIP, and a WIP library is under game_simulation. The current model simulates Phandalin, the town from an introductory D&D 5e adventure, using a setting described as more free-form than the paper's simple scenario. It uses lower-parameter, locally runnable models to address the cost of high-quality instruction models and many long-context queries, while noting that future instruction-tuned models are expected to perform better.
A user selects a notebook from notebook/Release or notebook/WIP and runs it locally or in Google Colab. The model runs a simulation of the town of Phandalin, aiming to model the kind of human-like behavior described by the paper. A WIP library is also available under game_simulation. The supplied material does not identify notebook filenames, inputs, prompts, model calls, cell order, or output artifacts, so those end-to-end details cannot be verified.
- A researcher with local GPU hardware who wants to run an implementation related to the model type described in the Generative Agents paper.
- An experimenter who wants to try the notebooks in Google Colab instead of deploying a service.
- A prototype developer studying simulated behavior in the more open-ended Phandalin setting from an introductory D&D 5e adventure.
- A user who wants to start with a stable version and compare notebook/Release with notebook/WIP when newer features matter.
- An experimental team constrained by the cost of high-quality instruction models and long-context queries that wants to explore a lower-parameter local-model approach.
How do you install or deploy this agent?
No copyable installation commands, dependency list, model acquisition method, environment versions, or credential requirements are provided. The documented execution boundary is that notebooks run locally or in Google Colab, JupyterLab is recommended for local use, and the notebooks should work as-is in Google Colab. A reproducible setup still needs the specific notebook filename, dependency installation steps, model-file source, and first-run workflow.
How do you use this agent?
Choose the model described as most stable in notebook/Release, or choose a newer WIP version in notebook/WIP; open and run the applicable notebook in local JupyterLab or Google Colab. A WIP library is also available under game_simulation. The material does not document a first notebook, command, parameters, or cell execution order, so no more specific verified invocation can be supplied.
What are this agent's strengths and limitations?
- Documents two notebook execution paths: local runs and Google Colab.
- Separates a stable release, newer WIP notebooks, and a WIP library across notebook/Release, notebook/WIP, and game_simulation.
- Uses the Phandalin D&D setting, described as more free-form than the paper's simple scenario.
- Explicitly uses lower-parameter locally runnable models to address the cost of high-quality instruction models and long-context queries.
- The current version works best with 16GB VRAM; although sub-8GB VRAM environments are supported, no performance or feature trade-offs are documented.
- No installation commands, dependency versions, model-download method, credentials, or notebook execution sequence are provided.
- The material acknowledges room for improvement in the current lower-parameter local models and expects future instruction-tuned models to perform better.
- There is no verifiable documentation of an API, CLI, evaluation results, output format, or production deployment interface.
How does this agent compare with similar options?
The material contrasts this project with the paper's approach, which requires a high-quality instruction model such as GPT-3 and many long-context queries: this implementation instead uses lower-parameter, locally runnable models to reduce running cost.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Generative Agents Behavior Simulator This agent | 36 · Major gaps | Library / SDKFree | ★ 997 | 1y ago | Jupyter Notebook | — |
| Gyoshu Research Lab | 44 · Major gaps | Agent plugin / skillFree + model costs | ★ 243 | 8mo ago | TypeScript | Claude Code |
| Concordia: A Library for Generative Social Simulation | 62 · Some gaps | Library / SDKFree + model costs | ★ 1.9k | 4d ago | Python | — |
| Open Science Workbench | 81 · Good | Desktop appFree + model costs | ★ 5.5k | today | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The source shows a local simulation loop and model-generation entry point, but main.py enables OpenAI by default. It provides no visible permission controls, call-time confirmation, data-handling explanation, sensitive-data safeguards, or rollback mechanism, so those areas lose points. The code writes simulation_log.txt without clearly describing what may be sent to an external service. The MIT license names a copyright holder, but publisher identity and a maintenance route are unverified, so attribution evidence is limited.
The README distinguishes Release from WIP and states VRAM requirements, but invalid rating responses are simply set to zero and no exception handling or clear failure messages are shown. Dependency availability guidance is limited, and the README's local-running guidance lacks concrete installation steps, so these criteria receive partial credit.
The README identifies the Phandalin/D&D scenario, Colab and local use, and multiple VRAM environments, giving some evidence for scenario and environment fit. The code is organized around a single simulation loop and configuration file, with little explanation of boundaries or extension. The README does clearly distinguish the stable and WIP entry points.
The README is organized into setup, usage, model, limitations, and future steps, and the license file is complete. Setup is only described in broad terms, without dependencies or concrete steps. The security policy remains a template, including uncustomized supported-version and vulnerability-report sections; no changelog or clear maintenance owner is shown, so those criteria lose points.
The simulation generates character plans, actions, and memories, with summaries and logs, but logging is selective by default and the README gives no result format or downstream-use guidance, limiting output usability. Lower-cost local models are an explicit benefit. However, main.py sets use_openai=True, and the loop performs repeated generation and rating calls, leaving actual cost-benefit uncertain.
The README connects the project to a paper and a specific scenario, and states model and VRAM limitations, but the supplied material does not independently corroborate those claims. The code shows the simulation flow and log writing, but no checkable run results or executed verification are supplied. The security policy's version table and reporting instructions remain placeholder text, weakening the separation of established facts from claims.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: sensitive-data handlingUse dedicated, low-privilege, revocable API keys — never production credentials — and keep secrets out of logs.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- main.py enables OpenAI by default; do not assume all generation remains local without checking model-call and data-flow configuration.
- SECURITY.md still contains template text and gives no actionable vulnerability-reporting route or reliable supported-version information.
- The README does not list dependency installation steps, and the supplied material includes no run results to substantiate cost or model-performance claims.
FAQ
What hardware does it need?
Can I use it in the cloud?
Does it require API keys or an external model service?
Should I choose the release or WIP version?
What output format does it produce?
Thanks — we use this to improve the page.