{"slug": "github-s-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or", "title": "GitHub's Copilot SDK for Java: Run AI Agents in Spring Boot Without Spring AI or LangChain4j", "summary": "GitHub has released the Copilot SDK for Java, embedding the agent runtime behind Copilot CLI as a Maven dependency for any server-side Java application. Principal engineer Edward Burns detailed the SDK in a GitHub engineering post, highlighting its framework-agnostic design, Java-native API, and BYOK mode supporting OpenAI, Anthropic, Azure, or any OpenAI-compatible endpoint without a Copilot subscription. The SDK requires Java 17 minimum and Copilot CLI 1.0.55-5 or later.", "body_md": "Every Java team adding AI to a backend right now faces the same fork in the road. If you are on Spring Boot, you reach for Spring AI. If you are not, you reach for LangChain4j. Both are good libraries. But both also come with a commitment: you adopt their abstractions, their release cadence, and their opinion of what an agent loop looks like. And if you are on Jakarta EE, Micronaut, or Quarkus, the Spring path is simply closed to you.\n\nOn August 10, 2026, GitHub quietly published a third option. [Edward Burns, the principal engineer who led the Java binding and was the release coordinator for Jakarta EE 11](https://github.blog/engineering/using-the-github-copilot-sdk-for-java/), walked through the Copilot SDK for Java in an engineering post on the GitHub blog. The short version: the same agent runtime that powers Copilot CLI is now a Maven dependency you can embed in any server-side Java application, Spring or not, IDE or not. And with its BYOK mode, it runs against OpenAI, Anthropic, Azure, or any OpenAI-compatible endpoint with your own API key, no Copilot subscription required.\n\nThat last sentence is the part that matters for architecture decisions. Let me explain what the SDK actually is, what the code looks like, and where it fits next to Spring AI and LangChain4j if you run Spring Boot services in production.\n\nFull disclosure: I have not shipped the Copilot SDK in production yet. I run my own small AI agent infrastructure on Spring Boot, and everything below comes from GitHub's official documentation, the SDK README, and Burns's engineering post. Treat this as a grounded evaluation with real code, not a war story.\n\n**It is not a model API client.** Most Java AI libraries give you a thin wrapper over a provider's HTTP endpoint: send messages, get a completion. The Copilot SDK exposes something bigger. Per the [repository README](https://github.com/github/copilot-sdk), it embeds \"the same engine behind Copilot CLI: a production-tested agent runtime you can invoke programmatically.\" Your code defines agent behavior and tools; the runtime handles planning, tool invocation, the model loop, and even file edits.\n\n**It speaks idiomatic Java, not a ported DSL.** The API surface is `CompletableFuture`\n\n, annotations, lambdas, and virtual threads. Burns's summary highlights five capabilities: a Java-native API, three tool-definition styles (annotations, lambdas, JSON Schema), section-level system message customization, a one-line agentic loop via `sendAndWait(...)`\n\n, and real-time event streaming via `session.on(...)`\n\n.\n\n**It is genuinely framework-agnostic.** The sample application in Burns's post runs on Jakarta EE 11 with Open Liberty 26, using CDI, JPA, and WebSocket. The Spring integration point is deliberately low-level: you hand the SDK an `Executor`\n\n, and it runs its agent work on your threads. There is no Spring Boot starter to install and no framework plugin. The same library works on Jakarta EE, Spring, Quarkus, or a plain `main`\n\nmethod.\n\n**It is a real, versioned product.** The SDK family (Python, TypeScript, Go, .NET, Java, Rust) is generally available and follows semantic versioning. The Java artifact is `com.github:copilot-sdk-java`\n\n, at version 1.0.12-preview.0 at the time of writing, and the repo sits at over 10,000 stars.\n\nBefore you get excited, know what the SDK assumes.\n\n**Java 17 minimum, JDK 25 recommended.** The jar is a multi-release JAR compiled on JDK 25 with `maven.compiler.release`\n\nset to 17. Run it on JDK 25 or later and the SDK automatically uses virtual threads for its default internal executor. On Java 17 it still works, you just do not get the virtual thread default.\n\n**The Copilot CLI must be installed.** The Java SDK (like the Go and Rust bindings) does not bundle the runtime as a dependency. You need [Copilot CLI](https://docs.github.com/en/copilot/how-tos/use-copilot-cli) version 1.0.55-5 or later on your `PATH`\n\n, or you configure a custom `cliPath`\n\n. Every SDK in the family talks to the CLI over JSON-RPC, and the client manages the process lifecycle. This is the deployment detail most likely to bite you in a container image: your Dockerfile needs the CLI present.\n\n**There is an experimental escape hatch.** If shipping a Node-based CLI alongside your JVM feels wrong, an experimental in-process mode runs the Copilot runtime as a native library instead of spawning a CLI process. It is currently limited to linux-x64 and requires an extra `copilot-sdk-java-runtime`\n\ndependency plus JNA. Interesting for lean containers, not something to bet a production service on yet.\n\nHere is the verified Quick Start from the [Java SDK README](https://github.com/github/copilot-sdk/blob/main/java/README.md), lightly trimmed:\n\n``` python\nimport com.github.copilot.CopilotClient;\nimport com.github.copilot.generated.AssistantMessageEvent;\nimport com.github.copilot.generated.SessionUsageInfoEvent;\nimport com.github.copilot.rpc.MessageOptions;\nimport com.github.copilot.rpc.PermissionHandler;\nimport com.github.copilot.rpc.SessionConfig;\n\npublic class CopilotSDK {\n    public static void main(String[] args) throws Exception {\n        var lastMessage = new String[]{null};\n\n        try (var client = new CopilotClient()) {\n            client.start().get();\n\n            var session = client.createSession(\n                new SessionConfig()\n                    .setOnPermissionRequest(PermissionHandler.APPROVE_ALL)\n                    .setModel(\"claude-sonnet-4.5\")).get();\n\n            session.on(AssistantMessageEvent.class, msg -> {\n                lastMessage[0] = msg.getData().content();\n                System.out.println(lastMessage[0]);\n            });\n\n            session.on(SessionUsageInfoEvent.class, usage -> {\n                var data = usage.getData();\n                System.out.println(\"Current tokens: \" + data.currentTokens().intValue());\n                System.out.println(\"Token limit: \" + data.tokenLimit().intValue());\n            });\n\n            session.sendAndWait(\n                new MessageOptions().setPrompt(\"What is 2+2?\")).get();\n        }\n    }\n}\n```\n\nThree things in this snippet deserve attention, because they differ from what Spring AI and LangChain4j hand you.\n\n** sendAndWait is the whole agentic loop.** One call. The runtime does the model call, decides whether to invoke tools, executes them, and loops until it has a final answer. In Spring AI you assemble this yourself from\n\n`ChatClient`\n\n, tool callbacks, and advisor chains. Here the loop is the runtime's job, which is either a relief or a loss of control depending on your temperament.**Token accounting is a built-in event, not an add-on.** `SessionUsageInfoEvent`\n\nstreams current tokens, the token limit, and message count as the session runs. Anyone who has been surprised by a provider invoice will appreciate that cost observability is a first-class event rather than something you bolt on with an interceptor.\n\n**Permissions are explicit.** `PermissionHandler.APPROVE_ALL`\n\nis the demo setting. The real API lets you write a handler that inspects each permission request and decides programmatically, or routes to a human. For a server-side agent that can touch your filesystem, this is the difference between a demo and something your security team signs off on.\n\nTools are where your domain logic meets the agent, and the SDK offers three styles. The annotation style is the one enterprise Java teams will recognize instantly:\n\n``` python\nimport com.github.copilot.rpc.ToolInvocation;\nimport com.github.copilot.tool.CopilotTool;\nimport com.github.copilot.tool.CopilotToolParam;\n\nclass ProgressTools {\n    @CopilotTool(\"Reports the current phase and session\")\n    public String reportProgress(\n            @CopilotToolParam(\"Current phase\") String phase,\n            ToolInvocation invocation) {\n        return \"phase=\" + phase + \", sessionId=\" + invocation.getSessionId();\n    }\n}\n```\n\nNote the `ToolInvocation`\n\nparameter. It is injected as runtime context and never appears in the tool schema the model sees, so you get session identity and tool call IDs inside your handler for free. It can sit before, between, or after the schema-visible parameters.\n\nFor quick inline tools at session construction, there is a lambda style:\n\n```\nToolDefinition search = ToolDefinition.from(\n    \"search_items\",\n    \"Searches indexed items by keyword\",\n    Param.of(String.class, \"keyword\", \"Search keyword\"),\n    keyword -> \"Searching for: \" + keyword)\n.skipPermission(true)\n.defer(ToolDefer.AUTO);\n```\n\nOptional parameters with defaults, async handlers via `fromAsync`\n\n, and a third JSON Schema style for full control round out the toolkit. The fluent modifiers matter in production: `.skipPermission(true)`\n\non a read-only search tool is reasonable, while leaving permissions on for anything that writes is the sane default.\n\nHere is the claim from Burns's post, quoted directly because the scope matters: \"Even though it's called GitHub Copilot SDK, you can use it with any direct model provider, such as OpenAI, Azure, Anthropic, or OpenAI-compatible endpoints, by passing a `provider`\n\n/`ProviderConfig`\n\nwith your own `baseUrl`\n\n+ `apiKey`\n\n(or bearer token). No Copilot subscription required.\"\n\nRead that again from a procurement perspective. The agent runtime GitHub has hardened over years of Copilot CLI usage, the orchestration, the tool loop, the permission model, becomes a portable harness you can point at whichever provider your company already has a contract with. If your organization standardized on Azure OpenAI, you do not need a Copilot seat per service to use this.\n\nThere are limits, and they are worth knowing before a design review. BYOK in the current SDK is key-based only. There is no support yet for Entra ID, managed identities, or third-party identity providers. Teams whose security posture requires workload identities rather than raw keys will either wait for that support or authenticate through GitHub OAuth instead.\n\nSince my day job is Spring Boot services, this is the angle I care about most, and the pattern is clean. The SDK does not want to own your threading model. You hand it an `Executor`\n\nand it hands back `CompletableFuture`\n\ns.\n\nThe deployment shape that makes sense in a Boot service:\n\n**One client, many sessions.** Instantiate a single `CopilotClient`\n\nas a singleton bean, call `start()`\n\nonce at startup, and create a session per user request or conversation. Sessions are cheap; the client owns the expensive JSON-RPC connection to the runtime.\n\n**Virtual threads for agent work.** On JDK 25, the SDK's internal executor already uses virtual threads by default. In a Boot 4 service you can additionally pass your own executor so agent work stays off the platform threads serving HTTP traffic. Each `sendAndWait`\n\ncall blocks a virtual thread, not a Tomcat worker.\n\n**Memory is per-session and explicit.** The SDK supports persistent agent memory via `MemoryConfiguration`\n\non `SessionConfig`\n\n, so an agent can carry context across turns. It is opt-in per session, including on `resumeSession`\n\n, which means you decide per use case whether the agent remembers anything. For stateless request/response endpoints, leave it off. For a support assistant, turn it on and bound it.\n\n**The container gotcha.** Your image needs the Copilot CLI binary on `PATH`\n\nunless you use the experimental in-process mode. A minimal stage in a multi-stage Docker build that installs the CLI keeps the final image honest. Budget for this in your CI pipeline before you demo.\n\nI keep getting asked some version of \"does this replace Spring AI,\" so here is the honest positioning.\n\n**Spring AI 2.0** remains the right default if you are all-in on Spring Boot. Its annotation-driven tool model, advisor chains, MCP support, and Spring Boot auto-configuration are unmatched for developer velocity inside the Spring ecosystem. You give up nothing except the ability to leave.\n\n**LangChain4j** remains the right default if you are not on Spring and want the broadest provider and vector store coverage, 20-plus models and 20-plus stores, with Quarkus and Micronaut integrations.\n\n**The Copilot SDK for Java** occupies a different slot: it is the option when you want a complete, production-tested agent runtime rather than a framework for assembling your own. You get the loop, the permission model, the memory, the token telemetry, and BYOK provider neutrality, with no framework coupling at all. The trade is that the runtime ships the Copilot CLI process model with it, the version is still in 1.0.x-preview territory, and the ecosystem around it (examples, community answers, battle scars) is young compared to the other two.\n\nA reasonable 2026 architecture: Spring AI for model-facing features inside your Boot services, and the Copilot SDK where you need a full autonomous agent harness that non-Spring teams can also consume. They are not mutually exclusive.\n\nIf you evaluate this SDK this month, here is the checklist I would run, save it for your next design doc:\n\n`APPROVE_ALL`\n\nis for demos. Decide per tool kind what auto-approves and what escalates.`@CopilotExperimental`\n\ncompile errors by default, which is a good sign of API hygiene.`SessionUsageInfoEvent`\n\ninto your metrics pipeline before the first demo, not after the first invoice.The Java AI stack consolidated fast this year: Spring AI 2.0, LangChain4j's BDI agents, Jakarta's own Agentic AI spec in milestone. The Copilot SDK for Java adds a genuinely different option, a vendor-neutral agent runtime with an enterprise Java soul, designed by someone who knows exactly how Jakarta EE shops build software. It is young, the CLI process dependency is real friction, and I would not rip out a working Spring AI integration for it. But for teams that want agent capabilities without framework commitment, or that want one harness across Jakarta EE and Spring, this is the first credible answer. I will be prototyping it against my own agent infra and will report back with real numbers.\n\nI write about Java, Spring Boot, and AI every week. Subscribe, it's free.\n\nHave you tried the Copilot SDK for Java, or are you staying with Spring AI or LangChain4j for now? What broke first in production? I read every comment.", "url": "https://wpnews.pro/news/github-s-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or", "canonical_source": "https://dev.to/jamilxt/githubs-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or-langchain4j-4mij", "published_at": "2026-08-21 20:09:35+00:00", "updated_at": "2026-08-21 20:45:01.599600+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products", "artificial-intelligence"], "entities": ["GitHub", "Copilot SDK", "Edward Burns", "Spring Boot", "Spring AI", "LangChain4j", "Jakarta EE", "OpenAI"], "alternates": {"html": "https://wpnews.pro/news/github-s-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or", "markdown": "https://wpnews.pro/news/github-s-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or.md", "text": "https://wpnews.pro/news/github-s-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or.txt", "jsonld": "https://wpnews.pro/news/github-s-copilot-sdk-for-java-run-ai-agents-in-spring-boot-without-spring-ai-or.jsonld"}}