Saplings here means the open-source Python package at shobrook/saplings: a compact framework that explores multiple tool-use trajectories with Monte Carlo tree search (MCTS), A* or greedy best-first search. It is not Meta’s Sapling source-control system, and it is not the maintainer’s older package that was renamed Syntaxis. The current package wraps LiteLLM for model calls and asks an evaluator—an LLM by default—to score candidate branches.
Saplings is best treated as a research-friendly search layer for reversible tools and bounded tasks, not as a production agent platform. It can compare alternative calls and backtrack after later mistakes, but each explored branch may actually execute its tool. That makes calculator, retrieval, code-in-a-sandbox and simulated environment tools reasonable first tests; email, payments, ticket creation or direct database writes require an external dry-run/commit boundary.
Exact identity and maintenance status
| Check | Verified on 2026-08-20 | Interpretation |
|---|---|---|
| Canonical project | GitHub shobrook/saplings; PyPI project saplings | Do not mix with Meta Sapling SCM or Syntaxis |
| Latest package | PyPI 6.2.0, uploaded 2025-06-22 | Installable, but no release for roughly fourteen months |
| Repository | Public, not archived; last push 2025-07-27 | The final commits are README changes; latest visible code fix was 2025-06-22 |
| Distribution | 33 kB source distribution; no wheel listed for 6.2.0 | Build occurs locally during pip install |
| Runtime metadata | Python >=3; dependencies are unpinned litellm and json-repair | The declared Python floor is too broad to prove modern-version compatibility |
| License | LICENSE file is Apache-2.0; setup.py and PyPI metadata say MIT | A real conflict, not a dual-license statement—request maintainer clarification |
The defensible status is available but quiet. The repository is neither archived nor disabled and PyPI still serves 6.2.0, so calling Saplings discontinued would overstate the evidence. Conversely, a working package page does not prove active compatibility work. There are no GitHub Releases, no newer PyPI files after June 2025, and the 6.2.0 source archive contains no bundled tests or benchmark harness. Pin the package and its transitive dependency lock, then run a private compatibility suite before adopting it.
The license mismatch deserves its own gate. Both the repository LICENSE and the LICENSE shipped inside the 6.2.0 source archive contain Apache License 2.0, while setup.py declares MIT and PyPI repeats that metadata. Those signals cannot all be summarized as simply “MIT” or “Apache-2.0.” Teams that redistribute the library should obtain clarification, preserve the shipped notices and let counsel decide the operative terms.
Choosing a Saplings search agent
| Class | Search behavior | Cost and failure boundary |
|---|---|---|
| COTAgent | One ordinary tool-calling trajectory; no search | Useful baseline and cheapest way to validate tools/evaluator |
| GreedyAgent | Generates candidates, executes/evaluates them, then keeps the best next branch | Lowest search overhead in the README’s positioning, but cannot recover from a locally attractive wrong path |
| AStarAgent | Keeps alternative paths and can return to another branch | Middle ground; evaluator quality determines whether the frontier ordering is meaningful |
| MonteCarloAgent | Uses selection, rollout and backpropagation; defaults include branching factor 3, depth 5 and 10 maximum rollouts in 6.2.0 source | Potentially most calls and side effects; current root tool call is generated once before the tree branches |
| Custom evaluator | Subclass the evaluator and return a normalized score/reasoning | Prefer tests, exact answers or environment rewards over an LLM judging its own prose |
A tree is only as useful as its value function. The default evaluator sends the trajectory to the configured model, requests a 0–10 score, then normalizes it to 0–1. That is convenient for a prototype but can reward plausible-looking progress rather than task completion. Coding agents should score compilation and tests; retrieval agents should score source coverage and answer support; environment agents should use state-based rewards. Keep a held-out task set because changing the evaluator prompt can change search behavior as much as changing the search algorithm.
The current MCTS implementation has a specific boundary: it forces one initial tool call and uses that as the root. A comment in the source acknowledges that a wrong root call can compromise the tree. Search expands after that point; it does not evaluate several independent first actions before choosing one. This is precisely why a product page should not promise generic “look-ahead and backtracking” without reading the implementation.
A safe evaluation workflow
- Freeze the artifact. Use an isolated environment, pin
saplings==6.2.0, generate a lockfile and record the sdist hash from PyPI. - Resolve license policy. Record the Apache-2.0 LICENSE versus MIT metadata conflict before distribution or embedding.
- Start with COTAgent. Establish task success, model cost, latency and tool correctness without search.
- Make tools replay-safe. Separate propose/preview from commit; use idempotency keys and sandboxed state for every branch.
- Design an objective evaluator. Prefer unit tests, schema validation, exact constraints, simulator state or source checks; reserve LLM scores for dimensions that truly need judgment.
- Bound the tree. Set branching factor, maximum depth, MCTS rollouts, timeout and provider budget explicitly rather than accepting defaults silently.
- Instrument every call. Log branch ID, parent, tool arguments, tool result, evaluator score, model, tokens, latency, retry and exception without leaking secrets.
- Run a fixed matrix. Compare COT, Greedy, A* and MCTS on the same prompts, seeds where supported, tool mocks and evaluator.
- Test failure cases. Include unavailable APIs, malformed tool output, rate limits, repeated actions, misleading evidence, context truncation and evaluator disagreement.
- Promote through a commit gate. Let search produce a plan or candidate patch; a deterministic validator or human authorizes the one real-world write.
- Vendor-check the model path. Saplings itself is local, but LiteLLM may transmit prompts and raw tool results to the provider you configure; apply that provider’s retention and privacy terms.
- Keep an exit path. Wrap Saplings behind your own agent/search interface so a quiet dependency can be replaced without rewriting tools.
What the compact README does not solve
| Risk | Why it exists in 6.2.0 | Control |
|---|---|---|
| Repeated side effects | BaseAgent expands candidates by executing each candidate tool call before scoring | Use pure/simulated tools; commit once after selection |
| Call explosion | Candidate generation, every branch evaluation and rollouts each invoke a model or tool | Hard budgets, timeouts, cache safe reads and cost-per-solved-task metrics |
| Evaluator bias | Default value function is an LLM judging the trajectory | Objective rewards, multiple evaluators or human audit |
| Root lock-in | MCTS creates one required root call before branching | Generate/validate an explicit plan first or patch the root strategy |
| Dependency drift | litellm and json-repair have no version ranges | Lock transitive versions and test upgrades in CI |
| Privacy/security | Prompts, tool schemas and trajectories reach the chosen model; tools receive trajectory memory | Minimize data, redact secrets, least privilege and provider-specific governance |
| Maintenance/license | Quiet release cadence and conflicting license metadata | Pin/fork, security scan, owner assignment and written license resolution |
The branch side-effect issue is the most important operational insight. In BaseAgent.expand, Saplings generates candidate calls, creates a task for each, awaits their execution and only then evaluates the child nodes. Backtracking does not undo those effects. An MCTS agent that explores three “send_email” candidates can send three emails even if only one branch is returned. A safe architecture searches over descriptions, simulated state or reversible patches and exposes the irreversible action only after search terminates.
Cost claims should be measured, not guessed. The 6.2.0 defaults are visible in source, but the exact number of provider calls depends on early termination, duplicate candidates, depth, rollouts, evaluator samples and tool behavior. Report model and tool cost per accepted task, plus p50/p95 latency and duplicate-side-effect count. The benchmark numbers in the README are attributed to the LATS research paper; they are not a Saplings 6.2.0 reproduction, and the sdist ships no benchmark runner that establishes the same gains.
Saplings alternatives and adjacent frameworks
| Option | Best fit | Trade-off versus Saplings |
|---|---|---|
| Saplings | Small Python experiment adding MCTS/A*/greedy search directly around tool calls | Compact API; quiet maintenance, no durable runtime and branch side effects need user controls |
| Plain ReAct/tool loop | Cheap, sequential tasks with strong tools and easy validation | No search/backtracking, but much easier to reason about cost and external writes |
| LangGraph | Stateful production workflows needing persistence, streaming, human review and durable execution | More orchestration code; search policy must be implemented, but commit gates and state are explicit |
| LLM Reasoners | Research and reproduction across MCTS, Tree-of-Thoughts, world models and many benchmarks | Broader/heavier research stack; clearer fit for algorithm studies than a tiny agent wrapper |
| Custom beam/tree search | Teams with a domain simulator, exact reward and strict side-effect policy | More engineering, but full control over branching, caching, budgets and transactional commit |
Independent judgment: Saplings’ strongest quality is legibility. A developer can inspect the full search loop, Tool abstraction and evaluator without adopting a large platform. That makes it useful for learning and for a bounded proof of concept. Its weakness is the gap between search research and production orchestration: it offers no built-in persistence, approval queue, transactional rollback, durable checkpoints or published security policy.
Adopt it when the environment is cheap to clone and the reward is objective. Avoid placing it directly around irreversible SaaS tools. For a long-lived service, either fork and own the package—with locked dependencies, tests, tracing and clarified license—or implement the search policy inside a maintained workflow runtime. A benchmark win from the cited paper is a hypothesis for your task, not a purchase decision.
Saplings FAQ
What is Saplings?
Saplings is a Python library from shobrook/saplings that wraps tool-calling agents with greedy, A* or Monte Carlo tree search. It uses LiteLLM for model access and an evaluator to score tool-use trajectories.
Is Saplings still maintained?
It is available and not archived, but maintenance is quiet. PyPI 6.2.0 was released on 2025-06-22 and the last repository push was 2025-07-27. Treat compatibility and security maintenance as unproven until a new release or maintainer statement appears.
Is Saplings the same as Meta Sapling?
No. Meta Sapling is a source-control system. This page covers Jonathan Shobrook’s Python tree-search library for AI agents. The README also warns that an older project once using the name Saplings was renamed Syntaxis.
Which license applies?
The repository and 6.2.0 sdist ship an Apache-2.0 LICENSE, but setup.py and PyPI metadata say MIT. That conflict should be clarified with the maintainer; do not silently label the package as one or the other for compliance.
Does tree search always improve an agent?
No. It can help when alternatives can be evaluated reliably, but it multiplies calls and can amplify a weak evaluator. The README benchmark table cites the LATS paper rather than a reproducible Saplings release benchmark.
Can Saplings use local models?
The README says it supports LiteLLM’s provider ecosystem, including local routes. Actual compatibility depends on tool-calling, structured output and token-count support for the selected model/provider; test those paths instead of assuming all listed models work equally.
Why are write tools dangerous?
Saplings executes candidate branch tools before selecting the winner. Search can therefore perform several writes that backtracking cannot reverse. Use previews, sandboxes and a single post-search commit gate.
What should I use instead?
Use a plain tool loop for low-cost sequential work, LangGraph for durable state and human approval, LLM Reasoners for broader search research, or custom search when you have a simulator and exact reward.
Sources reviewed
- shobrook/saplings repository and README
- Saplings 6.2.0 on PyPI
- PyPI project metadata API
- Repository and source-distribution LICENSE
- Saplings setup.py package metadata
- BaseAgent source: branching, execution and evaluation
- MonteCarloAgent source and defaults
- LiteLLM model wrapper source
- Language Agent Tree Search paper (ICML 2024)
- Tree Search for Language Model Agents paper
- LiteLLM provider documentation
- LangGraph official overview
- LLM Reasoners official repository
- Official Saplings README demo image
Independent review dated 2026-08-20. Product identity was checked against GitHub and PyPI. “Available but quiet” is evidence-based, not a declaration of abandonment. License metadata remains contradictory, and paper results were not represented as Saplings-specific benchmarks.
