This page reflects the current pre-1.0 roadmap as of June 2026. It replaces the older 2025 plan, which mixed implemented features with production-readiness goals.
LLM4S has broad, working framework functionality today: provider clients, agents, tool calling, RAG/vector stores, memory, guardrails, tracing, metrics, reliability wrappers, workspace isolation, and multimodal APIs. The remaining v1.0 work is productization: stable contracts, JVM interop, provider capability parity, security hardening, deterministic CI, runnable docs, and polished reference applications.
Quick Status
Latest release tag
v0.3.2
Main branch
Active development after v0.3.2
Stability
Pre-1.0, API stabilizing
Scala support
Scala 3.7.1
Java support
JDK 21 recommended and used in CI
Target
v1.0 production-ready stable modules
Timeline
2026 stabilization phases; v1.0 date intentionally not fixed
Maturity Legend
Status
Meaning
Stable path
Implemented, documented, covered by normal CI, and intended to remain compatible.
Beta
Implemented and usable, but API, provider behavior, or docs still need hardening before v1.0.
Experimental
Useful prototype or advanced feature; expect changes.
Planned
Roadmap item, design, issue, or PR queue item; not a stable user contract.
Publish a generated provider capability matrix and contract tests for chat, streaming, tools, structured output, embeddings, image/audio, timeouts, retries, cost, and raw exchange logging.
Agents
Core agents, tool calling, handoffs, guardrails, memory, streaming events, async tools, reasoning modes, and state serialization are implemented.
Remove, replace, or label ??? placeholders in user-facing docs.
Guides are either runnable or explicitly pseudocode.
Publish stable/beta/experimental/planned status.
Users know which APIs are safe to build on.
Phase 1: Define The Stable Spine
Target: next stabilization window.
Deliverable
Outcome
Name stable module boundaries: core, agents, rag, tools, observability, workspace, and interop.
v1.0 compatibility surface is explicit.
Mark experimental features and modules.
Advanced features can evolve without surprising production users.
Land MiMa or equivalent binary compatibility checks.
Compatibility regressions are caught before release.
Publish compatibility, deprecation, and migration policy.
Users can plan upgrades.
Add package-level Scaladoc for stable modules.
Public API intent is documented.
Phase 2: Provider Capability Matrix And Contract Tests
Target: after stable spine is defined.
Deliverable
Outcome
Capability model for chat, streaming, tools, structured output, reasoning, embeddings, image/audio, timeout/retry, usage/cost, and raw exchange logging.
Provider behavior is comparable and explicit.
Fake-provider contract servers for protocol families.
Behavior is testable without live API calls.
Generated provider capability docs.
Docs stay aligned with code/tests.
Standardized provider options for base URL, headers, proxy, request IDs, user agent, retry-after, and error mapping.
Provider integrations behave consistently.
Phase 3: JVM Interop And Adoption
Target: before v1.0 beta.
Deliverable
Outcome
Java facade with builders, Java collections, and Java-friendly error boundaries.
Java users do not need Scala-specific ergonomics.
Kotlin coroutine wrapper.
Kotlin services can use idiomatic suspend APIs.
Spring Boot starter.
Spring users get auto-configuration, properties binding, health checks, metrics, and test slices.
Maven and Gradle quickstarts.
JVM users can start without sbt.
CI-tested sample projects.
Interop docs remain runnable.
Phase 4: Security And Governance
Target: before v1.0 release candidate.
Deliverable
Outcome
Versioned threat model.
Tool, MCP, RAG, workspace, and provider-log risks are explicit.
Default-deny policies for tools, shell/workspace access, file/network access, MCP servers, and provider exchange logging.
Production users start from safer defaults.
MCP hardening: retain auth and public-bind protection, then add allowlists, capability scoping, audit logs, prompt-injection guidance, and tool poisoning mitigations.
MCP is treated as a production security boundary.
SBOM and dependency/security scanning in CI/release.
Release artifacts have auditable supply-chain metadata.
PII redaction, retention, and multi-tenant logging examples.
Observability guidance is safe for real deployments.
Phase 5: Reliability, Cost, Observability, And Scale