llm.rb 15.5.0 → 16.0.0.pre.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: df1a9b7fbf194f568b95f3f1b2d0314bb703027bc89e4432109d118f238ea2ba
-  data.tar.gz: 679938a2f6538f9c1999d31870462498393e1b3a7c7203630c5e8706c893e9ce
+  metadata.gz: 89404c839d44cd5a11c59fdd56d396a64f50447996a03c01216eb928aed4c28a
+  data.tar.gz: f040e94e577c068690b7bae08900468408d1dd0985bd6d40ebc239eab60ea4a8
 SHA512:
-  metadata.gz: 49151bad60a22a06b119e08062e58c6d35727d59d10e07d9921166a23b5817083ea11fe942a090bc0e64b68a06340b9cf175a87ecfa81775dffcc7d88a8abb0c
-  data.tar.gz: 92ddc3cd73f7af70f25e735fd8ac63dcbca6ed48fd78ba3510be0171ea180d006f399ff60e215bdf1b9159e52b721916c59fcb7278c322fb0ffe789db5900602
+  metadata.gz: c466492b003222fd3411b2777aa982663e50330600a2b69c1bd7d2fce9180576ccfc59230140fb392d584a1dddf45307c09fc785b7c7fc06d158aa3ec11230c7
+  data.tar.gz: 2da69855287105e2926045fdef7ef346be4fc4189f5e8659eb03829e85ae136a4fc5660506dee14ef7c933775e6790bacda9acedf1e4d4c438b61fc4730a584c

data/CHANGELOG.md

@@ -15,7 +15,85 @@
 
 ## What's next
 
