LAB-103AgentsOngoingUpdated 2026

TamaBench — Small Models, Long Horizons

A lightweight benchmark that puts a small or local model in a persistent virtual-pet sandbox. The agent must plan across three simulated days, use structured tools, manage money and supplies, and recover when delayed consequences go wrong.

Open source repository

Hypothesis

A focused automation harness can extract more useful autonomy from a small model by reducing unnecessary wake-ups, tool calls, tokens, and compute without changing the model itself.

Test Setup & Hardware Specification

Evaluation RigLocal consumer hardware; a CPU-only episode is designed to finish in under five minutes
Environment ParametersPython 3.11+ project using Ollama or an OpenAI-compatible API, seeded random events, an event-driven simulation engine, and rule, raw-LLM, and Harness V1 agents.

Methodology & Execution

Compare a rule baseline, a raw model, and the same model wrapped by Harness V1. Record survival, schema compliance, planning and resource failures, API calls per day, tokens per day, and latency while keeping the model, prompt budget, scenario, and seed fixed.

Observations

The repository has a working event-driven runtime, JSON/schema validation, SQLite and JSONL logging, reasoning traces, reference and accelerated modes, and a DECIDE → CALCULATE → SCHEDULE harness. The current result rows are still marked TBD, so this note treats the benchmark as an instrument rather than a leaderboard.

Known Limitations

The project is an early research preview: APIs and scoring may change, v0.1.0 results are not cross-version comparable, and the repository does not yet include a multi-agent runner or result dashboard.

Reproduction Script

Execute this command in your local environment using the Cheva test harness:

reproduce_experiment.shbash
1python -m tamabench.cli run --agent harness_v1 --model <your-model> --episodes 1

Full Research Report

TamaBench — Small Models, Long Horizons

The project

TamaBench is a lightweight benchmark for small and local language-model agents. It places an agent in a persistent virtual-pet sandbox where actions have delayed consequences.

The pet is the simulation mechanism. The actual subject is long-horizon autonomy: observing state, planning, calling tools, managing resources, recovering from failure, and continuing after the model's last decision.

What the agent has to survive

Across three simulated days, the agent must:

  • feed, clean, heal, and play with the pet;
  • earn money through jobs before buying supplies;
  • balance its own energy against the pet's needs;
  • respond to random sickness events;
  • produce valid structured actions;
  • plan around time that keeps moving while it sleeps, works, or waits.

This creates pressure that ordinary question-answering benchmarks do not create. A response can be fluent and still fail because it chose the wrong priority, used invalid JSON, waited too long, or spent resources it could not replace.

The harness question

TamaBench compares more than one model against another. Its central comparison is:

snippet.txttext
1Raw model
2 vs
3Raw model + Wake Scheduler
4 vs
5Raw model + Harness V1

Harness V1 follows a DECIDE → CALCULATE → SCHEDULE loop. The model wakes when a care decision is needed, while routine economy actions can be handled deterministically. The intended test is whether better orchestration can reduce API calls, tokens, and compute while preserving or improving survival.

What it measures

The repository defines metrics for:

  • survival across the full episode;
  • average health and happiness;
  • economic efficiency;
  • first-pass and recovered schema compliance;
  • planning, resource, truncation, and retry failures;
  • latency, API calls per day, and reasoning or JSON tokens.

The runtime also records SQLite results, JSONL events, reasoning traces, and replay files. That makes the benchmark useful for investigating why an agent failed, not only whether it survived.

Why this belongs in the Lab

TamaBench is a good example of an evaluation that starts from a workflow rather than a model score. The controlled sandbox gives a small local model a concrete job, fixed rules, seeded events, and consequences that accumulate over time.

It still does not prove that an agent is safe for email, home automation, or production infrastructure. Those environments need their own tools, permissions, policies, and tests. TamaBench isolates reusable skills underneath them: observation, planning, structured tool use, recovery, and long-horizon control.

Run one episode

From the repository root, install the package, start a local model through Ollama, then run:

snippet.shbash
1python -m tamabench.cli run --agent harness_v1 --model <your-model> --episodes 1

The repository also includes a rule-based baseline that does not need a model. Keeping that baseline in the comparison makes it easier to separate model behavior from environment and harness behavior.

Current boundaries

TamaBench is an early research preview. Its README marks current result rows as TBD, warns that version 0.1.0 results are not cross-version comparable, and lists a multi-agent runner and result dashboard as future work.

This note credits Pichetpong Muangsiri, keeps the original repository as the source of truth, and does not turn the benchmark into a winner list.

Related Experiments

LAB-102
2026Ongoing

EV Terminal — A Local AI Agent on Android

A small Android agent that loads Qwen3.5-0.8B only when a task needs model intelligence, routes deterministic work through explicit tools, and releases model resources when the task ends. It runs without an Ollama server or an always-on cloud backend.

Hypothesis: A small on-device model can still be useful when the harness owns routing, tool execution, and task lifecycle instead of asking the model to do every operation itself.
Category: AgentsCredit: Cheva1234
LAB-101
2026In Review

Local LLM Inference Under Limited VRAM — MoE vs Dense vs RAM Offloading

Exploratory study of Mixture-of-Experts, dense models, and RAM offloading on an NVIDIA RTX 3060 12 GB + 16 GB DDR4. Tests whether sparse MoE can use system RAM as a capacity tier: Gemma 4 26B-A4B stays interactive (12–19 tok/s at 16K), while the dense Mistral Small 3.1 24B collapses to 3.35 tok/s and Qwen-AgentWorld 35B-A3B reaches double digits only with high latency and memory pressure.

Hypothesis: A sparse MoE with low active parameters can use system RAM as a model-capacity tier more effectively than a dense architecture under GPU/RAM hybrid inference, so total parameter count alone does not predict throughput.
Category: Models