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 #5533] Bug: Changing DeepSeek model or API key resets conversation context (workspace forgets history) #5150

New Issue
Closed
opened 2026-06-05 14:52:19 -04:00 by yindo · 4 comments
yindo commented 2026-06-05 14:52:19 -04:00
Owner
Copy Link
Copy Source

Originally created by @miraitech24 on GitHub (Apr 25, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5533

Problem
When I change the DeepSeek model (e.g., from deepseek-chat to deepseek-v4-flash) or regenerate the API key, the workspace treats every message as a first-time interaction. It does not remember any previous conversation history.

What happens

  • I have a long conversation in a workspace
  • I update the API key or change the model name in LLM settings
  • After saving, the LLM responds as if we've never spoken before
  • Previous messages are still visible in the UI, but the context is NOT sent to the API

What should happen
Changing API keys or model names should NOT break conversation continuity. The workspace should maintain its history and continue sending full context to the new API key/model.

Root cause suspicion
AnythingLLM seems to treat model/key changes as a 'new session' instead of preserving the existing conversation thread. The UI shows old messages, but they are not being included in the API request payload.

Steps to reproduce

  1. Create a workspace
  2. Have a 5+ message conversation with DeepSeek API
  3. Go to Settings → LLM Provider → change model from deepseek-v4-flash to deepseek-v4-pro (or change API key)
  4. Save and return to workspace
  5. Send a follow-up question: 'Based on our previous conversation...'
  6. The LLM has no memory of earlier messages

Expected vs actual

Aspect Expected Actual
Old messages visible in UI ✅ Yes ✅ Yes
Old messages sent to API ✅ Yes (as context) ❌ No
LLM remembers conversation ✅ Yes ❌ No ('新人さん' / first-time user)

Why this matters
LLM APIs are stateless by design — that's correct. The application's job is to manage state. If AnythingLLM fails to send conversation history after settings changes, it's not fulfilling its core purpose as a chat/workspace application.

Additional note
I confirmed the API key is valid using curl:

curl https://api.deepseek.com/v1/chat/completions -H "Authorization: Bearer " ...

Authentication works. The issue is on AnythingLLM's side, not DeepSeek's.

Environment

  • AnythingLLM version: [your version]
  • DeepSeek API with deepseek-v4-flash / deepseek-v4-pro
  • Workspace setting: 'Use workspace LLM settings' (not overriding)
Originally created by @miraitech24 on GitHub (Apr 25, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5533 **Problem** When I change the DeepSeek model (e.g., from deepseek-chat to deepseek-v4-flash) or regenerate the API key, the workspace treats every message as a first-time interaction. It does not remember any previous conversation history. **What happens** - I have a long conversation in a workspace - I update the API key or change the model name in LLM settings - After saving, the LLM responds as if we've never spoken before - Previous messages are still visible in the UI, but the context is NOT sent to the API **What should happen** Changing API keys or model names should NOT break conversation continuity. The workspace should maintain its history and continue sending full context to the new API key/model. **Root cause suspicion** AnythingLLM seems to treat model/key changes as a 'new session' instead of preserving the existing conversation thread. The UI shows old messages, but they are not being included in the API request payload. **Steps to reproduce** 1. Create a workspace 2. Have a 5+ message conversation with DeepSeek API 3. Go to Settings → LLM Provider → change model from deepseek-v4-flash to deepseek-v4-pro (or change API key) 4. Save and return to workspace 5. Send a follow-up question: 'Based on our previous conversation...' 6. The LLM has no memory of earlier messages **Expected vs actual** | Aspect | Expected | Actual | |--------|----------|--------| | Old messages visible in UI | ✅ Yes | ✅ Yes | | Old messages sent to API | ✅ Yes (as context) | ❌ No | | LLM remembers conversation | ✅ Yes | ❌ No ('新人さん' / first-time user) | **Why this matters** LLM APIs are stateless by design — that's correct. The application's job is to manage state. If AnythingLLM fails to send conversation history after settings changes, it's not fulfilling its core purpose as a chat/workspace application. **Additional note** I confirmed the API key is valid using curl: ``` curl https://api.deepseek.com/v1/chat/completions -H "Authorization: Bearer " ... ``` Authentication works. The issue is on AnythingLLM's side, not DeepSeek's. **Environment** - AnythingLLM version: [your version] - DeepSeek API with deepseek-v4-flash / deepseek-v4-pro - Workspace setting: 'Use workspace LLM settings' (not overriding)
yindo added the needs info / can't replicateinvestigating labels 2026-06-05 14:52:19 -04:00
yindo closed this issue 2026-06-05 14:52:19 -04:00
yindo commented 2026-06-05 14:52:19 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Apr 25, 2026):

This is almost certainly a model thing - we are most certainly send the message history with every provider (not just deepseek). That part is normalized across all providers. How are you validating that it does not "remember" anything?

The model could just be that bad at recall - its not impossible!

<!-- gh-comment-id:4318294877 --> @timothycarambat commented on GitHub (Apr 25, 2026): This is almost certainly a model thing - we are most certainly send the message history with every provider (not just deepseek). That part is normalized across all providers. How are you validating that it does not "remember" anything? The model _could_ just be that bad at recall - its not impossible!
yindo commented 2026-06-05 14:52:20 -04:00
Author
Owner
Copy Link
Copy Source

@miraitech24 commented on GitHub (Apr 27, 2026):

Regarding your statement: 'Pinning a document = always viewable like a bulletin board'

Thank you for your response. However, I believe there is a critical misunderstanding here about what 'always viewable' means, which has now been confirmed by my actual usage.

What I expected (and the natural interpretation of 'bulletin board'):

  • I pin a file today.
  • I start a brand new chat session tomorrow.
  • I mention the file.
  • The LLM remembers it.
    → This does NOT happen.

What your documentation and source code say 'Pinning' actually does:

'Pinning: Forces specific documents to always be included in chat context, regardless of similarity scores' (DeepWiki)

Crucially, there is NO mention of cross-session or cross-thread persistence. The implementation detail shows pinnedWorkspaces ties the pin ONLY to the current workspace context.

In simple terms:

  • My expectation (Bulletin Board): 'Pin it once, see it forever in any conversation.'
  • Your design (Sticky Note): 'Pin it for the duration of a single chat session.'

These are completely different features. If my interpretation is wrong, and the feature is actually supposed to work like a bulletin board, then your documentation is incorrect and there is a significant bug in the implementation (likely the same issue reported in #2841, where the API disregards pinned documents).

Could you please clarify:

  1. Is the intended behavior of 'Pinning' to persist the document context across ALL future chats in a workspace (my 'bulletin board' expectation)?
  2. Or is it only scoped to the current active chat session (the current implementation)?
  3. If it is #1, then the feature is broken. If it is #2, then the feature name and description are highly misleading to users.

Thank you.

<!-- gh-comment-id:4324562408 --> @miraitech24 commented on GitHub (Apr 27, 2026): **Regarding your statement: 'Pinning a document = always viewable like a bulletin board'** Thank you for your response. However, I believe there is a critical misunderstanding here about what 'always viewable' means, which has now been confirmed by my actual usage. **What I expected (and the natural interpretation of 'bulletin board'):** - I pin a file today. - I start a brand new chat session tomorrow. - I mention the file. - The LLM remembers it. **→ This does NOT happen.** **What your documentation and source code say 'Pinning' actually does:** > 'Pinning: Forces specific documents to always be included in chat context, regardless of similarity scores' (DeepWiki) Crucially, there is NO mention of cross-session or cross-thread persistence. The implementation detail shows `pinnedWorkspaces` ties the pin ONLY to the current workspace context. **In simple terms:** - **My expectation (Bulletin Board)**: 'Pin it once, see it forever in any conversation.' - **Your design (Sticky Note)**: 'Pin it for the duration of a single chat session.' These are completely different features. If my interpretation is wrong, and the feature is actually supposed to work like a bulletin board, then your documentation is incorrect and there is a significant bug in the implementation (likely the same issue reported in #2841, where the API disregards pinned documents). **Could you please clarify:** 1. Is the intended behavior of 'Pinning' to persist the document context across ALL future chats in a workspace (my 'bulletin board' expectation)? 2. Or is it only scoped to the current active chat session (the current implementation)? 3. If it is #1, then the feature is broken. If it is #2, then the feature name and description are highly misleading to users. Thank you.
yindo commented 2026-06-05 14:52:20 -04:00
Author
Owner
Copy Link
Copy Source

@miraitech24 commented on GitHub (Apr 28, 2026):

根本的な設計思想の欠陥について

度重なる議論、ご対応ありがとうございます。しかし、今回の一連の問題は個別のバグではなく、AnythingLLMの『設計思想の欠陥』に起因している可能性が高いという結論に至りました。

問題の本質:
AnythingLLMは、LLMとユーザーの間に『仲介役』として入り、『ワークスペース』『埋め込み』『ピン留め』といった独自の概念を提供しています。しかし、これらの概念はLLMに伝わるものではなく、単なるローカルの管理タグです。

ユーザーは『ワークスペースにファイルを埋め込んだ』『ピン留めした』という操作をしますが、LLMに伝わるのは『あるテキスト断片がプロンプトに追加された』という事実だけです。その結果、『埋め込みを見える？』『ピン留めしたファイルの内容は？』といったユーザーの問いかけに対して、LLMは『ファイルシステムにアクセスできない』と混乱した回答を返します。

これはバグではなく、設計思想の欠陥です。 なぜなら、システムは設計通りに動作している可能性があるからです。問題は、その『設計』自体がユーザーの期待と現実のLLMの動作を著しく乖離させている点にあります。

提案:
これは技術的に難しい問題ですが、少なくとも以下の2つの方向性で改善できないでしょうか。

  1. UI/UXでの明示: モデルが『埋め込み』『ピン留め』を理解できない仕様であることを、チュートリアルやUI上で明確にユーザーに伝える。
  2. 機能の再設計: ピン留めを『モデルが常に参照すべき事実情報の保存庫』として再設計する。例えば、システムプロンプトに近い形で、ピン留めされたドキュメントの内容を常にコンテキストに挿入する方式への変更。

RAGの本質を変えろとは言いません。しかし、ユーザーが『埋め込み』という機能名から自然に抱く期待と、実際の動作のギャップは、現在大きすぎます。これは製品の競争力を大きく損なう要因です。

長期的な視点での設計の見直しを、ぜひご検討ください。

<!-- gh-comment-id:4332299740 --> @miraitech24 commented on GitHub (Apr 28, 2026): **根本的な設計思想の欠陥について** 度重なる議論、ご対応ありがとうございます。しかし、今回の一連の問題は個別のバグではなく、AnythingLLMの『設計思想の欠陥』に起因している可能性が高いという結論に至りました。 **問題の本質:** AnythingLLMは、LLMとユーザーの間に『仲介役』として入り、『ワークスペース』『埋め込み』『ピン留め』といった独自の概念を提供しています。しかし、これらの概念はLLMに伝わるものではなく、単なるローカルの管理タグです。 ユーザーは『ワークスペースにファイルを埋め込んだ』『ピン留めした』という操作をしますが、LLMに伝わるのは『あるテキスト断片がプロンプトに追加された』という事実だけです。その結果、『埋め込みを見える？』『ピン留めしたファイルの内容は？』といったユーザーの問いかけに対して、LLMは『ファイルシステムにアクセスできない』と混乱した回答を返します。 **これはバグではなく、設計思想の欠陥です。** なぜなら、システムは設計通りに動作している可能性があるからです。問題は、その『設計』自体がユーザーの期待と現実のLLMの動作を著しく乖離させている点にあります。 **提案:** これは技術的に難しい問題ですが、少なくとも以下の2つの方向性で改善できないでしょうか。 1. **UI/UXでの明示**: モデルが『埋め込み』『ピン留め』を理解できない仕様であることを、チュートリアルやUI上で明確にユーザーに伝える。 2. **機能の再設計**: ピン留めを『モデルが常に参照すべき事実情報の保存庫』として再設計する。例えば、システムプロンプトに近い形で、ピン留めされたドキュメントの内容を常にコンテキストに挿入する方式への変更。 RAGの本質を変えろとは言いません。しかし、ユーザーが『埋め込み』という機能名から自然に抱く期待と、実際の動作のギャップは、現在大きすぎます。これは製品の競争力を大きく損なう要因です。 長期的な視点での設計の見直しを、ぜひご検討ください。
yindo commented 2026-06-05 14:52:20 -04:00
Author
Owner
Copy Link
Copy Source

@miraitech24 commented on GitHub (Apr 28, 2026):

検証完了：ピン留めされたファイルの中身はモデルに渡されていない

以下の検証を実施しました。

検証手順:

  1. ファイル BIOCore.csv をアップロードし、ピン留めした
  2. モデルに「今あなたが見えているテキストをすべて表示してください」と依頼した

結果:
モデルが表示したテキストには、以下のものが含まれていました。

  • 会話履歴全文
  • ファイル名（'BIOCore.csv'）

しかし、以下のものは含まれていませんでした。

  • BIOCore.csv の中身
  • 他のピン留めファイルの中身

結論:
AnythingLLMは『ピン留め』されたファイルの中身をモデルに渡していません。『ファイル名』は渡しているため、モデルは『BIOCore.csv』という名前は認識できるが、その内容を知らない、という状態です。

これはバグではなく、設計思想の欠陥です。なぜなら、システムはおそらく『ピン留めされたファイルの中身は渡さない』という設計だからです。

しかし、ユーザーは『ピン留め』という言葉から『そのファイルを永続的にコンテキストに挿入する』と期待します。その期待と実際の動作の乖離が、今回の混乱のすべての原因です。

改善提案:

  1. ピン留めを『ファイルの中身を永続的にコンテキストに挿入する』機能として再設計する
  2. または、現在の動作（ファイル名だけを記憶する）を『お気に入り』や『ブックマーク』など、ユーザーが誤解しない別の名称に変更する

この検証結果をもって、本Issueを『設計思想の欠陥』としてクローズします。今後の設計の参考にしていただければ幸いです。

<!-- gh-comment-id:4332334751 --> @miraitech24 commented on GitHub (Apr 28, 2026): **検証完了：ピン留めされたファイルの中身はモデルに渡されていない** 以下の検証を実施しました。 **検証手順:** 1. ファイル BIOCore.csv をアップロードし、ピン留めした 2. モデルに「今あなたが見えているテキストをすべて表示してください」と依頼した **結果:** モデルが表示したテキストには、以下のものが含まれていました。 - 会話履歴全文 - ファイル名（'BIOCore.csv'） しかし、以下のものは含まれていませんでした。 - BIOCore.csv の中身 - 他のピン留めファイルの中身 **結論:** AnythingLLMは『ピン留め』されたファイルの**中身**をモデルに渡していません。『ファイル名』は渡しているため、モデルは『BIOCore.csv』という名前は認識できるが、その内容を知らない、という状態です。 これはバグではなく、設計思想の欠陥です。なぜなら、システムはおそらく『ピン留めされたファイルの中身は渡さない』という設計だからです。 しかし、ユーザーは『ピン留め』という言葉から『そのファイルを永続的にコンテキストに挿入する』と期待します。その期待と実際の動作の乖離が、今回の混乱のすべての原因です。 **改善提案:** 1. ピン留めを『ファイルの中身を永続的にコンテキストに挿入する』機能として再設計する 2. または、現在の動作（ファイル名だけを記憶する）を『お気に入り』や『ブックマーク』など、ユーザーが誤解しない別の名称に変更する この検証結果をもって、本Issueを『設計思想の欠陥』としてクローズします。今後の設計の参考にしていただければ幸いです。
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 investigating needs info / can't replicate
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#5150
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?