“Chatnik” is a Raku package that provides Command Line Interface (CLI) scripts for conversing with multiple, persistent Large Language Model (LLM) personas. Files of the host Operating System (OS) are used to maintain persistence.
Most importantly, “Chatnik” does not try to entrench users in its own user experience (loop) for interaction with LLMs. Instead, it brings customizable LLM invocations and conversations into the Unix shell — making them composable, integratable, and scriptable with existing workflows.
In other words, the tag line “LLM Host in the Shell” should be understood as “LLMs, not as an app — but as a Unix shell primitive.”
Here are the most notable “Chatnik” features:
Remark: “Chatnik” closely follows the LLM-chat objects interaction system of the Raku package “Jupyter::Chatbook”, [AAp3].(Using OS shell instead of Jupyter notebooks.)
The rest of this document is organized as follows:
The examples in this section demonstrate how the CLI scripts llm-chat and llm-chat-meta — provided by “Chatnik” — are used to have multi-turn LLM conversations and compose Unix shell pipelines with LLM interaction messages.
Remark: Instead of llm-chat and llm-chat-meta, the CLI script chatnik can be used: chatnik invokes llm-chat, and chatnik meta invokes llm-chat-meta.
Remark: The prompts used in the examples are provided by the Raku package “LLM::Prompts”, [AAp2]. Since many of the prompts of that package have dedicated pages at the Wolfram Prompt Repository (WPR) the examples use WPR reference links.
Here we create an LLM persona — by naming it and “priming it” with a prompt — and start interacting with it:
Here we continue the conversation — using the -i synonym of --chat-id and no-quotes message argument:
And continue the discussion some more:
The example used the LLM persona “Yoda”.
(See more LLM personas here.)
Here we specify a pipeline for
Remark: In the shell command above, llm-chat created (or reused) a chat object with the default identifier “NONE”.
Here we use prompt expansion to request the creation of a Mermaid-JS diagram via the
prompt “CodeWriterX”:
Since the result is given in Markdown code fences we take the last message via the CLI script llm-meta-chat,
then use sed to remove the first and last lines, and then pass that text to the terminal
Mermaid-JS visualizer mmdflux:
┌──────┐ ┌───────┐
│ User │ │ Space │
└───┬──┘ └───┬───┘
│ │
│─Thinks space is big─────────────>│
│ │
│ │ ┌──────────────────────────────────────────────┐
│ │ │ Space is vastly, hugely, mind-bogglingly big │
│ │ └──────────────────────────────────────────────┘
│ │
│─Compares to drug store distance─>│
│ │
│ │ ┌──────────────────────────────────────────────┐
│ │ │ Drug store distance is just peanuts to space │
│ │ └──────────────────────────────────────────────┘
│ │
Remark: Since the result is usually given in Markdown code fences, we did not make a pipeline to plot the diagram. We used two shell commands in order to observe the intermediate result.
Remark: The default object identifier for both llm-chat and llm-chat-object is “NONE”.
Here is a very practical example — this document was copy-edited with the prompt “CopyEdit” using the following commands:
(And, yes, the LLM copy-edited version was evaluated, and some edits were rejected.)
Most LLM interfaces — both “big” popular ones and those built by developers experimenting with LLMs — default to an application-centric design: a closed interaction loop with implicit state. This pattern is convenient, but very limiting. It can be cynically seen as an intentional effort for user lock-in or just as an attempt to impose certain user-experience views. It works against the “freedom enabling” Unix design principles. (Such as composability, transparency, and scriptability.)
With “Chatnik”, instead of adapting workflows to fit an LLM application, LLM capabilities are brought into the shell as first-class primitives. This enables reuse of existing tooling (pipes, redirects, scripts) and aligns LLM interaction with long-established UNIX practices.
“Chatnik” is a composition of existing capabilities rather than a ground-up implementation:
Remark: Related to the last point above, the following quote is attributed to Ken Thompson about UNIX:
We have persistent objects, they’re called files.
Remark: Less obnoxiously, instead of saying that LLM providers expose messy, non-uniform APIs, we can say that their APIs “are individually reasonable, but collectively inconsistent.” Because of the popularity of OpenAI’s models, many LLM providers adhere to a degree with OpenAI’s API. Still, the APIs — collectively — have inconsistent schemas, authorization, streaming, tool-calling, roles, etc.
“Chatnik” is useful because it places LLM capabilities in a natural manner into Unix shell workflows:
grep, awk, sed) can be combined with LLM outputs
The following flowchart summarizes the computational components and their interactions fairly well:
Here is a concise narration of the flow:
Chatnik is built around the principle that LLM interaction should behave like a native shell capability, not a siloed application.
A command issued in the OS shell is treated as the entry point into a composable pipeline, where LLM calls can participate alongside standard UNIX tools.
State is externalized and file-backed, not hidden in process memory.
Chat sessions are represented as chat objects that are ingested from and persisted to the file system.
This makes conversations durable, inspectable, and naturally versionable using existing OS tools.
Chat identity is explicit but optional.
When a chat ID is provided, the corresponding conversation is resumed; when absent or unknown, a new chat object is created.
This allows both ad-hoc interactions and long-lived conversational contexts without friction.
Prompting is treated as a programmable layer.
Inputs are not passed directly to models; they are first parsed through a lightweight DSL.
Known prompts are expanded from a prompt repository, enabling reuse, parameterization, and standardization of interactions.
LLM invocation is abstracted but not obscured.
Evaluation is delegated to “LLM::Functions”, which provides a uniform interface over multiple providers, including OpenAI (ChatGPT), Google (Gemini), and Ollama.
This keeps provider choice flexible while preserving a consistent workflow.
The system is designed for composability and integration.
Each stage—state ingestion, prompt processing, evaluation, and persistence—can be understood as part of a pipeline.
This makes LLM interactions scriptable, chainable, and interoperable with existing command-line utilities.
Persistence is a first-class outcome of every interaction.
Every evaluation both returns a result to the shell and updates the underlying chat object store, ensuring that conversational context evolves incrementally and reliably.
In short. To reiterate the point in the introduction, “Chatnik” treats LLMs as shell-native, stateful, and programmable primitives —
aligning conversational AI with the philosophy of UNIX pipelines rather than application-bound interfaces.
In this section, we point to Raku packages that are both ingredients of, and alternatives to, “Chatnik”.
The creation and interaction LLM-chat object functionalities are provided by “LLM::Functions”, [AAp1].
Prompt collection, prompt spec DSL, and related prompt expansion are provided by “LLM::Prompts”, [AAp2]. The CLI script llm-prompt of “LLM::Prompts” can be used to examine, retrieve, and concretize prompts. For example, here it can be seen the full text of the function prompt “MermaidDiagram” with given arguments:
In some cases it is more convenient to use llm-prompt than prompt expansion. For example:
Access to LLMs is provided by the packages “WWWW::OpenAI”, “WWWW::Gemini”, “WWW::MistralAI”, “WWW::LLaMA”, “WWW::Ollama”.
Each of these packages has a corresponding CLI script that is an alternative to llm-chat:
| Package | CLI |
|---|---|
| WWW::OpenAI | openai-playground |
| WWW::Gemini | gemini-prompt |
| WWW::MistralAI | mistralai-playground |
| WWW::LLaMA | llama-playground |
| WWW::Ollama | ollama-client |
The package “LLM::DWIM”, [BDp1], is similar in spirit to “Chatnik”, and it is also based on the LLM packages “LLM::Functions”, [AAp1], and “LLM::Prompts”, [AAp2].
There are significant differences, however, in that “LLM::DWIM”:
The Raku package “Jupyter::Chatbook” uses the same evaluation mechanisms as “Chatnik”, but its interactive environment is a Jupyter notebook instead of an OS shell. The Python package “JupyterChatbook” and the Wolfram Language paclet “Chatbook” are also notebook alternatives to “Chatnik”.
[AA1] Anton Antonov, “Jupyter::Chatbook”, (2023), RakuForPrediction at WordPress.
[AA2] Anton Antonov, “Jupyter::Chatbook Cheatsheet”, (2026), RakuForPrediction at WordPress.
[AA3] Anton Antonov, “Jupyter Chatbook Cheatsheet”, (2026), PythonForPrediction at WordPress.
[AAp1] Anton Antonov, LLM::Functions, Raku package, (2023-2026), GitHub/antononcube.
[AAp2] Anton Antonov, LLM::Prompts, Raku package, (2023-2025), GitHub/antononcube.
[AAp3] Anton Antonov, Jupyter::Chatbook, Raku package, (2023-2026), GitHub/antononcube.
[AAp4] Anton Antonov, Data::Translators, Raku package, (2023-2026), GitHub/antononcube.
[AAp5] Anton Antonov, JupyterChatbook, Python package, (2023-2026), GitHub/antononcube.
[BDp1] Brian Duggan, LLM::DWIM, Raku package, (2024-2025), GitHub/bduggan.
[CGp1] Connor Gray, et al. Chatbook, Wolfram Language paclet, (2023-2024), Wolfram Language Paclet Repository.
[AAv1] Anton Antonov, “Integrating Large Language Models with Raku”, (2023), The Raku Conference 2023 at YouTube.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。