For the next couple of months (at least), I will be posting the "Thursdays with Koog" series. This will explore the API for JetBrains' Koog, their API for interacting with LLMs from your Kotlin projects. Part of the value of local models is being able to add them to your favorite apps, to do useful things while not adding to the world's frontier model woes.

(don't worry — I will have posts on other things as well, beyond Koog!)

My framing device for this series is Knosh, my one-shot coding agent. It is written in Kotlin/JVM and uses Koog for the actual LLM integration. Part of the reason I am creating Knosh is to serve as a demonstration of Koog, in something a bit bigger than a "hello, world" sort of sample.

So, let's dive in!

Let's look at a basic Knosh command-line invocation:

knosh prompt --agentId=general "What can you do for me?"

The first argument tells Knosh what specific command to invoke, where prompt is a generic "send a prompt to the LLM, and emit the response" command. We will explore how those commands map to actual prompts sent to LLMs in a few weeks. For now, take it on faith that the trailing text (e.g., "What can you do for me?") will form part of that prompt.

Where Koog starts to show up is in the --agentId=general argument. This tells Knosh specifically what "agent" you want to use, which will go a long way towards driving what we ask Koog to do with the prompt. The value for --agentId (e.g., general) maps to a Markdown file in your agents directory. By default, that will be ~/.config/knosh/agents, so general will map to ~/.config/knosh/agents/general.md.

Those Markdown files follow a "frontmatter, then Markdown" pattern used by a fair number of tools, from coding agents to the Jekyll static site generator. A trivial agent definition might be:

---
model: "ollama/qwen3.6:35b-a3b-coding-nvfp4"
description: a general-purpose agent with full tool access
---
You are a helpful assistant to an experienced software developer.

The model property in the frontmatter indicates the model provider (ollama) and the specific model to use with that provider (qwen3.6:35b-a3b-coding-nvfp4). The model provider names that we can use come from Koog and the subset of those providers that Knosh supports. So, for example, you could have anthropic/claude-sonnet-4-6 or openai/gpt-5.4-nano or mistral/mistral-large-latest as your model, as Koog and Knosh support Ollama, Anthropic, OpenAI, and Mistral and model providers. I will get into more details about models and providers next week.

There can be other Koog-related configuration options in the frontmatter, but model is all you need.

Knosh is a CLI utility, but the CLI application module itself (:knosh-cli) is kept lean. The bulk of the logic resides in library modules, such as :lib:knosh-api and :lib:knosh-agents.

(NOTE: most of the Knosh links in this post point to Knosh 0.2.0, from June 2026)

:knosh-cli focuses on parsing command-line arguments and all the other behaviors needed of a CLI. :lib:knosh-api represents the API from the real logic that :knosh-cli consumes. And central to that AI is KnoshApi, especially its runPrompt() function. As the name suggests, it sends a prompt to an LLM and delivers whatever the LLM sent back as its one-shot response.

Over the next couple of posts in this series, I will take us through what runPrompt() does, as we explore Koog's concepts of providers, models, AI agents, and prompt executors.

Knosh 0.2.0 uses Koog 1.0.0... mostly.

Koog has an interesting take on versioning, and it has nearly 100 artifacts. As I wrote a month ago, Koog might be doing a bit too much.

About half of those artifacts right now are at 1.0.0. The other half are at 1.0.0-beta. Effectively, JetBrains is using a durable -beta designation for stuff that they have not firmed up yet. As we will get into more next week, Koog's support for Ollama, Anthropic, and OpenAI are stable, but Mistral support is not — that remains in 1.0.0-beta as of now.

Next Thursday: Koog's providers and models!