Overview
The design is practical and tested at scale; main costs come from relying on closed LLMs (GPT‑4) for simulation and evaluation, and cache upkeep is needed to retain benefits.
Citations0
Evidence Strength0.70
Confidence0.80
Risk Signals8
Trust Signals
Findings with numeric evidence: 5/5
Findings with evidence refs: 5/5
Results with explicit delta: 2/5
Reproducibility
Status: Code + data available
Open source: Partial
At A Glance
Cost impact: 50%
Production readiness: 70%
Novelty: 60%
Why It Matters For Business
Benchmarks must be reproducible to compare tool‑enabled models over time; StableToolBench cuts evaluation noise from API outages and weak auto‑judges, enabling fairer model selection and cheaper repeated runs.
Who Should Care
Summary TLDR
StableToolBench replaces fragile live-API evaluation with a virtual API server (cache + LLM-based API simulator) and a GPT-4-based, two-step evaluator that first filters solvable tasks and then reports Solvable Pass/Win Rates (SoPR/SoWR). The benchmark increases reproducibility: large cache (165k entries after filtering), high cache hit rates for prior experiments (~97%), simulator outputs judged realistic by humans (90% adherence to docs), and small performance swings when up to 50% of real APIs are made unavailable. Tradeoffs: uses GPT-4 (cost) and simulator quality depends on the backbone LLM.
Problem Statement
Large-scale tool benchmarks rely on live APIs and weaker auto-evaluators, which change or fail over time. This causes non-reproducible model scores and unstable comparisons across days or months. The paper targets stability in API behavior and automated scoring when evaluating LLMs that call external tools.
Main Contribution
StableToolBench: a virtual API server combining a response cache and LLM-based API simulator to replace unstable real APIs.
A two-step stable evaluation: filter solvable tasks with multiple LLMs, then score answers using GPT-4 with Solvable Pass Rate (SoPR) and Solvable Win Rate (SoWR).
Key Findings
Many original ToolBench APIs were unstable or unavailable.
GPT-3.5 is unreliable as an automatic judge for tool tasks.
Results
| Metric | Value | Baseline | Delta | Split / Dataset | Evidence | Evidence Ref |
|---|---|---|---|---|---|---|
| API availability in original ToolBench | 44.4% success rate | — | — | ToolBench APIs scan | Table 10; Sec.2.3 | Table 10 |
| Cache size after filtering | 164,980 cached call-response entries | — | — | StableToolBench cache | Table 2; Sec.3.1 | Table 2 |
What To Try In 7 Days
Reproduce your tool-usage experiments with a response cache to spot variability sources.
Run a simple LLM-based API simulator for unreachable tools and compare score stability.
Swap weak automatic judges for a stronger evaluator or add human spot checks to reduce noisy metrics.
Agent Features
Memory
Tool Use
Optimization Features
System Optimization
Reproducibility
Data URLs
Risks & Boundaries
Limitations
Relies on GPT‑4 as both evaluator and simulator backbone, which increases cost.
Simulator quality and scores can shift when the backbone LLM upgrades or changes.
When Not To Use
When live, real-time external facts are required (simulators do not return true real-time data).
When closed-source backbone LLMs are unacceptable for policy or cost reasons.
Failure Modes
Backbone LLM drift: upgrades change simulator/evaluator behavior and scores.
Cache staleness: new methods produce calls not covered by cache, reducing hit rates.