-*No unreleased changes yet. Check back after the next release.*
+### Breaking
+
+#### Migration
+
+| Old | New |
+|-----|-----|
+| Ruby 3.3 or later | Ruby 3.4 or later |
+
+* **drop Ruby 3.3 support** <br>
+  The gem now requires Ruby 3.4 or later: `required_ruby_version` is
+  `>= 3.4.0`, the CI matrix runs 3.4 and 4.0, and RuboCop targets 3.4.
+  Ruby 3.3 cannot hold an interrupt for a ractor-backed tool call, so a
+  cancel that arrives before the tool starts is not delivered there, while
+  Ruby 3.4 and 4.0 both deliver it.
+
+### Console
+
+* **console: erase with the backspace key on OpenBSD** <br>
+  The console now erases a character for every code a backspace key sends. A
+  terminal that follows the Linux convention sends DEL (127), the OpenBSD
+  console sends ^H (8), and curses sends its own `KEY_BACKSPACE` when the
+  terminal's terminfo describes the key. All three erase. Before this only 127
+  did, so the backspace key did nothing on the OpenBSD console.
+
+### Function
+
+* **function: deliver an interrupt to the tool, not to whatever is running** <br>
+  [`LLM::Function::Window`](https://r.uby.dev/api-docs/llm.rb/LLM/Function/Window.html)
+  is the stretch of a call that an interrupt belongs to. The `:fork` and
+  `:ractor` strategies now raise `LLM::Interrupt` on the thread that runs
+  the tool, and only while the tool runs: a cancel that arrives before the
+  tool starts is held until it does, so the tool's own `rescue` can handle
+  it, and one that arrives after the tool has returned is a no-op, which no
+  longer throws the result away. Before this, the interrupt was raised on
+  the child process's or the ractor's main thread wherever that thread had
+  got to.
+
+* **function: answer a ractor-backed task once its ractor has gone** <br>
+  A `:ractor` tool's result is handed to a ractor the task holds it in,
+  rather than asked of the ractor that ran the tool, which answers `alive?`
+  while the tool runs and goes once the result is in. So a wait that arrives
+  after the tool has run is answered, a second wait is answered from memory,
+  the way
+  [`LLM::Function::Thread::Task#wait`](https://r.uby.dev/api-docs/llm.rb/LLM/Function/Thread/Task.html#wait-instance_method)
+  answers from the thread's value, and `alive?` answers `false` once the task
+  has been waited on. A cancel returns `nil` rather than raising, which is what
+  lets
+  [`LLM::Function::Ractor::Group#interrupt!`](https://r.uby.dev/api-docs/llm.rb/LLM/Function/Ractor/Group.html#interrupt!-instance_method)
+  reach every task it holds. Before this, a wait that arrived once the tool had
+  run raised `Ractor::ClosedError` or never came back, a cancel raised the same
+  error, and a group's cancel stopped at the first task that had already
+  returned, leaving the calls after it uncancelled.
+
+### Provider
+
+* **deepseek: support image attachments in chat completions** <br>
+  DeepSeek's vision models now take an image through the chat completions
+  adapter. A tagged prompt object of kind `:image_url` is sent as an `image_url`
+  content item, and a local image file is sent as a base64 encoded data URI.
+  Anything else is rejected with a reason of its own: a remote file or an
+  `LLM::Response` raises
+  [`LLM::PromptError`](https://r.uby.dev/api-docs/llm.rb/LLM/PromptError.html)
+  because DeepSeek has no Files API, so a file id cannot be resolved, and a
+  local file that is not an image raises because DeepSeek's models read images
+  only.
+
+### Registry
+
+* **refresh model metadata** <br>
+  Update `data/` with current model listings, limits, and pricing. Alibaba adds
+  `qwen3.5-flash`, `qwen3.7-flash`, and `qwen3.8-omni-flash`, and gives
+  `qwen3.7-plus` attachments, structured output, and a lower price; OpenAI adds
+  `gpt-daybreak-blue-latest` and `gpt-daybreak-red-latest`; Bedrock adds
+  `openai.gpt-6-sol` and `openai.gpt-6-luna`; and DeepInfra adds
+  `tencent/Hy4-preview` and the Xiaomi MiMo V2.6 Pro and V2.6 Flash models.
+  Bedrock also corrects the context and output limits of fifteen models, Google
+  lowers the limits of `gemini-2.5-computer-use-preview-10-2025` and
+  `gemini-3-pro-image`, and OpenRouter adds four models, drops six, and reprices
+  many of the DeepSeek, Z.ai, and Qwen entries.
 
 ## v15.5.0
 

data/README.md

@@ -14,18 +14,17 @@
 
 Welcome to the canonical llm.rb repository.
 
-llm.rb is an advanced runtime for building agentic AI applications
+llm.rb is a runtime for building agentic AI applications
 on CRuby. It has zero runtime dependencies by default, supports
 concurrent and parallel tool execution and has a single coherent API
 that spans 14+ providers.
 
-It is possible to see llm.rb in action on the
+See llm.rb in action on the
 [the r.uby.dev website](https://r.uby.dev) where
-I am working on building an agentic platform that
-users can use to manage multiple agents that are
-specialized in different areas, and have access to
-different services (eg GitHub, etc). Check it out if
-curious. Still in early development.
+I am building a platform that supports users who have
+personalized agents with access to different services
+(eg GitHub, etc). Check it out if curious.
+**Still in early development.**
 
 ## Install
 
@@ -53,9 +52,12 @@ model as an in-band error that allows the model to correct course.
 A lot of care also goes into keeping the tool loop from entering
 an invalid state that would lead to API-level errors. For example,
 when a tool call is interrupted it could leave an unanswered tool
-call that a model will reject on the next turn. The runtime takes
-care of this by pruning orphaned tool calls and ensuring that the
-tool loop always remains valid.
+call that a model will reject on the next turn. The runtime closes
+every tool call that has no return before the next request is sent,
+and each one is answered with an in-band return of its own. The
+conversation a provider sees is therefore always valid, and a
+cancelled call is something the model is told about rather than
+something that quietly disappears.
 
 ```ruby
 require "llm"
@@ -666,8 +668,7 @@ agent = LLM::Agent.new(llm, tools: [LLM::Tool::Exec, ReadFile], guard: PolicyGua
 <br>
 
 It is possible to rewrite outgoing messages before they reach the provider with
-[`LLM::Transformer`](https://r.uby.dev/api-docs/llm.rb/LLM/Transformer.html).
-Create a subclass and implement `call(message:)` to scrub sensitive data,
+[`LLM::Transformer`](https://r.uby.dev/api-docs/llm.rb/LLM/Transformer.html). Create a subclass and implement `call(message:)` to scrub sensitive data,
 inject context, or normalize content. The transform runs automatically
 on every turn, so you never have to change your prompt code.
 
@@ -1109,9 +1110,8 @@ It is battle tested daily.
 The console that is distributed with llm.rb is used
 to build llm.rb so there is a healthy, active feedback
 loop. It also powers the [r.uby.dev](https://r.uby.dev)
-website where multiple llm.rb agents are deployed with
-the help of [roda-llm](https://github.com/r-uby-dev/roda-llm).
-I'm also aware of at least one production Rails deployment
+website where multiple llm.rb agents are deployed. I'm
+aware of at least one production Rails deployment
 at a large-ish company.
 
 And this git repository includes llm.rb agents that help me
@@ -1121,20 +1121,6 @@ there is a large test suite that covers live requests (recorded
 by VCR) and database interactions.
 </details>
 
-## See also
-
-The [roda-llm](https://github.com/r-uby-dev/roda-llm#readme) project
-is how I deploy multiple ActiveRecord-backed llm.rb agents over HTTP.
-Each agent has an identical interface at a unique path that provide
-CRUD operations and stream support (via SSE - Server Side Events).
-It lets you focus on implementing agents rather than the glue that
-brings them together. It is implemented as a Roda plugin that could
-be hosted within a Rails application or other Rack-based applications.
-
-The [docs/](docs/) directory contains the full documentation and
-the chatbot can find the answers to your questions there. Or you
-can read them yourself. :)
-
 ## License
 
 This software is released under the terms of the MIT license. <br>