llm.rb
Ruby's capable AI runtime: one coherent API across 14+ providers, zero runtime dependencies, with concurrent tool execution for building agentic applications on CRuby.
Evidence shows: MCP tool allowlist, Guard hooks (policy/quotas), Transformers for redaction, zero runtime deps by default, fork isolation. Deductions: `confirm` appears only as an option name with no documented confirmation defaults; built-in shell/filesystem tools (LLM::Tool::Exec etc.) lack documented permission/consent semantics; no rollback mechanism described; publisher unverified, only author attribution (Robert Gleeson) confirmable.
Evidence shows: default Guard::Loop protection, retry budgets, timeout/cancellation (LLM::Interrupt), CI matrix across Ruby versions and JSON parsers. Deductions: README typos (Aftter/providied); error/failure-path semantics only partially documented (unknown set keys raise, Interrupt).
Evidence shows: 14+ providers, six concurrency strategies, multiple transports, DB integrations, CLI and console — scenario coverage is broad. Deductions: no documentation of trigger precision (when a tool/skill fires), and no stated capability boundaries or unsuitable use-cases.
Evidence shows: well-structured README (install, quick start, collapsible topics), full MIT license, many runnable examples, optional-dependency install notes, CI workflows present. Deductions: no CHANGELOG or version history; no known-limitations section (only scattered notes such as compactor opt-in).
Evidence shows: single API across providers, structured outputs, Schema, persistence, ready-to-use CLI — clear marginal value for building agents. Deductions: cost/benefit only partially evidenced (price sorting in registry, tool_budget/retry_budget named without examples); no quantified cost-control evidence.
Evidence shows: API-doc links (self-hosted), CI config corroborating optional deps (curb, pg), models.dev sourcing. Deductions: heavy reliance on self-referential sources (r.uby.dev docs/chatbot); claims like DeepSeek SVG generation are not statically verifiable; no independent corroboration.
- Default permission boundaries of built-in Exec/filesystem tools are undocumented; configure a Guard and verify the actual behavior of the confirm mechanism before production use.
- Publisher identity is unverified; feature claims (e.g., DeepSeek extensions) come only from self-hosted docs and need independent verification.
- No CHANGELOG or known-limitations section; review diffs and pin versions before upgrading.
What does this agent do, and when should you use it?
llm.rb (repository r-uby-dev/llm) is a runtime for building agentic AI applications on CRuby, with zero runtime dependencies by default and a single coherent API spanning 14+ providers including Anthropic, OpenAI, DeepSeek, Google, Ollama, and llama.cpp. Its high-level interface, LLM::Agent, automatically manages tool execution, guards against infinite loops, and maintains conversation state, while LLM::Stream exposes structured callbacks for content, reasoning, tool calls, and compaction. The runtime ships first-class MCP and A2A protocol support, LLM::Schema structured outputs, LLM::Guard tool-call policy hooks, LLM::Transformer message rewriting, LLM::Compactor context-window management, and OpenTelemetry-based observability. Persistence ranges from filesystem JSON to ActiveRecord and Sequel (with PostgreSQL b optimization), and a curses-based interactive console plus an llm.rb CLI are bundled. It is MIT-licensed and also mirrored on the Radicle network.
After gem install llm.rb, developers create a provider via class-level factories (e.g. LLM.deepseek, LLM.openai), hand it to LLM::Agent, and drive turns with agent.talk. The agent can execute: Ruby tools as LLM::Tool subclasses (with a built-in catalog of filesystem, search, and shell tools, run under one of six concurrency strategies: :async/:thread/:fiber/:fork/:ractor/:sequential); markdown-defined Skills that spawn a fresh, stateless subagent per call; tools from MCP servers via LLM::MCP.stdio/.http; and remote A2A agent skills via LLM::A2A.rest. LLM::Schema yields validated JSON structured outputs, LLM::Guard can let through, cancel, block, or answer tool calls (LLM::Guard::Loop protection is on by default), LLM::Transformer rewrites outgoing messages, LLM::Compactor::Truncate keeps conversations within the context window, and 429s and timeouts are retried automatically up to retry_budget (default five). LLM::Agent#interrupt! aborts a request mid-stream from any thread and interrupts running tools. The embedding API (llm.embed) supports RAG with sqlite-vec/pgvector; OpenAI, Google, xAI, and DeepInfra generate images, and DeepSeek generates SVG graphics through its text model.
- Ruby/Rails developers who need to integrate multiple LLM providers and switch between them with a one-line change.
- Teams building agents that use filesystem, shell, or search tools and require concurrent or parallel tool execution.
- Teams with an ActiveRecord/Sequel stack that want database-backed chatbots (as the r.uby.dev chatbot does with acts_as_agent and b).
- Integrations that need remote MCP servers or A2A agents exposed as local agent tools.
- Budget-conscious developers using cheap models like DeepSeek while gaining structured outputs and image (SVG) generation as runtime enhancements.
- Developers who want to debug agents, test tools, and manage sessions interactively via the curses console or the llm.rb CLI.
What are this agent's strengths and limitations?
- Zero runtime dependencies by default, with one API across 14+ providers; switching providers is a one-line factory change.
- Six concurrency strategies (including true parallelism via :fork/:ractor) plus interrupt!/cancel! for fine-grained tool execution control.
- First-class MCP and A2A support, with tools, skills, compactors, guards, and tracers all debuggable in the curses console.
- One-column ActiveRecord/Sequel persistence alongside filesystem JSON, sharing the same serialization.
- Built-in model registry (sourced from models.dev) with catalogs, pricing, context windows, and modalities, sortable by price.
- Some concurrency strategies need opt-in dependencies: :async requires the async gem, :fork requires xchan.rb, and :fiber requires you to supply a Fiber.scheduler.
- Newer features (Skills, A2A) tie into the maintainer's personal ecosystem (r.uby.dev, roda-llm), and the project is primarily maintained by one person, a bus-factor risk.
- Runtime support is CRuby-focused; the README mentions a separate mruby-llm runtime that requires backporting changes.
- Tool execution is :sequential by default; parallelism requires explicitly choosing a strategy and accepting its dependency costs.
- DeepSeek image generation is SVG-only, and its structured outputs are simulated by the runtime rather than an official API capability.
How do you install or deploy this agent?
Install the gem:
gem install llm.rbFor the full console experience, install optional dependencies separately:
gem install unicode-display_width curses kramdown xchan.rb test-cmd.rbSet API keys via environment variables (e.g. DEEPSEEK_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY); local providers (Ollama, llama.cpp) typically need no key.
How do you use this agent?
Minimal example:
require "llm"llm = LLM.deepseek(key: ENV["KEY"])
agent = LLM::Agent.new(llm, stream: $stdout)
agent.talk "hello world"Add custom tools by defining LLM::Tool subclasses (name/description/parameter/required, implement call) and passing tools:. Persistence: LLM::Agent.new(llm, path: "session.") saves and restores sessions automatically. Database persistence: require "llm/active_record" and use acts_as_agent(format: :b) on a model. CLI: run llm.rb (auto-detects provider from env vars), llm.rb -p openai to pick a provider, llm.rb -t for a temporary session; sessions persist under ~/.llm.rb/. MCP: mcp = LLM::MCP.stdio(argv: ["ruby", "server.rb"]) then pass mcp.tools to the Agent.
How does this agent compare with similar options?
The README names no direct competitors, but by positioning llm.rb is the Ruby-ecosystem agentic runtime analogous to Python-ecosystem LLM agent frameworks; its differentiators are zero dependencies, native CRuby concurrency (fiber/ractor/fork), and built-in MCP/A2A support.