Nineteen project ideas from the LLM4S Foundation for Google Summer of Code 2027: four for LLM4S itself, a large and a medium idea for each of six projects built on it, and a large idea each for TermFlow, GraphStore and Forge.
This page follows the format of our earlier ideas lists (2025, 2026). Every idea builds on a real codebase, names the gap it closes, and has two or three mentors who created or contribute to that project or belong to the LLM4S core team.
Draft. The mentors listed below have been proposed and must confirm before this page is announced. Dates
follow Google’s official GSoC 2027 timeline.
How to apply
Pick an idea from the table below and read the project’s repository: its README, open issues and roadmap.
Make a first contribution. A merged good first issue in the project you apply for (or in
LLM4S) is the best
evidence that you can work in the codebase.
Write the proposal with a week-by-week plan, the deliverables of each idea below, and how you will test them.
Google’s proposal guide explains what a good
one contains. Read the program rules too.
Our own ideas are welcome: propose them on Discord and find a mentor before you write them up.
What every project shares
LLM4S is heading for 1.0, and the ideas are designed to follow its rules, so the work lasts beyond the summer:
Scala 3 and typed errors: Result[A] (Either[LLMError, A]) rather than exceptions.
Configuration at the edge through Llm4sConfig and named provider sections, never sys.env in library code.
Providers as modules (llm4s-openai, llm4s-anthropic, llm4s-ollama and others), chosen by configuration.
Tests that need no API key: llm4s-testkit’s scripted client or a recorded fixture, with live calls kept to
separate smoke tests.
Observability through the LLM4S tracing contract (Langfuse and OpenTelemetry backends).
AI-assisted development
These projects run in summer 2027, after LLM4S 1.0, and the LLM4S Foundation allows contributors to use AI coding
assistants. The ideas are scoped for that: each asks for more than a 2025 or 2026 idea of the same size would, and
the extra goals at the end of each description are part of the project, not stretch goals.
You own every line. Explain any change you submit, and test it; mentors review design and code as usual.
Say how you use AI. Your proposal describes your workflow and how you check what an assistant produces; a pull
request notes substantial AI help.
Spend the time saved on quality: tests, documentation, benchmarks and the evaluation each idea asks for.
Follow each repository’s own rules for commits and sign-off, and Google’s
program rules.
Large projects are about 350 hours, medium projects about 175 hours.
LLM4S
LLM4S is the AI framework for Scala: a provider-agnostic client, an agent runtime
with tools, guardrails, handoffs and memory, RAG, and tracing, published as modules on a small core.
Calling a model in LLM4S means building a Conversation, options and a parser at every call site. Other JVM frameworks let a developer declare a typed interface and get an implementation backed by an LLM. Issue #1474 asks for the Scala 3 answer, which need not be a JVM proxy: type classes, derives and inline functions are candidates. This project writes the design, compares at least three approaches on classification, extraction and a tool-using task, and builds the recommended one as an experimental module, with streaming, tool calling and structured output, a Java-friendly entry point and the LLM4S samples moved onto it where it makes them simpler.
Expected outcome
A design document in docs/design/ with a maintainer-reviewed recommendation; a prototype of each approach tested against llm4s-testkit; an @Experimental module with the chosen approach covering streaming, tools and structured output, its tests (meeting the repository’s coverage floor), a Java entry point, migrated samples and a user guide.
Skills
Scala 3 metaprogramming (inline, derives, macros), API design, functional programming.
Platform teams building fast-starting services and serverless functions compile to GraalVM native images; nothing in LLM4S supports or tests that today. Issue #1463 lists what a native build must handle: providers and tracing backends found through ServiceLoader, reference.conf resources merged across jars, and vendor SDKs that use reflection. This project builds a minimal LLM4S application as a native image, records what fails, and ships the reachability metadata in each module so users get it for free. It then ships llm4s-doctor as a native binary and measures start-up time and memory against the JVM.
Expected outcome
Reachability metadata under META-INF/native-image for core and the viable provider modules; a sample compiled to a native image in a CI job; llm4s-doctor released as a native binary; start-up and memory benchmarks; docs/guide/graalvm-native-image.md stating what is supported and what is not.
Agents built with different frameworks increasingly call each other over A2A: an agent card says what an agent can do, and tasks run, stream and ask for input over HTTP. LangGraph Platform already serves A2A; LLM4S has none (issue #2450). This project builds an llm4s-a2a module that serves any LLM4S agent over A2A, mapping a task to a run, a context to a thread, input-required to a suspended run and cancel to cancellation, with streamed events. It also builds the client side, so a remote A2A agent is a tool or a handoff target inside an LLM4S agent, and covers authentication, multi-tenancy and tracing across agent boundaries. It ends by proving interoperability against agents built with at least two other frameworks.
Expected outcome
An @Experimentalllm4s-a2a module with server and client, tested against the A2A specification’s examples; agent cards generated from an agent’s tools and skills; streaming, input-required and cancel round trips; authentication and per-tenant isolation; one trace spanning two agents; an interoperability test suite against two other frameworks in CI; a reference service and a user guide.
Scala’s strongest ground is data processing, and data teams run LLMs over millions of rows, where OpenAI’s Batch API, Anthropic’s Message Batches and Gemini Batch Mode cost about half as much as live calls. LLM4S has no batch support (issue #2337), and its Scala 3-only spine cannot run inside the many Spark jobs still on Scala 2.13 (issue #874, deferred to after 1.0). This project closes both gaps: a provider-neutral BatchCompletions facade with OpenAI, Anthropic and Gemini implementations that stream results without loading them whole, then a Scala 2.13 cross-build of the frozen spine (core, agent, observability and the main providers) with per-version source directories and per-version compatibility checks, and finally Spark and fs2 integrations that put the two together.
Expected outcome
Batch vocabulary in core following the growth-safe data-type rules; OpenAI, Anthropic and Gemini batch clients tested against a local stub server (upload, polling, per-item errors, expiry); the frozen spine cross-built for Scala 2.13 with CI on both versions and per-version MiMa baselines; a Spark job on Scala 2.13 and an fs2 pipeline that submit, poll and join results; a cost comparison against live calls; docs/guide/batch-inference.md and a Scala 2.13 guide.
Skills
Scala 3 and Scala 2.13 cross-building, sbt, Spark or fs2, REST APIs, binary compatibility (MiMa).
Szork is a voice-controlled, Zork-style adventure game: an LLM agent acts as the
dungeon master, with speech-to-text, text-to-speech, generated scene images and a Vue web client over WebSockets. It
is LLM4S’s showcase of speech, images, tools and agentic gameplay.
5. Szork: An MCP-powered game master with NPC agents and durable saves
Szork’s dungeon master invents everything itself, so lore drifts and puzzles repeat. Issue #7 asks for MCP servers that showcase LLM4S’s MCP connector. This project builds them in Scala with llm4s-mcp (for example a lore server that keeps the world canon-consistent and a puzzle server), connects the game master to them as an MCP client, adds non-player characters as separate agents reached through LLM4S handoffs, and makes saves durable with an LLM4S checkpointer so a game resumes where it stopped. It then turns Szork into a shared world: several players in one game over WebSockets, and an evaluation suite that replays recorded sessions and scores the game master’s consistency with an LLM judge.
Expected outcome
Two or more MCP servers in Scala with tests; the game master using them through llm4s-mcp; at least two NPC agents with their own prompts and tools; game state saved through SqliteCheckpointer and resumed after a restart; multiplayer sessions sharing one world; a replay-based consistency evaluation; a guardrail for content safety; a one-command Docker deployment; a write-up and demo recording.
Skills
Scala 3, LLM agents and tool calling, MCP, basic web (Vue, WebSockets).
Szork depends on LLM4S core 0.3.2 and calls its speech, image and model features directly. Issue #20 asks for the upgrade to current LLM4S. This project moves Szork onto the LLM4S 1.x modules (llm4s-openai, llm4s-anthropic, llm4s-speech, llm4s-image), loads providers through Llm4sConfig so any configured provider can run the game, covers the game engine with tests that need no API key, and fixes the language-switch bug in issue #4. It adds a local-first mode in which the model, speech and images all run without a cloud key, and plays the game in three languages.
Expected outcome
Szork building on published LLM4S 1.x artifacts; providers chosen by configuration; a documented local-first mode (Ollama plus local speech and images); game-engine tests using llm4s-testkit running in CI; issue #4 fixed with a regression test; the game playable in three languages; an updated README.
Skills
Scala 3, sbt, LLM APIs; speech and image APIs are a plus.
Adk4s is an agent development kit for Scala 3 built on LLM4S and
workflows4s, with Cats Effect and fs2: ReAct agents, DAG workflows,
structured outputs, durable agent memory, interrupt and resume, and an evaluation harness with LLM judges.
7. Adk4s: A DSPy-style program compiler: few-shot bootstrapping and instruction optimisation
Adk4s is porting the ideas of DSPy, where an LLM program is optimised against a metric instead of hand-tuned. Its operative plan has finished phase 0 (the Optimizable predictor surface in adk4s-optimize) and phase 1 (the adk4s-eval harness). This project delivers phase 2, the compiler MVP: signatures as data, rendering demonstrations into prompts, a BootstrapFewShot optimizer and a cache of compiled state; then phase 3’s instruction optimizers, and applies the compiler to tool-using LLM4S agents, not only single predictors.
Expected outcome
Phase 2 specs implemented with the OptimizerLaws checks passing; a compiled program saved and reloaded; at least one phase 3 instruction optimizer; the compiler applied to a tool-using agent; measured score improvements on two public datasets with adk4s-eval; documentation of the optimizer API and a tutorial.
Adk4s builds on LLM4S 0.3.4. Since then LLM4S has split providers into modules, made its data types growth-safe, defined a tracing contract with Langfuse and OpenTelemetry backends and reached 1.0. This project upgrades Adk4s to LLM4S 1.x, loads providers through Llm4sConfig, and bridges Adk4s’s AgentEvent stream to LLM4S tracing, so an Adk4s agent run shows up in Langfuse or an OpenTelemetry collector with its model calls, tool calls and token usage. It also publishes adk4s-eval results as Langfuse scores and datasets, so a team can compare agent versions over time.
Expected outcome
Adk4s compiling and passing its tests on LLM4S 1.x; provider selection by configuration; an AgentEvent-to-tracing bridge with tests; evaluation results published as Langfuse scores; every example traced end to end; a migration note in the Adk4s docs.
Skills
Scala 3, Cats Effect and fs2, sbt; tracing (OpenTelemetry or Langfuse) is a plus.
RAG in a Box is a turnkey RAG deployment powered by LLM4S: a REST API and
admin UI over PostgreSQL and pgvector, hybrid search, incremental ingestion, built-in connectors, analytics and A/B
experiments for RAG configurations.
9. RAG in a Box: On llm4s-rag 1.x: production observability, multi-tenancy and evaluation in CI
RAG in a Box depends on LLM4S core 0.2.9; RAG has since moved into its own llm4s-rag module with vector stores, reranking and evaluation (issue #5). Its roadmap leaves observability and deployment items open (phase 6): distributed tracing, Grafana dashboards, alerting rules and database migrations. This project moves the server onto llm4s-rag 1.x and the provider modules, then delivers those production items with LLM4S’s OpenTelemetry tracing and Prometheus metrics. It goes on to what a company needs before a pilot: multi-tenancy with per-tenant access control enforced at retrieval, a RAG evaluation gate in CI that fails a change which lowers answer quality on a golden set, and a Helm chart.
Expected outcome
The server on LLM4S 1.x with its test suite passing; one trace per query covering retrieval, reranking and generation; Prometheus metrics with a Grafana dashboard and alert rules; schema migrations with Flyway; tenants isolated at retrieval with tests; an evaluation gate in CI; a Helm chart and updated deployment docs.
Skills
Scala 3, http4s, PostgreSQL; RAG concepts; Docker; observability tooling is a plus.
Teams keep their knowledge in wikis and shared drives, not only in files and URLs. The roadmap lists Confluence and Google Drive connectors (3.4) and real-time file watching for the directory ingester (3.1) as open. This project adds them, plus SharePoint and Notion, on top of the existing sync API (upsert, change detection by content hash, prune), so each connector re-indexes only what changed. It extracts a small connector SDK from them so others can add sources, and carries each document’s source permissions into retrieval metadata.
Expected outcome
Confluence, Google Drive, SharePoint and Notion connectors with configuration, incremental sync and deletion detection; a watch option for the directory ingester with debouncing; a documented connector SDK; source permissions carried into retrieval metadata; tests against recorded API responses; a setup guide for each connector.
Skills
Scala 3, REST APIs and OAuth, file-system APIs, testing.
toon4s is the Scala implementation of
Token-Oriented Object Notation (TOON), a compact, JSON-compatible format that
cuts the tokens structured data costs in an LLM prompt. It has a pure functional core, a CLI, JMH benchmarks and a
Spark integration.
11. toon4s: toon4s on Scala.js and Scala Native: a native CLI and a browser playground
toon4s runs on the JVM only. Three open issues ask for more: cross-compiling for Scala.js and Scala Native (#6), a console tool built as a native binary (#7) and a web playground on Scala.js (#8). This project cross-builds the dependency-free core, publishes the new platforms, ships a native CLI, and builds a playground that converts JSON to TOON in the browser and shows the token savings. It then brings TOON to editors: a language server with validation and formatting, packaged as a VS Code extension, and runs the official TOON conformance tests on every platform.
Expected outcome
toon4s-core published for JVM, Scala.js and Scala Native with the shared and official conformance tests passing on each; a native CLI binary built in CI for Linux, macOS and Windows; a static playground deployed with the docs; a TOON language server and VS Code extension; benchmarks comparing the platforms.
Skills
Scala 3, sbt cross-building; Scala.js or Scala Native experience is a plus.
The 2026 ideas list proposed TOON-encoded input and output for LLM4S; it has not been built. This project adds a toon4s-llm4s module to the toon4s repository (as the Spark integration is, so LLM4S core gains no dependency): encoders that render tool results and retrieved RAG context as TOON, a tool that converts JSON to TOON, and a benchmark that measures the saving with LLM4S’s tokenizer and checks that answers stay correct. It also adds a streaming TOON decoder so a model can answer in TOON and LLM4S parses it as it arrives, and runs the accuracy study across at least three providers.
Expected outcome
A published toon4s-llm4s module; round-trip property tests; a streaming decoder for model output; a benchmark report of tokens saved on realistic tool and RAG payloads, with answer quality compared against JSON across three or more providers; an LLM4S agent sample; documentation of when TOON helps and when it does not.
Skills
Scala 3, JSON and serialization, benchmarking (JMH).
llm4s-tripper is a travel-planning agent built with LLM4S and
workflows4s: a pipeline of POI discovery, research, plan generation and accommodation search, using MCP servers for
Google Maps and Brave Search, with a command-line interface.
13. llm4s-tripper: An interactive, resumable trip planner
Tripper is CLI-only and plans a trip in one pass, with no chance for the traveller to steer it. Its wishlist asks for an interactive web UI and HTML/PDF output. This project adds an http4s web interface with live progress over Server-Sent Events, human approval steps in the workflow (the traveller accepts or rejects the discovered places before a plan is generated), persistence so a planning run survives a restart, and export of the final plan. It then makes planning collaborative: several travellers join a trip, vote on places and set a shared budget that the planner optimises against, with calendar export of the itinerary.
Expected outcome
A web UI showing each workflow step live; approval steps as workflows4s signals; runs resumed after a restart; shared trips with voting and a budget the planner respects; HTML, PDF and calendar export; tests for the new workflow states and HTTP routes; a deployed demo and recording.
Skills
Scala 3, Cats Effect, http4s, HTML/CSS; workflow engines are a plus.
Tripper builds against local checkouts of LLM4S and workflows4s and supports OpenAI only. Its wishlist puts Anthropic, Azure OpenAI and OpenRouter support, error recovery and end-to-end tests first. This project moves Tripper onto published LLM4S 1.x artifacts, selects providers through Llm4sConfig (so Anthropic, Azure, OpenRouter and a local Ollama model work by configuration), retries and degrades gracefully with LLM4S’s reliability support, and adds end-to-end tests with scripted models and MCP fixtures. Each run reports its token cost per step, and an LLM-judge evaluation scores plan quality so provider and prompt changes can be compared.
Expected outcome
Tripper building from a fresh clone; at least four providers selectable by configuration; retries and fallbacks with tests; per-step cost reporting; an LLM-judge plan-quality evaluation; end-to-end workflow tests that need no API key; CI running them on every pull request.
Triage4s is a Scala library for evidence-backed AI issue triage, built on
LLM4S, with a read-only dashboard for real GitHub issues. It suggests an issue type and component, requires an exact
source excerpt for each suggestion, and abstains with a reason when it is unsure.
15. Triage4s: Triage where teams work: a GitHub Action, GitLab and Jira sources, a published library
Triage4s today means cloning the repository and running a dashboard by hand. Three open issues describe how teams would adopt it: a GitHub Action that suggests a type and component on new issues, dry-run by default (#100); issue sources beyond GitHub, GitLab and Jira Cloud, behind an issue-source abstraction (#103); and publishing triage4s-core to Maven Central (#96). This project delivers all three, then adds duplicate detection: embeddings of past issues let triage link a new issue to likely duplicates, with the same evidence-or-abstain rule.
Expected outcome
An issue-source abstraction with GitHub, GitLab and Jira implementations, each tested against recorded responses; a GitHub Action with a dry-run default and documented permissions; duplicate detection with evidence; triage4s-core released to Maven Central from a tag; a guide for each.
Teams need to see what triage costs and how good it is before they rely on it. This project traces each classification with LLM4S observability (Langfuse or OpenTelemetry: model, tokens, cost, outcome; #92), verifies and documents local models through llm4s-ollama so triage runs with no API key (#89), and adds a review workflow in the dashboard whose decisions export as evaluation data (#15). Those decisions then drive an accuracy-over-time view and a prompt-regression check in CI.
Expected outcome
One span per classified issue, selected by TRACING_MODE; a documented, tested Ollama setup with the local models that follow the triage schema; reviewer annotations captured separately from model output and exported for the evaluation command; an accuracy-over-time view; a prompt-regression check in CI; tests for each.
Skills
Scala 3, JavaScript for the dashboard, LLM evaluation basics.
TermFlow is a functional terminal UI framework for Scala 3, published as
org.llm4s:termflow. It uses an Elm-style architecture (a pure update, a declarative view, Cmd and Sub) and
ships widgets, a testkit and the LLM4S streaming chat client.
17. TermFlow: Accessible, faster terminal UIs for LLM apps
TermFlow draws a character grid, so a screen reader sees only cells and the renderer repaints more than it needs to when a model streams tokens into a long transcript. Its tracker already names the pieces: a semantic model layer of roles, labels and state (termflow#136), an opt-in linear renderer for screen readers (termflow#137), cell-level damage-region rendering (termflow#128) and configurable frame-rate coalescing (termflow#129). This project builds them and the popup and context-menu primitive (termflow#124), then an agent UI kit on top: widgets for streamed Markdown, tool-call cards, approval dialogs and diffs, proven on the LLM4S chat client and a coding-agent UI.
Expected outcome
Widgets that expose roles and labels; a linear renderer selectable at start-up; damage-region rendering with a benchmark of bytes written and frame time on a streamed transcript before and after; frame-rate settings; popups and context menus; an agent UI kit with a sample coding-agent UI; testkit snapshot tests for each; performance and accessibility guides on the TermFlow docs site.
Skills
Scala 3, functional programming, terminal and ANSI rendering, accessibility, benchmarking.
GraphStore is a temporally-aware knowledge graph for AI agent memory, a Scala
3 take on Graphiti’s ideas on the Typelevel stack: episodic ingestion, bi-temporal edges, contradiction-driven
invalidation, and hybrid BM25 and embedding retrieval over Neo4j. It is wired into Adk4s as durable agent memory.
18. GraphStore: Temporal knowledge-graph memory for LLM4S agents
LLM4S agents remember through llm4s-memory and llm4s-agent-memory, which store facts but not when they were true or what replaced them. GraphStore keeps exactly that, but today only Adk4s agents can use it and its embeddings come from OpenAI alone. This project brings it to LLM4S: an Embedder over any LLM4S embedding provider (Ollama included, for local use), extraction through LLM4S structured completion, and a memory store that LLM4S agents use for recall, including point-in-time questions such as “where did the user work in March?”. It also exposes the graph as an MCP server so any MCP client can use it as memory, and ends with a measured comparison against the existing LLM4S memory stores on a public long-term memory benchmark.
Expected outcome
A GraphStore module that runs on LLM4S providers; an LLM4S memory integration with the same contract tests as the existing stores; an MCP memory server; a sample agent whose answers change correctly as facts are superseded; benchmark results (accuracy and latency) published in the repository; a user guide.
Skills
Scala 3, Typelevel (cats-effect, fs2, http4s), Neo4j and Cypher, embeddings and retrieval, LLM agents.
Forge is a Scala meta-orchestrator above the Claude Code and Codex CLIs. It takes
a feature request through design, piece-by-piece implementation, a pull request and merge, with independent review
and a human in the loop, coordinated by a finite-state machine and Git so one person can supervise many features.
19. Forge: An LLM4S agent connector and reactive PR review
Forge drives its coding and reviewing agents through a Connector trait with two implementations, one per vendor CLI, so every role needs one of those CLIs and its subscription. An LLM4S-backed connector would let any role run on any LLM4S provider, including a local model through Ollama, with token usage and cost from LLM4S, and make true cross-model review a configuration choice. The project then builds the first two capabilities of Forge’s Phase 5 roadmap: reactive PR review, which watches GitHub and GitLab for pull requests Forge did not open and reviews them with that same reviewer role, and workstreams linked to an issue tracker, so a labelled issue becomes a Forge feature run.
Expected outcome
An LLM4S connector passing Forge’s connector test suites, with the streaming, question and resume behaviour the existing connectors have; configuration that assigns a provider and model per role; reactive PR review for GitHub and GitLab with posted review comments and a cost report; issue-tracker workstreams; documentation and an end-to-end demonstration on a real repository.
Skills
Scala 3, cats-effect, LLM agents and tool calling, Git and the GitHub API, state machines.