llm4s

LLM4S is now onboarded and tracked on Linux Foundation LFX Insights, providing an independent, data-driven view of project health, maintainer activity, development, contributors, and security practices. LFX Insights tracking does not mean that LLM4S is hosted by or part of the Linux Foundation.

This visibility helps contributors, adopters, and organizations evaluate the project's activity and sustainability, strengthening transparency, trust, and readiness for broader community and enterprise adoption.

View LLM4S on LFX Insights →

LLM4S appears in the LLM API Gateways & Local Inference collection alongside widely adopted projects such as Ollama, vLLM, LiteLLM, and Vercel AI SDK. For developers exploring production-minded LLM infrastructure—especially on the JVM and Scala—this makes LLM4S easier to discover, compare, and explore. Collection inclusion provides category context; it does not imply ranking or endorsement.

LLM4S provides a simple, robust, and scalable framework for building LLM applications in Scala. While most LLM work is done in Python, we believe that Scala offers a fundamentally better foundation for building reliable, maintainable AI-powered applications.

LLM4S is under active pre-1.0 development. The latest published release is v0.5.1; v0.5.0 was the first with the split module artifacts. Both target Scala 3.7.1 and JDK 21. Its APIs are usable today but are still being stabilized ahead of the 1.0 compatibility commitment.

The framework already provides multi-provider clients, agents and tool calling, RAG and vector stores, memory, guardrails, tracing and metrics, reliability wrappers, workspace isolation, MCP support, and image and speech APIs.

