Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5081] # [BUG]: Agent mode completely broken in v1.11.0 — "Invalid regular expression: missing /" #4906

New Issue
Closed
opened 2026-06-05 14:50:47 -04:00 by yindo · 2 comments
yindo commented 2026-06-05 14:50:47 -04:00
Owner
Copy Link
Copy Source

Originally created by @Kartosko on GitHub (Feb 27, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5081

How are you running AnythingLLM?

AnythingLLM desktop app (Windows)

Version

AnythingLLM v1.11.0
Ollama v0.16.2 (also tested with v0.17.1)

What happened?

After updating to AnythingLLM v1.11.0, all @agent invocations fail immediately with the error:

Could not respond to message.
Invalid regular expression: missing /

This happens with every model I have available (tested with multiple Qwen3 variants via Ollama). Normal chat mode works fine — only the @agent mode is broken.

This is a critical issue because all custom skills and agent tools are only accessible via @agent, making the entire agent/skill system unusable.

Additional issue: num_ctx type error

Additionally, v1.11.0 introduced a separate bug where the "Model context window" field sends num_ctx as a string instead of an integer to Ollama, causing:

option "num_ctx" must be of type integer

Workaround found: clearing the "Model context window" field (setting it to "Auto-detected from model") resolves the num_ctx issue, but there is no workaround for the @agent regex error.

Steps to reproduce

  1. Install AnythingLLM v1.11.0 (Desktop, Windows)
  2. Configure Ollama as LLM provider with any model
  3. Open any workspace
  4. Type @agent ciao (or any message with @agent)
  5. Agent invokes, then immediately fails with "Invalid regular expression: missing /"

Expected behavior

@agent should process the request and respond normally, as it did in previous versions (v1.10.x and earlier).

Suspected cause

The v1.11.0 release notes mention: chore: bump ollama SDK from 0.5.10 to 0.6.3. This SDK update likely introduced a breaking change in how agent responses are parsed (regex parsing of model output).

Environment

  • OS: Windows
  • AnythingLLM: v1.11.0 (Desktop)
  • LLM Provider: Ollama v0.16.2
  • Models tested: ByteShape Qwen3-30B (and others) — all fail
  • GPU: NVIDIA RTX 5090
Originally created by @Kartosko on GitHub (Feb 27, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5081 ## How are you running AnythingLLM? AnythingLLM desktop app (Windows) ## Version AnythingLLM v1.11.0 Ollama v0.16.2 (also tested with v0.17.1) ## What happened? After updating to AnythingLLM v1.11.0, **all @agent invocations fail immediately** with the error: ``` Could not respond to message. Invalid regular expression: missing / ``` This happens with **every model** I have available (tested with multiple Qwen3 variants via Ollama). Normal chat mode works fine — only the @agent mode is broken. This is a critical issue because **all custom skills and agent tools are only accessible via @agent**, making the entire agent/skill system unusable. ## Additional issue: num_ctx type error Additionally, v1.11.0 introduced a separate bug where the "Model context window" field sends `num_ctx` as a string instead of an integer to Ollama, causing: ``` option "num_ctx" must be of type integer ``` **Workaround found:** clearing the "Model context window" field (setting it to "Auto-detected from model") resolves the num_ctx issue, but there is no workaround for the @agent regex error. ## Steps to reproduce 1. Install AnythingLLM v1.11.0 (Desktop, Windows) 2. Configure Ollama as LLM provider with any model 3. Open any workspace 4. Type `@agent ciao` (or any message with @agent) 5. Agent invokes, then immediately fails with "Invalid regular expression: missing /" ## Expected behavior @agent should process the request and respond normally, as it did in previous versions (v1.10.x and earlier). ## Suspected cause The v1.11.0 release notes mention: `chore: bump ollama SDK from 0.5.10 to 0.6.3`. This SDK update likely introduced a breaking change in how agent responses are parsed (regex parsing of model output). ## Environment - OS: Windows - AnythingLLM: v1.11.0 (Desktop) - LLM Provider: Ollama v0.16.2 - Models tested: ByteShape Qwen3-30B (and others) — all fail - GPU: NVIDIA RTX 5090
yindo closed this issue 2026-06-05 14:50:47 -04:00
yindo commented 2026-06-05 14:50:48 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Feb 27, 2026):

Im guessing you discovered this was a client side issue since you closed it? What was the root cause and solution?

<!-- gh-comment-id:3973949287 --> @timothycarambat commented on GitHub (Feb 27, 2026): Im guessing you discovered this was a client side issue since you closed it? What was the root cause and solution?
yindo commented 2026-06-05 14:50:48 -04:00
Author
Owner
Copy Link
Copy Source

@Kartosko commented on GitHub (Feb 27, 2026):

Hi, thanks for the quick reply!

The num_ctx issue is actually NOT fully resolved — I just found a workaround.

Root cause: When a value is set in the "Model context window" field (Advanced Settings under LLM Preference), AnythingLLM passes num_ctx as a string (e.g. "65536") instead of an integer (65536) to the Ollama API. Recent versions of Ollama now enforce strict type validation and reject this with: option "num_ctx" must be of type integer.

Important note: I tested with both AnythingLLM 1.11.0 and 1.10.x — the issue is present in both versions. This suggests it has always been passed as a string, but older Ollama versions were more permissive and accepted it anyway. The breaking change is on Ollama's side (stricter type checking), but the fix should be in AnythingLLM — casting num_ctx to integer before sending it to the API.

My workaround: I created custom Ollama models with PARAMETER num_ctx 131072 baked into the Modelfile, so the context length is set at the model level and AnythingLLM doesn't need to pass it.

Suggested fix: In the Ollama connector code, cast the context window value to integer before including it in the API request, something like:

num_ctx: parseInt(contextWindow) || undefined

About the @agent regex error I originally reported: That turned out to be caused by one of my custom agent skills that had literal newline characters inside JavaScript regex patterns. Not an AnythingLLM bug — my fault.

Summary:

  • num_ctx is passed as string → should be integer (bug in AnythingLLM, exposed by newer Ollama versions)
  • Agent regex error was my custom skill — not an AnythingLLM bug

Hope this helps!

<!-- gh-comment-id:3973989858 --> @Kartosko commented on GitHub (Feb 27, 2026): Hi, thanks for the quick reply! The `num_ctx` issue is actually NOT fully resolved — I just found a workaround. **Root cause:** When a value is set in the "Model context window" field (Advanced Settings under LLM Preference), AnythingLLM passes `num_ctx` as a **string** (e.g. `"65536"`) instead of an **integer** (`65536`) to the Ollama API. Recent versions of Ollama now enforce strict type validation and reject this with: `option "num_ctx" must be of type integer`. **Important note:** I tested with both AnythingLLM 1.11.0 and 1.10.x — the issue is present in both versions. This suggests it has always been passed as a string, but older Ollama versions were more permissive and accepted it anyway. The breaking change is on Ollama's side (stricter type checking), but the fix should be in AnythingLLM — casting `num_ctx` to integer before sending it to the API. **My workaround:** I created custom Ollama models with `PARAMETER num_ctx 131072` baked into the Modelfile, so the context length is set at the model level and AnythingLLM doesn't need to pass it. **Suggested fix:** In the Ollama connector code, cast the context window value to integer before including it in the API request, something like: ```js num_ctx: parseInt(contextWindow) || undefined ``` **About the @agent regex error I originally reported:** That turned out to be caused by one of my custom agent skills that had literal newline characters inside JavaScript regex patterns. Not an AnythingLLM bug — my fault. **Summary:** - `num_ctx` is passed as string → should be integer (bug in AnythingLLM, exposed by newer Ollama versions) - Agent regex error was my custom skill — not an AnythingLLM bug Hope this helps!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4906
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?