---
title: Scope
description: What v1 is, what got cut from the earlier execution-layer plan, and why.
sidebar:
  order: 8
---

Runic wasn't always a cache. Earlier plans (archived under `_deprecated/` in the repo, and in `ALPHA.md`/`ROADMAP.md` for historical context) described an execution runtime: intercepting tool calls, enforcing permissions, sandboxing filesystem/network access, and metering a hard budget. This page explains why that plan was cut, not extended.

## In scope for v1

- Caching a decision's outcome, keyed on an exact-match normalized signature — `{ intent, params }`, never raw task text, never a reasoning trace.
- Logging tokens spent (agent-reported) vs. tokens saved on a cache hit.
- Per-session scope. Cross-session/cross-agent sharing is a later phase, once per-session reuse is proven to matter in practice.

## Explicitly out of scope

- **Execution of any kind.** Runic never calls a capability, deploys anything, or runs code. The old `packages/runtime` is dead.
- **Permissions or sandboxing.** There's nothing to check if nothing executes. The old `packages/permissions` and `packages/sandbox` are dead.
- **Semantic or fuzzy task matching.** This is deliberately narrow — exact match only. It's a design constraint meant to stay a constraint, not a v1 shortcut to be widened later without re-opening the question of whether a cache hit is *actually* the same decision.

## Why this is a pivot, not an addition

Most of the old execution-layer plan — permission enforcement, sandboxing, capability execution — turned out to duplicate what MCP already standardizes for tool calls. Building a parallel permission/execution system on top of that isn't a defensible wedge on its own; it's redundant infrastructure competing with a standard that already exists.

The cache-and-ledger idea survived the cut because it answers a question MCP doesn't: *has this exact decision already been resolved, and what did it cost?* That's a narrower, more honest claim than "Runic manages your agent's execution" — and it's the one this repo actually delivers on, with real benchmark numbers to back it up rather than an architecture diagram.

## If you're looking for the execution-layer plan

It's preserved for history in `ALPHA.md` and `ROADMAP.md` at the repo root, and the code itself is archived under `_deprecated/`. Neither is maintained, and neither reflects what Runic ships today — read [Introduction](/) for that.