Since 0.5.0, llm4s ships as separate modules. RAG, knowledge graph, memory, MCP, shared media types, image, and speech have been carved out of llm4s-core into focused modules with smaller dependency footprints, and providers register through an SPI. Provider clients have moved into modules of their own - llm4s-ollama, llm4s-gemini, llm4s-anthropic, llm4s-openai, llm4s-openai-compatible (DeepSeek, Z.ai, OpenRouter, Mistral, Cohere and any OpenAI-compatible endpoint) and llm4s-voyage - and llm4s-core holds none. Langfuse tracing, the trace collector and store, and CostTracker are in llm4s-observability, and Prometheus metrics in llm4s-observability-prometheus, leaving llm4s-core with only the tracing and metrics contracts, console and no-op tracing, and no observability dependency. The agent runtime is in llm4s-agent and the built-in tools in llm4s-agent-tools, so llm4s-core is now a ~19k-line spine, and its API has been cleaned up ahead of the compatibility baseline, which is set at a pre-1.0 release once the designs are final (#1281). Upgrading from 0.4.x? Start with Upgrading from 0.4.1 to 0.5.0. See the 1.0 scope and migration guide for module maturity and upgrade details.

The path to 1.0 is focused on stable API boundaries, provider capability parity and contract tests, Java/Kotlin/Spring/Gradle interoperability, security hardening, deterministic CI, production observability and cost controls, runnable documentation, and maintained reference applications. See the roadmap for the full stabilization plan.

• Type Safety: Catch errors at compile time, not in production.
• Functional Programming: Immutable data and pure functions for predictable, maintainable systems.
• JVM Ecosystem: Access to mature, production-grade libraries and tooling.
• Concurrency: Advanced models for safe, efficient parallelism.
• Performance: JVM speed with functional elegance.
• Ecosystem Interoperability: Seamless integration with enterprise JVM systems and cloud-native tooling.

Choosing between JVM libraries? Comparing LLM4S sets LLM4S beside LangChain4j, Spring AI, Koog and Embabel, with a source and a date for every claim, and Migrating from LangChain4j maps its concepts to LLM4S.

• Multi-Provider Support: Connect to multiple LLM providers, including OpenAI, Anthropic, Azure OpenAI, Google Gemini, DeepSeek, Cohere, Mistral, OpenRouter, Requesty, Z.ai, and Ollama.
• Execution Environments: Run LLM-driven operations in secure, containerized or non-containerized setups.
• Error Handling: Robust mechanisms to catch, log, and recover from failures gracefully.
• MCP Support: Model Context Protocol primitives for richer tool and context integration.
• Agent Framework: Build single or multi-agent workflows with standardized interfaces.
• Multimodal Generation: Support for text, image, voice, and other LLM modalities.
• RAG (Retrieval-Augmented Generation): Built-in tools for search, embedding, retrieval workflows, and RAGAS evaluation with benchmarking harness.
• Observability: Detailed trace logging, monitoring, and analytics for debugging and performance insights.
• Raw Provider Exchange Logging: Persist request/response exchanges, including streaming responses for streaming-capable providers, to inspect raw provider payloads during development and debugging.

        ┌───────────────────────────┐
        │    LLM4S API Layer        │
        └──────────┬────────────────┘
                   │
          Multi-Provider Connector
        (OpenAI | Anthropic | DeepSeek | ...)
                   │
         ┌─────────┴─────────┐
         │ Execution Manager │
         └─────────┬─────────┘
                   │
        ┌──────────┴──────────┐
        │   Agent Framework   │
        └──────────┬──────────┘
                   │
      ┌────────────┴────────────┐
      │  RAG Engine + Tooling   │
      └────────────┬────────────┘
                   │
     ┌─────────────┴─────────────┐
     │   Observability Layer     │
     └───────────────────────────┘

• modules/core: Core LLM4S framework
• modules/workspace: Workspace runner/client/shared
• modules/samples: Usage examples
• docs: Documentation site and references
• hooks: Pre-commit hook installer

To get started with the LLM4S project, check out this teaser talk presented by Kannupriya Kalra at the Bay Area Scala Conference. This recording is essential for understanding where we’re headed:

🎥 Teaser Talk: https://www.youtube.com/watch?v=SXybj2P3_DE&ab_channel=SalarRahmanian

LLM4S was officially introduced at the Bay Area Scala Conference in San Francisco on February 25, 2025.

LLM4S is on Maven Central; the current release is 0.5.1, for Scala 3.7.x (built with 3.7.1) on JDK 21. llm4s-core holds no provider client, so add the module of the provider you call next to it:

// build.sbt
ThisBuild / scalaVersion := "3.7.1"

val llm4sVersion = "0.5.1"

libraryDependencies ++= Seq(
  "org.llm4s" %% "llm4s-core"   % llm4sVersion,
  "org.llm4s" %% "llm4s-openai" % llm4sVersion  // or llm4s-anthropic, llm4s-gemini, llm4s-ollama, ...
)

Providers are named sections in your application.conf (see Setup your LLM Environment). To start from a generated project instead, use the starter kit. The installation guide has Maven, Gradle, the BOM (llm4s-bom) and every optional module; the Scala CLI quick start makes a first call from a single file, and first steps walks through the API. The sections below, from pre-commit hooks to the containerised demo, are for working on LLM4S itself.

To ensure code quality, we use a Git pre-commit hook that automatically checks code formatting and runs tests before allowing commits:

# Install the pre-commit hook
./hooks/install.sh

# The hook will automatically:
# - Check code formatting with scalafmt
# - Compile code
# - Run tests

# To skip the hook temporarily (not recommended):
# git commit --no-verify

• JDK 21+ (see supported JDKs)
• SBT
• Docker

java -version

Set JAVA_HOME and update your PATH.

brew install openjdk@21
echo 'export PATH="/opt/homebrew/opt/openjdk@21/bin:$PATH"' >> ~/.zshrc

sbt compile

# Build and test
sbt buildAll

See: docs/reference/contributing.md#IDE-Setup

You will need an API key for at least one cloud provider, or a local Ollama installation for local models.

llm4s reads providers from named sections under llm4s.providers in application.conf. Each provider module binds its vendor's API-key variable (OPENAI_API_KEY, ANTHROPIC_API_KEY, ...) to a shared key, so with the variable set a section needs only provider and model - a section for a second account sets its own apiKey = ${?OTHER_VAR}. Nothing reads LLM_MODEL:

llm4s {
  providers {
    provider = "openai-main"          # the default: the name of a section below

    openai-main {
      provider = "openai"
      model    = "gpt-4o-mini"
    }
  }
}

The samples in this repository already have an application.conf whose default is a local Ollama section (ollama-local, model llama3:latest, overridable with OLLAMA_MODEL and OLLAMA_BASE_URL). Run ollama pull llama3 once, or set OLLAMA_MODEL to a model you already have (ollama list). To run them against a cloud provider, put a section like the one above in modules/samples/src/main/resources/application.local.conf (ignored by git) and select it:

export OPENAI_API_KEY=<your_openai_api_key>
export LLM4S_PROVIDER=openai-main   # bound by the samples' application.conf

Anthropic, Gemini, Azure, OpenRouter, Z.ai, DeepSeek, Mistral, Cohere, xAI and generic OpenAI-compatible endpoints work the same way with provider = "anthropic", "gemini", "azure", "openrouter", "zai", "deepseek", "mistral", "cohere", "xai" or "openai-compatible", and the vendor's own key variable (ANTHROPIC_API_KEY, GOOGLE_API_KEY/GEMINI_API_KEY, AZURE_OPENAI_API_KEY, ...); each provider module's reference.conf has an example section. See the API keys table, the configuration guide for all of them and running the samples for the samples' own bindings.

To check the whole setup in one run - the JDK, the provider section, its module, its API key (where it was found, never its value) and, with --local, whether Ollama is running and has the model - run the doctor; each step that fails prints the fix:

sbt "configPolicy/runMain org.llm4s.configpolicy.DoctorCli --config modules/samples/src/main/resources/application.conf --local"

No build tool yet? The Scala CLI quick start makes a first call from a single file.

The quickest start is the cookbook: complete, runnable programs that need no API key (a scripted client stands in for the model; add --live for your configured provider), each run in CI. Recipes: classify text into an enum, extract data from an email, summarise a long document, answer questions over a folder of files, an agent that calls two tools, a guardrailed chatbot, stream tokens, fall back between providers, cache repeated calls, evaluate an answer with a judge, keyword search, memory, several agents in one graph.

sbt "samples/runMain org.llm4s.samples.cookbook.StructuredOutputRecipe"

Every other sample:

# Using Scala 3
sbt "samples/runMain org.llm4s.samples.basic.BasicLLMCallingExample"

sbt workspaceRunner/Docker/publishLocal
sbt "workspaceSamples/runMain org.llm4s.samples.workspace.ContainerisedWorkspaceDemo"

LLM4S now targets Scala 3.7.1 only. The build keeps compatibility-oriented aliases for Scala 3 verification:

• src/main/scala - Common code for all versions
• src/main/scala-3 - Scala 3 specific code (add when needed)

We've kept convenient build aliases:

# Compile the repo
sbt compileAll

# Test the repo
sbt testAll

# Clean, compile, and test
sbt buildAll

# Publish current Scala 3 artifacts
sbt publishAll

Our goal is to build a production-grade, type-safe AI application framework for Scala and the JVM, with multi-provider, multimodal, agentic, RAG, observability, and governance capabilities.

For the current roadmap, see the LLM4S Roadmap.

The roadmap covers:

• Current Capability Map: What exists today and what still needs hardening
• Production Pillars: Testing, API stability, provider parity, JVM adoption, security, performance, cost, documentation, and observability
• 2026 Stabilization Phases: The path from broad pre-1.0 functionality to a production-ready v1.0
• Reference Applications: The maintained end-to-end apps needed before v1.0

Tool calling is a critical integration - designed to work seamlessly with multi-provider support and agent frameworks. We use ScalaMeta to auto-generate tool definitions, support dynamic mapping, and run in secure execution environments.

Tools can run:

• In containerized sandboxes for isolation and safety.
• In multi-modal pipelines where LLMs interact with text, images, and voice.
• With observability hooks for trace analysis.

Using ScalaMeta to automatically generate tool definitions from Scala methods:

/** My tool does some funky things with a & b...
 * @param a The first thing
 * @param b The second thing
 */
def myTool(a: Int, b: String): ToolResponse = {
  // Implementation
}

ScalaMeta extracts method parameters, types, and documentation to generate OpenAI-compatible tool definitions.

Mapping LLM tool call requests to actual method invocations through:

• Code generation
• Reflection-based approaches
• ScalaMeta-based parameter mapping

Tools run in a protected Docker container environment to prevent accidental system damage or data leakage.

Tracing isn’t just for debugging - it’s the backbone of understanding model behavior.LLM4S’s observability layer includes:

• Detailed token usage reporting
• Multi-backend trace output (console and none in llm4s-core; Langfuse from llm4s-observability, OpenTelemetry from llm4s-observability-otel)
• Agent state visualization
• Integration with monitoring dashboards

Configure tracing behavior using the TRACING_MODE environment variable. Console output (the default) and no tracing are built into llm4s-core; every other mode comes from a backend module you add as a dependency:

# Send traces to Langfuse - needs "org.llm4s" %% "llm4s-observability"
TRACING_MODE=langfuse
LANGFUSE_PUBLIC_KEY=pk-lf-your-key
LANGFUSE_SECRET_KEY=sk-lf-your-secret

# Print detailed traces to console with colors and token usage
TRACING_MODE=print

# Disable tracing completely
TRACING_MODE=none

import org.llm4s.config.Llm4sConfig
import org.llm4s.trace.{ ConsoleTracing, Tracing }

// Build the tracer llm4s.tracing.mode selects; fall back to the console tracer
val tracer: Tracing = Llm4sConfig
  .tracing()
  .flatMap(Tracing.fromSettings)
  .fold(_ => new ConsoleTracing(), identity)

// Trace events, completions, and token usage
tracer.traceEvent("Starting LLM operation")
tracer.traceCompletion(completion, completion.model) // prefer the model reported by the API
tracer.traceTokenUsage(tokenUsage, completion.model, "chat-completion")
// An agent built withTracing(tracer) ends each run with a TraceEvent.AgentRunEnded

Note: The LLM4S template has moved to its own repository for better maintainability and independent versioning.

The llm4s.g8 starter kit helps you quickly create AI-powered applications using llm4s. It is a starter kit for building AI-powered applications using llm4s with improved SDK usability and developer ergonomics. You can now spin up a fully working scala project with a single sbt command. The starter kit comes pre-configured with best practices, prompt execution examples, CI, formatting hooks, unit testing, documentation, and cross-platform support.

Template Repository: github.com/llm4s/llm4s.g8

Using sbt, do:

sbt new llm4s/llm4s.g8 \
--name=<your.project.name> \
--package=<your.organization> \
--version=<your.project.version> \
--llm4s_version=0.5.1 \
--scala_version=3.7.1 \
--munit_version=1.1.1 \
--directory=<your.project.name> \
--force

to create new project.

Since 0.5.0 llm4s-core ships no provider, so the generated build.sbt needs llm4s-core and at least one provider module at the same version. The template is being moved to 0.5.x (llm4s.g8#6), which adds llm4s-ollama and llm4s-openai itself; a template from before that lists llm4s-core only (and defaults to llm4s 0.4.0 if you leave out --llm4s_version), so add the provider you use, for example llm4s-openai at 0.5.1.

For more information about the template, including compatibility matrix and documentation, visit the template repository. Use the comprehensive documentation to get started with the project using starter kit.

llm4s exposes a single configuration flow with sensible precedence:

• Precedence: -D system properties > application.conf (if your app provides it) > reference.conf defaults.
• Environment variables are read only where a ${?ENV} substitution binds them: in a module's reference.conf (tracing, embeddings, tools, and each provider module's vendor key under llm4s.credentials) or in your own application.conf. No .env reader is required, and nothing reads LLM_MODEL.

Preferred typed entry points (PureConfig-backed via Llm4sConfig):

• Provider / model:
  • Llm4sConfig.defaultProvider(): Result[ProviderConfig] – the typed config of the section llm4s.providers.provider names.
  • Llm4sConfig.provider(name: String): Result[ProviderConfig] – the typed config of the section llm4s.providers.<name>.
  • LLMConnect.getClient(config: ProviderConfig): Result[LLMClient] – builds a client from a typed config (with a given ModelRegistryService from Llm4sConfig.modelRegistryService()).
• Tracing:
  • Llm4sConfig.tracing(): Result[TracingSettings] – returns typed tracing settings.
  • Tracing.fromSettings(settings: TracingSettings): Result[Tracing] – builds the tracer the mode selects; a missing backend is an error.
  • Tracing.create(settings: TracingSettings): Tracing – the same, falling back to NoOpTracing with an error logged.
• Embeddings:
  • Llm4sConfig.embeddings(): Result[(String, EmbeddingProviderConfig)] – returns (provider, config) with validation.
  • EmbeddingClient.from(provider: String, cfg: EmbeddingProviderConfig): Result[EmbeddingClient] – builds an embeddings client from typed config.

Recommended usage patterns:

• Model name for display: Llm4sConfig.defaultProvider().map(_.model) or prefer completion.model from API responses.
• Tracing:
  • Llm4sConfig.tracing().flatMap(Tracing.fromSettings), or .map(Tracing.create) to fall back to no tracing.
• Workspace (samples): WorkspaceConfigSupport.load() to get workspaceDir, imageName, hostPort.
• Embeddings sample (samples): EmbeddingUiSettings.loadFromEnv, EmbeddingTargets.loadFromEnv, EmbeddingQuery.loadFromEnv (sample helpers backed by Llm4sConfig).

Use these loaders to convert flat keys and HOCON paths into typed, validated settings used by the code:

• LLM provider and model selection

  • Keys: llm4s.providers.provider (the default section's name) and llm4s.providers.<name>.{provider, model, apiKey, baseUrl, ...}. No environment variable is bound: bind your own with ${?VAR} in application.conf
  • Type: ProviderConfig (with provider-specific subtypes)
  • Loader: Llm4sConfig.defaultProvider() or Llm4sConfig.provider("name") + LLMConnect.getClient(...)

• Tracing configuration

  • Keys: llm4s.tracing.mode | TRACING_MODE (llm4s-core); llm4s.tracing.langfuse.* | LANGFUSE_URL, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY, LANGFUSE_ENV, LANGFUSE_RELEASE, LANGFUSE_VERSION (bound by llm4s-observability); llm4s.tracing.opentelemetry.* | OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT (bound by llm4s-observability-otel)
  • Type: TracingSettings (the mode, plus the selected mode's block as extras); LangfuseConfig via LangfuseConfigLoader.default()
  • Loader: Llm4sConfig.tracing() → then Tracing.fromSettings or Tracing.create

• Workspace settings (samples)

  • Keys: llm4s.workspace.dir | WORKSPACE_DIR, llm4s.workspace.image | WORKSPACE_IMAGE, llm4s.workspace.port | WORKSPACE_PORT
  • Type: WorkspaceSettings
  • Loader: WorkspaceConfigSupport.load()

• Embeddings sample settings (samples only; bound under llm4s.samples.embeddings in the samples' application.conf)

  • Input paths: EMBEDDING_INPUT_PATHS or EMBEDDING_INPUT_PATH → EmbeddingSampleConfig.inputs() → EmbeddingTargets.fromInputs(...)
  • Query: EMBEDDING_QUERY → EmbeddingSampleConfig.inputs() (or EmbeddingQuery.loadFromEnv()) → EmbeddingQuery
  • Chunking: CHUNK_SIZE, CHUNK_OVERLAP, CHUNKING_ENABLED → EmbeddingSampleConfig.chunking()
  • UI knobs: MAX_ROWS_PER_FILE, TOP_DIMS_PER_ROW, GLOBAL_TOPK, SHOW_GLOBAL_TOP, COLOR, TABLE_WIDTH → EmbeddingSampleConfig.ui() → EmbeddingUiSettings
  • Non-text stubs: ENABLE_EXPERIMENTAL_STUBS, LLM4S_EMBEDDINGS_LOCAL_{IMAGE,AUDIO,VIDEO}_MODEL → EmbeddingSampleConfig.experimentalStubs(), .localModels()

• Embeddings: provider configuration

  • Key: EMBEDDING_MODEL / llm4s.embeddings.model as provider/model (or legacy EMBEDDING_PROVIDER / llm4s.embeddings.provider)
  • Supported providers: openai (llm4s-openai), voyage (llm4s-voyage), ollama (llm4s-ollama); each from its module once published
  • Type: (String, EmbeddingProviderConfig)
  • Loader: Llm4sConfig.embeddings()
  • Provider-specific keys:
    • OpenAI: OPENAI_EMBEDDING_BASE_URL, OPENAI_EMBEDDING_MODEL, and OPENAI_API_KEY - the same key OpenAI chat sections use
    • Voyage: VOYAGE_EMBEDDING_BASE_URL, VOYAGE_EMBEDDING_MODEL, VOYAGE_API_KEY
    • Ollama (local): OLLAMA_EMBEDDING_BASE_URL (default: http://localhost:11434), OLLAMA_EMBEDDING_MODEL

• Provider API keys and endpoints

  • Keys: apiKey and baseUrl inside each llm4s.providers.<name> section, plus the provider's own keys - organization (OpenAI, Requesty, OpenRouter), endpoint and apiVersion (Azure), project and location (Vertex AI). A section without apiKey uses its vendor's shared llm4s.credentials.<provider>.apiKey, which the provider module binds to OPENAI_API_KEY, ANTHROPIC_API_KEY and so on; a section's own apiKey wins
  • Type: concrete ProviderConfig (e.g., OpenAIConfig, AnthropicConfig, AzureConfig, OllamaConfig, GeminiConfig, DeepSeekConfig, CohereConfig)
  • Loader: Llm4sConfig.defaultProvider() or Llm4sConfig.provider("name")

Tracing

• Configure mode via llm4s.tracing.mode (default: console). Supported: console and noop (built into llm4s-core), langfuse (with llm4s-observability), opentelemetry (with llm4s-observability-otel), and any mode a TracingBackend on the classpath registers.
• Override with env: TRACING_MODE=langfuse (or system property -Dllm4s.tracing.mode=langfuse).
• Build tracers:
  • Checked: Llm4sConfig.tracing().flatMap(Tracing.fromSettings) → Result[Tracing]
  • Falling back to no tracing: Llm4sConfig.tracing().map(Tracing.create)
  • Low-level: LangfuseConfigLoader.default().map(LangfuseTracing.from) (llm4s-observability)

Example (no application.conf required):

sbt -Dllm4s.providers.provider=openai-main -Dllm4s.providers.openai-main.provider=openai -Dllm4s.providers.openai-main.model=gpt-4o -Dllm4s.providers.openai-main.apiKey=sk-... "samples/runMain org.llm4s.samples.basic.BasicLLMCallingExample"

Or with an openai-main section (provider = "openai" and a model) in modules/samples/src/main/resources/application.local.conf and the samples' LLM4S_PROVIDER binding:

export LLM4S_PROVIDER=openai-main
export OPENAI_API_KEY=sk-...
sbt "samples/runMain org.llm4s.samples.basic.BasicLLMCallingExample"

LLM4S uses GitHub Actions for continuous integration to ensure code quality and compatibility across supported platforms.

Our unified CI workflow runs on every push and pull request to main/master branches:

• Quick Checks: formatting, scalafix, compilation and the build's policy checks, in one sbt server. It runs alongside the test jobs rather than before them, and gates the merge through All Tests Pass
• Code Coverage: per-module coverage floors, enforced in four parallel legs (Code Coverage (<leg>))
• Cross-Platform Testing: Tests run on Ubuntu and Windows with Scala 3.7.1
• Template Validation: Verifies the g8 template works correctly
• Caching: Optimized caching strategy with Coursier for faster builds

Automated AI-powered code review for pull requests:

• Automatic Reviews: Trusted PRs get automatic Claude reviews
• Security: External PRs require manual trigger by maintainers
• Manual Trigger: Maintainers can request reviews with @claude comment

Automated release process triggered by version tags (format: v0.3.2):

• Tag Format: Must use v prefix (e.g., v0.3.2, not 0.3.2)
• Pre-release Checks: Runs full CI suite before publishing
• GPG Signing: Artifacts are signed for security
• Maven Central: Publishes to Sonatype/Maven Central

See RELEASE.md for detailed release instructions.

You can run the same checks locally before pushing:

# Check formatting
sbt scalafmtCheckAll

# Compile
sbt compile

# Run all tests
sbt test

# Full build (compile + test)
sbt buildAll

Stay hands-on with LLM4S! Join us for interactive mob programming sessions, live debugging, and open-source collaboration. These events are great for developers, contributors, and anyone curious about Scala + GenAI.

🗓️ Weekly live coding and collaboration during LLM4S Dev Hour, join us every Sunday at 09:00 London time on Discord!

When is Dev Hour in your time zone? LLM4S is a global community: the maintainers and contributors are spread across the world, and everyone joins from where they are. Dev Hour is every Sunday at 09:00 London time:

"Summer" is while the UK is on British Summer Time (late March to late October). The time follows London's clocks, so it can move by an hour elsewhere when clocks change; see the full schedule and the Luma calendar for details.

See the talks being given by maintainers and open source developers globally and witness the engagement by developers around the world.

Stay updated with talks, workshops, and presentations about LLM4S happening globally. These sessions dive into the architecture, features, and future plans of the project.

The Events page on llm4s.org shows what's coming up next, including the next Dev Hour.

Snapshots from LLM4S talks held around the world 🌍.

📝 Want to invite us for a talk or workshop? Reach out via our respective emails or connect on Discord: https://discord.gg/4uvTPn6qww

• Build AI-powered applications in a statically typed, functional language designed for large systems.
• Help shape the Scala ecosystem’s future in the AI/LLM space.
• Learn modern LLM techniques like zero-shot prompting, tool calling, and agentic workflows.
• Collaborate with experienced Scala engineers and open-source contributors.
• Gain real-world experience working with Dockerized environments and multi-LLM providers.
• Contribute to a project that offers you the opportunity to become a mentor or contributor funded by Google through its Google Summer of Code (GSoC) program.
• Join a global developer community focused on type-safe, maintainable AI systems.

Interested in contributing? Start here:

LLM4S GitHub Issues: https://lnkd.in/eXrhwgWY

Security: to report a vulnerability, follow SECURITY.md; please do not use a public issue.

Want to be part of developing this and interact with other developers? Join our Discord community!

Please review our Code of Conduct to understand our community guidelines and expectations.

Help and adopters: see SUPPORT.md for where to ask what, and add your organisation to ADOPTERS.md if you use LLM4S.

LLM4S Discord: https://lnkd.in/eb4ZFdtG

LLM4S was selected for GSoC 2025 under the Scala Center Organisation.

LLM4S participated in Google Summer of Code (GSoC) 2025 under the Scala Center organisation. To learn about the 2025 projects and contributors, check out the details here:

👉 Scala Center GSoC Ideas: https://lnkd.in/enXAepQ3

To know everything about GSoC and how it works, check out this talk:

🎥 GSoC Process Explained: https://lnkd.in/e_dM57bZ

To learn about the experience of GSoC contributors of LLM4S, check out their blogs in the section below.

📚 Explore Past GSoC Projects with Scala Center: https://www.gsocorganizations.dev/organization/scala-center/ This page includes detailed information on all GSoC projects with Scala Center from past years - including project descriptions, code repositories, contributor blogs, and mentor details.

Hello GSoCers and future GSoC aspirants! Here are some essential onboarding links to help you collaborate and stay organized within the LLM4S community.

• 🔗 LLM4S GSoC GitHub Team:You have been invited to join the LLM4S GitHub team for GSoC participants. Accepting this invite will grant you access to internal resources and coordination tools.👉 https://github.com/orgs/llm4s/teams/gsoc/members
• 📌 Private GSoC Project Tracking Board: Once you're part of the team, you will have access to our private GSoC tracking board. This board helps you track tasks, timelines, and project deliverables throughout the GSoC period. 👉 https://github.com/orgs/llm4s/projects/3

• Contributor: Elvan Konukseven | GSoC Final Report URL
• LinkedIn: https://www.linkedin.com/in/elvan-konukseven/ | Email: [email protected] | Discord: elvan_31441
• Mentors: Kannupriya Kalra (Email: [email protected]), Rory Graves (Email: [email protected])
• Announcement: Official Acceptance Post | Volunteering at Scala Center 1, 2, 3 | Python Vs Scala
• Contributor Blogs: 📌 elvankonukseven.com/blog
• Work log: 📌 GitHub Project Board

• Contributor: Gopi Trinadh Maddikunta | GSoC Final Report URL
• LinkedIn: https://www.linkedin.com/in/gopitrinadhmaddikunta/ | Email: [email protected] | Discord: g3nadh_58439
• Mentors: Kannupriya Kalra (Email: [email protected]), Rory Graves (Email: [email protected]), Dmitry Mamonov (Email: [email protected])
• Announcement: Official Acceptance Post | Midterm evaluation post | Lightning talk post| GSoC Final Report post
• Contributor Blogs: 📌 Main Blog | 📌 Scala at Light Speed – Part 1 | 📌 Scala at Light Speed – Part 2
• Work log: 📌 Work Log → GitHub Project

• Contributor: Anshuman Awasthi | GSoC Final Report URL
• LinkedIn: https://www.linkedin.com/in/let-me-try-to-fork-your-responsibilities/ | Email: [email protected] | Discord: anshuman23026
• Mentors: Kannupriya Kalra (Email: [email protected]), Rory Graves (Email: [email protected])
• Announcement: Official Acceptance Post | Midterm evaluation post | Rock the JVM post | Lightning talk post | GSoC Final Report post
• Contributor Blogs: 📌 Anshuman's GSoC Journey
• Work Log: 📌 GitHub Project Board

• Contributor: Shubham Vishwakarma | GSoC Final Report URL
• LinkedIn: https://www.linkedin.com/in/shubham-vish/ | Email: [email protected] | Discord: oxygen4076
• Mentors: Kannupriya Kalra (Email: [email protected]), Rory Graves (Email: [email protected]), Dmitry Mamonov (Email: [email protected])
• Announcement: Official Acceptance Post | Midterm evaluation post | Midway journey post | Lightning talk post | Rock the JVM post
• Contributor Blogs: 📌 Cracking the Code: My GSoC 2025 Story
• Work log: 📌 GitHub Project Board

Feel free to reach out to the contributors or mentors listed for any guidance or questions related to GSoC 2026.

Contributors selected across the globe for GSoC 2025 program.

We’ve got exciting news to share - Scalac, one of the leading Scala development companies, has officially partnered with LLM4S for a dedicated AI-focused blog series!

This collaboration was initiated after our talk at Functional World 2025, and it’s now evolving into a full-fledged multi-part series and an upcoming eBook hosted on Scalac’s platform. The series will combine practical Scala code, GenAI architecture, and reflections from the LLM4S team - making it accessible for Scala developers everywhere who want to build with LLMs.

📝 The first post is already drafted and under review by the Scalac editorial team. We’re working together to ensure this content is both technically insightful and visually engaging.

🎉 Thanks to Matylda Kamińska, Rafał Kruczek, and the Scalac marketing team for this opportunity and collaboration!

Stay tuned - the series will be published soon on scalac.io/blog, and we’ll link it here as it goes live.

LLM4S blogs powered by Scalac.

Technical deep-dives, production stories, and insights from LLM4S contributors. These articles chronicle real-world implementations, architectural decisions, and lessons learned from building type-safe LLM infrastructure in Scala.

💡 You can contribute writing blogs Share your LLM4S experience, architectural insights, or production lessons. Reach out to maintainers on Discord or create a PR updating this table.

Our Google Summer of Code (GSoC) 2025 contributors have actively documented their journeys, sharing insights and implementation deep-dives from their projects. These blog posts offer valuable perspectives on how LLM4S is evolving from a contributor-first lens.

💡 These blogs reflect first-hand experience in building real-world AI tools using Scala, and are great resources for future contributors and researchers alike.

• 🌐 Main Blog
• 📝 Articles:
  • The Application
  • First Task
  • Final GSoC Report URL

• 🌐 Main Blog
• 📝 Articles:
  • Spark of Curiosity
  • The Hunt Begins
  • Enter Scala Center
  • Understanding the Mission
  • Locking the Vision
  • The Proposal Sprint)
  • The Acceptance Moment
  • Stepping In
  • Fiel for the Mission
  • Scala at Light Speed – Part 1
  • Scala at Light Speed – Part 2
  • From Documents to Embeddings
  • Universal Extraction + Embedding Client = One step closer to RAG
  • Midterm Milestone- Modular RAG in Motion
  • GSoC Final Report URL

• 🌐 Main Blog : Anshuman's GSoC Journey
• 📝 Articles:
  • My Journey to Google Summer of Code 2025
  • Community Bonding Experience at GSoC 2025
  • Milestone 1 : Successfully Added Image Generation Capabilities into the LLM4S Library
  • GSoC Final Report URL

• 🌐 Main Blog : Shubham's GSoC Journey
• 📝 Articles:
  • Cracking the Code: My GSoC 2025 Story
  • My Scala Sprint: JVM to Poland Insights
  • GSoC Final Report URL

Want to connect with maintainers? The LLM4S project is maintained by:

• Rory Graves - https://www.linkedin.com/in/roryjgraves/ | Email: [email protected], [email protected] | Discord: rorybot1
• Kannupriya Kalra - https://www.linkedin.com/in/kannupriyakalra/ | Email: [email protected], [email protected] | Discord: kannupriyakalra_46520

• CHANGELOG.md — full release history from v0.1.0 to present, following Keep a Changelog format
• Migration guides — step-by-step upgrade instructions between versions
  • 0.x → 1.0 consolidated guide — all breaking changes across the 0.x series
  • v0.2.9 → v0.3.0 — migrate throwing APIs to type-safe Result[T]

This project is licensed under the MIT License - see the LICENSE file for details.