Skip to content

v0.7.0

Choose a tag to compare

View all tags
@AlexJoaquimPereira AlexJoaquimPereira released this 09 Oct 09:01
· 224 commits to master since this release
v0.7.0
b73e16a

v0.7.0 — Shared-core / runtime-adapter contract

v0.7.0 makes the boundary between the runtime-independent shared core and the OpenCode V1 adapter explicit and testable. It is a narrowly scoped architecture milestone: no provider behavior changed and no request/telemetry semantics were altered.

Changes

  • Audited boundary: cache-policy-core.mjs, cache-engine-core.mjs, and cache-usage-core.mjs import only Node builtins and sibling shared modules — no OpenCode client, hook, routing, or V2 dependency. Only cache-engine.ts (the V1 adapter) registers hooks and calls the client.
  • Documented contract (implementation plan §2B.8): policy resolution; shared transformations and identity; usage/accounting; the V1 adapter boundary; fail-closed error/unknown handling.

Tests (+4; suite 277 → 281):

  • Shared-core import isolation; adapter hook-registration ownership; full re-export single-definition contract; resolveRuntimePolicy capability-shape contract.
  • No source changes were required — the audit found no boundary violation.

Scope

  • Does not implement a V2 adapter and does not claim dual-runtime support.
  • Session-state lifecycle (v0.7.1) and V2 API verification (v0.7.2+) remain future work.
  • No changes to provider policy, request mutation, cache identity, TTLs, or telemetry schema.

Detailed changelog:

Full Changelog: v0.6.0...v0.7.0

Provider-aware prompt-cache optimization and observability for OpenCode.

opencode-cache-engine is an OpenCode npm plugin with two targets:

  • Server target — the actual cache-engine runtime and provider policies.
  • TUI target — registration with OpenCode's TUI plugin manager.

CacheEngine is an OpenCode plugin designed for long-running agent sessions where prompt-cache efficiency affects both latency and cost. It keeps the harness conservative for providers whose cache behavior is already automatic, while applying provider-specific optimizations where the provider exposes useful cache controls or where prompt structure can be safely improved.

The plugin currently has eleven cache-policy families:

  • DeepSeek — passive cache observability; request structure is preserved.
  • GPT-5.6 and later — documented cache-key/options metadata, with prompt text unchanged. GPT-6 and future 5.6+/6+/7+ versions resolve through the same documented boundary.
  • GLM-5.3 and later — GLM implicit-cache baseline and diagnostics; GLM-5.3 additionally uses a narrow, content-preserving <env> relocation overlay.
  • MiMo V2.6 and later — MiMo implicit-cache baseline and diagnostics; MiMo V2.6 Flash/Pro additionally use a narrow content-preserving <env> relocation overlay.
  • Kimi — passive Moonshot/Kimi implicit-cache observability; the request is left unchanged. The Anthropic-compatible cache_control route is not implemented.
  • Claude (Anthropic) — passive classification and accounting; the request is left unchanged because OpenCode itself applies Anthropic cache_control breakpoints.
  • Google Gemini — passive classification and accounting; Gemini 2.5+ provider-managed implicit caching is left untouched. CacheEngine creates no CachedContent resources and injects no Gemini cache-control field.
  • Alibaba Qwen — passive classification and accounting; Qwen's provider-managed implicit caching is left untouched on every route. CacheEngine places no explicit block-level cache_control marker and adds no affinity, because the V1 hook cannot reach message content blocks and OpenCode already applies breakpoints on the Qwen Messages routes.
  • xAI Grok — passive classification and accounting. Grok caching is automatic on all Grok language models, and direct xAI already receives a stable conversation affinity key from OpenCode itself, so CacheEngine injects no header or key and rewrites nothing.
  • Meta Muse — passive classification and accounting. Muse caching is automatic positional prefix caching; Meta's prompt_cache_key must be an application-stable routing hint (never per-session) and prompt_cache_retention is a request-level policy, so CacheEngine injects neither and rewrites nothing.
  • MiniMax — passive classification and accounting, route-aware. MiniMax caching is automatic; M2.x additionally supports explicit Anthropic cache_control (M3 does not), but OpenCode already owns those breakpoints on the Anthropic-compatible routes, so CacheEngine injects nothing.

Initial models were personally chosen for their performance in max programming task completed per dollar. More models can be added based on newer releases or updates.

Future releases will be based on newer versions of models from the above providers, as well as any model that performs optimally over the Pareto distribution on OpenRouter as well as on personal discretion. Since cache stability policy doesn't change much for the providers, there's no need for a code rebase.

Quick Installation (TUI):

opencode plugin opencode-cache-engine --global

Best complemented with agents for the particular models configured at AlexJoaquimPereira/opencode-agent-config

Assets 3
Loading