Auto Sync
I’m on BoltAI 2.16.0 (build 85) and I have cloud sync enabled. Since there is no auto sync, I have to manually click on settings > Cloud Sync > Sync to Cloud which is really cumbersome. I’d like to see auto syncing on an interval that can be configured by the user.
r2lux 1 day ago
Feature Requests
Auto Sync
I’m on BoltAI 2.16.0 (build 85) and I have cloud sync enabled. Since there is no auto sync, I have to manually click on settings > Cloud Sync > Sync to Cloud which is really cumbersome. I’d like to see auto syncing on an interval that can be configured by the user.
r2lux 1 day ago
Feature Requests
Give BoltAI a Real Knowledge Base, Not Just Document Dumping
Why I'm Writing This I use BoltAI for quick tasks, writing, and code help, and it's good at that. But I also run a personal knowledge base of over 1,100 Markdown documents — 491 YouTube video transcripts, a published book, legal case files, product research, and travel guides — and BoltAI can't touch it. The reason is simple: BoltAI doesn't do retrieval at all. When you attach a document, the whole thing gets stuffed into the context window. That works for a single short file. It breaks down completely the moment someone has a real knowledge base rather than a handful of documents, because there's no way to attach 1,100 files to a single chat, and no mechanism to find the two or three that actually answer a question. I've built a system from plain files and SQLite that finds the right document out of that 1,100 and answers correctly almost every time. Nothing in it is exotic. Most of it would translate directly into BoltAI. Here's how it works and what I'd suggest you build. How My System Works (The Reference Architecture) The core idea: retrieval and context are two different jobs. Search finds the right document. The full document — not a chunk of it — is what goes to the model. The setup: One folder, plain Markdown, as the source of truth. Every piece of knowledge is a structured .md file in a numbered folder hierarchy. No proprietary format, no lock-in. YAML frontmatter on every file. Each document carries kb_id, title, domain, and tags. These are first-class retrieval signals, not decoration. A query about "Simpson Desert tyre pressure" matches on domain and tags before any embedding maths happens. A database that stores complete documents. A local SQLite database holds every document in full — title, full text, metadata, one row per document. It rebuilds from the files every 2 hours via upsert, so it never drifts and never duplicates. A cloud copy (Supabase) adds vector embeddings for semantic search. Universal ingest with a complete internal scrape. Anything can be dropped in: PDF, Word, plain text, email, web page, video. Videos are transcribed with Whisper into one MD file per video. PDFs and other documents are converted into a complete structured text representation — the full content, restructured with headings, not a sampled extract. The original goes to archive; the complete text version lives in the knowledge base forever. Hybrid search over a section index, full documents in context. The index knows about 11,700+ sections across the documents and searches them with combined lexical (BM25) and semantic scoring. Sections are only signposts. When the model answers, it reads the entire matched document. Used with Claude, this setup finds the right information across 1,100+ documents with an accuracy BoltAI has no way to approach today — not because BoltAI's model is worse, but because it never gets to see the right document in the first place. Where BoltAI Falls Short Today BoltAI's document handling is attach-and-dump: the full content of whatever you attach goes into the prompt. There's no index, no search step, no concept of "which of my documents is relevant to this question." That's fine for one document. It's not a knowledge base feature — it's a paste-a-file feature with extra steps. Ask BoltAI "summarise what I've written about the Simpson Desert" or "what tyre press
Stephan Fischer 3 days ago
Feature Requests
Give BoltAI a Real Knowledge Base, Not Just Document Dumping
Why I'm Writing This I use BoltAI for quick tasks, writing, and code help, and it's good at that. But I also run a personal knowledge base of over 1,100 Markdown documents — 491 YouTube video transcripts, a published book, legal case files, product research, and travel guides — and BoltAI can't touch it. The reason is simple: BoltAI doesn't do retrieval at all. When you attach a document, the whole thing gets stuffed into the context window. That works for a single short file. It breaks down completely the moment someone has a real knowledge base rather than a handful of documents, because there's no way to attach 1,100 files to a single chat, and no mechanism to find the two or three that actually answer a question. I've built a system from plain files and SQLite that finds the right document out of that 1,100 and answers correctly almost every time. Nothing in it is exotic. Most of it would translate directly into BoltAI. Here's how it works and what I'd suggest you build. How My System Works (The Reference Architecture) The core idea: retrieval and context are two different jobs. Search finds the right document. The full document — not a chunk of it — is what goes to the model. The setup: One folder, plain Markdown, as the source of truth. Every piece of knowledge is a structured .md file in a numbered folder hierarchy. No proprietary format, no lock-in. YAML frontmatter on every file. Each document carries kb_id, title, domain, and tags. These are first-class retrieval signals, not decoration. A query about "Simpson Desert tyre pressure" matches on domain and tags before any embedding maths happens. A database that stores complete documents. A local SQLite database holds every document in full — title, full text, metadata, one row per document. It rebuilds from the files every 2 hours via upsert, so it never drifts and never duplicates. A cloud copy (Supabase) adds vector embeddings for semantic search. Universal ingest with a complete internal scrape. Anything can be dropped in: PDF, Word, plain text, email, web page, video. Videos are transcribed with Whisper into one MD file per video. PDFs and other documents are converted into a complete structured text representation — the full content, restructured with headings, not a sampled extract. The original goes to archive; the complete text version lives in the knowledge base forever. Hybrid search over a section index, full documents in context. The index knows about 11,700+ sections across the documents and searches them with combined lexical (BM25) and semantic scoring. Sections are only signposts. When the model answers, it reads the entire matched document. Used with Claude, this setup finds the right information across 1,100+ documents with an accuracy BoltAI has no way to approach today — not because BoltAI's model is worse, but because it never gets to see the right document in the first place. Where BoltAI Falls Short Today BoltAI's document handling is attach-and-dump: the full content of whatever you attach goes into the prompt. There's no index, no search step, no concept of "which of my documents is relevant to this question." That's fine for one document. It's not a knowledge base feature — it's a paste-a-file feature with extra steps. Ask BoltAI "summarise what I've written about the Simpson Desert" or "what tyre press
Stephan Fischer 3 days ago
Feature Requests
In Progress
Bolt Hangs
Hello, Any idea why Bolt Ai now constantly hangs when using my Ai workflow shortcut for text and spelling correction?? Cheers Stefan
Stephan Fischer 4 days ago
Feature Requests
In Progress
Bolt Hangs
Hello, Any idea why Bolt Ai now constantly hangs when using my Ai workflow shortcut for text and spelling correction?? Cheers Stefan
Stephan Fischer 4 days ago
Feature Requests
In QA
MCP Writes and Edits hang - formerly with Gemini Pro 2.5, now with Claude Sonnet 5.0:
BoltAI MCP Tool-Call Hang: Technical Report Date stamp: 260912 Reporter: Nigel Protter (existing Featurebase reports below) Scope: Local MCP filesystem server tool calls (write_file, edit_file) issued from an AI agent session running inside BoltAI on macOS. 1. Summary Two distinct fault mechanisms were observed during a single BoltAI chat session using a local stdio MCP filesystem server. Both produce the same visible symptom: a tool call appears to stop progressing, with a "Continue" or "Continue generating" control appearing in the UI, and no corresponding tool-result content in the model-visible transcript. 2. Environment OS: macOS (build/version not captured in-session; to be supplied by reporter) BoltAI version/build: not captured in-session; to be supplied by reporter MCP server: local stdio filesystem server (custom, exposing write_file, edit_file, get_file_info, read_text_file, list_directory, among others) Model in use during observation: Claude (Sonnet), accessed via BoltAI's chat interface 3. Fault Mechanism A: Tool-Call Relay Hang Sequence observed: The model issues a tool call (e.g. edit_file) to the MCP server. Screenshots of the BoltAI window show the tool-call block in a "Running tool: ..." state. In at least one occurrence, that running-state block disappeared from the visible history entirely on the next screen state, replaced by a "Continue" or "Continue generating" control, with no result block and no error message rendered. The model's own transcript contains no corresponding tool-result for that call — from the model's side, the call simply never returned. Disk state was checked directly via a separate get_file_info call after the stall. In one occurrence the target file was confirmed unchanged (the write had not reached disk). In a separate occurrence in the same session, the stall occurred immediately after a trivial, already-completed read-only shell command, with no write pending at all, indicating the stall is not exclusively tied to write payload delivery. 4. Fault Mechanism B: Large-Payload Write Non-Return Sequence observed: A write_file call was issued with a content payload of approximately 11,000 characters (11 KB), targeting a new file. The call entered a running state in the BoltAI UI and did not return a result for the remainder of the session turn. No error was surfaced. No tool-result block was produced in the model's transcript for that call. Directory listing after the stall confirmed the target file was never created on disk. A control test was then run: a write_file call with a 4-byte payload to a new file. That call returned a success result immediately, and the file was confirmed present on disk via get_file_info. This establishes that the write pathway is not universally blocked; the fault is correlated with, but not conclusively proven to be caused by, larger single-call payload size. 5. Escalation Test Log A controlled escalation test was run: successive edit_file append calls of increasing size against a single target file, with get_file_info verification after each. StepPayload sizeResult 1 4 bytes (write_file to new file)
Nigel Protter 4 days ago
Bug Reports
In QA
MCP Writes and Edits hang - formerly with Gemini Pro 2.5, now with Claude Sonnet 5.0:
BoltAI MCP Tool-Call Hang: Technical Report Date stamp: 260912 Reporter: Nigel Protter (existing Featurebase reports below) Scope: Local MCP filesystem server tool calls (write_file, edit_file) issued from an AI agent session running inside BoltAI on macOS. 1. Summary Two distinct fault mechanisms were observed during a single BoltAI chat session using a local stdio MCP filesystem server. Both produce the same visible symptom: a tool call appears to stop progressing, with a "Continue" or "Continue generating" control appearing in the UI, and no corresponding tool-result content in the model-visible transcript. 2. Environment OS: macOS (build/version not captured in-session; to be supplied by reporter) BoltAI version/build: not captured in-session; to be supplied by reporter MCP server: local stdio filesystem server (custom, exposing write_file, edit_file, get_file_info, read_text_file, list_directory, among others) Model in use during observation: Claude (Sonnet), accessed via BoltAI's chat interface 3. Fault Mechanism A: Tool-Call Relay Hang Sequence observed: The model issues a tool call (e.g. edit_file) to the MCP server. Screenshots of the BoltAI window show the tool-call block in a "Running tool: ..." state. In at least one occurrence, that running-state block disappeared from the visible history entirely on the next screen state, replaced by a "Continue" or "Continue generating" control, with no result block and no error message rendered. The model's own transcript contains no corresponding tool-result for that call — from the model's side, the call simply never returned. Disk state was checked directly via a separate get_file_info call after the stall. In one occurrence the target file was confirmed unchanged (the write had not reached disk). In a separate occurrence in the same session, the stall occurred immediately after a trivial, already-completed read-only shell command, with no write pending at all, indicating the stall is not exclusively tied to write payload delivery. 4. Fault Mechanism B: Large-Payload Write Non-Return Sequence observed: A write_file call was issued with a content payload of approximately 11,000 characters (11 KB), targeting a new file. The call entered a running state in the BoltAI UI and did not return a result for the remainder of the session turn. No error was surfaced. No tool-result block was produced in the model's transcript for that call. Directory listing after the stall confirmed the target file was never created on disk. A control test was then run: a write_file call with a 4-byte payload to a new file. That call returned a success result immediately, and the file was confirmed present on disk via get_file_info. This establishes that the write pathway is not universally blocked; the fault is correlated with, but not conclusively proven to be caused by, larger single-call payload size. 5. Escalation Test Log A controlled escalation test was run: successive edit_file append calls of increasing size against a single target file, with get_file_info verification after each. StepPayload sizeResult 1 4 bytes (write_file to new file)
Nigel Protter 4 days ago
Bug Reports
In QA
Hiding Setapp models or disabling it as a model provider
I am using BoltAI via a Setapp subscription, which introduces a slight inconvenience regarding model selection. My Setapp plan does not include AI credits, yet BoltAI still detects Setapp as an active model provider, populating a long list of OpenAI models. Whenever I search for "gpt" to find models linked to my own OpenAI API key, the Setapp models appear in the results as well, often taking priority at the top of the list. Currently, there seems to be no option to hide or disable Setapp models, whereas other providers allow you to toggle specific models on or off. Would you consider adding the ability to disable Setapp as a provider, or hide its models from the selector, in a future update?
Max M. 6 days ago
Feature Requests
In QA
Hiding Setapp models or disabling it as a model provider
I am using BoltAI via a Setapp subscription, which introduces a slight inconvenience regarding model selection. My Setapp plan does not include AI credits, yet BoltAI still detects Setapp as an active model provider, populating a long list of OpenAI models. Whenever I search for "gpt" to find models linked to my own OpenAI API key, the Setapp models appear in the results as well, often taking priority at the top of the list. Currently, there seems to be no option to hide or disable Setapp models, whereas other providers allow you to toggle specific models on or off. Would you consider adding the ability to disable Setapp as a provider, or hide its models from the selector, in a future update?
Max M. 6 days ago
Feature Requests
In QA
Are MCP and AI preferences completely broken?
For the past six months i’ve been using BoltAI, MCP and AI preferences have not worked for me. Yes, I have read all the posts and the web. New project chats do not inherit MCP server or default AI settings. New Projects do do not inherit MCP server or default AI settings. Preferences seem useless. I have to set all MCP server settings and the AI with every chat spawned to a project row. I have to set set all MCP server settings and the AI with every new Project. Also, there are three separate places to enter AI settings. Settings are a hot mess.
Nigel Protter 12 days ago
Bug Reports
In QA
Are MCP and AI preferences completely broken?
For the past six months i’ve been using BoltAI, MCP and AI preferences have not worked for me. Yes, I have read all the posts and the web. New project chats do not inherit MCP server or default AI settings. New Projects do do not inherit MCP server or default AI settings. Preferences seem useless. I have to set all MCP server settings and the AI with every chat spawned to a project row. I have to set set all MCP server settings and the AI with every new Project. Also, there are three separate places to enter AI settings. Settings are a hot mess.
Nigel Protter 12 days ago
Bug Reports
Custom Icon for Project in Toolbar
Maybe it’s silly but I’d love to be able to change the folder icon for each of my projects to an emoji of my choice. Then I can keep my projects apart visually. 🧠
Mandy Steinhardt 17 days ago
Feature Requests
Custom Icon for Project in Toolbar
Maybe it’s silly but I’d love to be able to change the folder icon for each of my projects to an emoji of my choice. Then I can keep my projects apart visually. 🧠
Mandy Steinhardt 17 days ago
Feature Requests
In QA
Silent failures with Opus 5
Hi, I keep finding that Opus 5 requests fail silently. I put in a fairly long prompt, hit enter, it goes away thinking for awhile, then just stops. No response, no error, no nothing. Refreshing the prompt tends to create the same effect. If I switch to an OpenAi model, it then works. v 2.15.0 (build 84) on macOS 26.5.2
Eric Bowman 23 days ago
Bug Reports
In QA
Silent failures with Opus 5
Hi, I keep finding that Opus 5 requests fail silently. I put in a fairly long prompt, hit enter, it goes away thinking for awhile, then just stops. No response, no error, no nothing. Refreshing the prompt tends to create the same effect. If I switch to an OpenAi model, it then works. v 2.15.0 (build 84) on macOS 26.5.2
Eric Bowman 23 days ago
Bug Reports
In QA
License immediately "forgotten"
Just purchased a Pro license for the latest-and-greatest BoltAI, entered the code, everything looked good: cute confetti animation, congrats, etc. However, I’m soon pestered to “Link Cloud Account” to recognize the license, but that keeps failing with “This license is not active”. Sure enough, when I click Settings went to the License tab, it claims that my license is revoked/deactivated. Restarting BoltAI doesn’t help. I just visited the License Manager web page, and everything looks fine / matches-up over there. Bizarre and (obviously) frustrating.
matti 28 days ago
Bug Reports
In QA
License immediately "forgotten"
Just purchased a Pro license for the latest-and-greatest BoltAI, entered the code, everything looked good: cute confetti animation, congrats, etc. However, I’m soon pestered to “Link Cloud Account” to recognize the license, but that keeps failing with “This license is not active”. Sure enough, when I click Settings went to the License tab, it claims that my license is revoked/deactivated. Restarting BoltAI doesn’t help. I just visited the License Manager web page, and everything looks fine / matches-up over there. Bizarre and (obviously) frustrating.
matti 28 days ago
Bug Reports
In QA
web_fetch server_tool_use block sent without its tool_result → Anthropic 400 on next turn
OS version: macOS 26.6 BoltAI app version: 2.15.0 Setapp user: No AI provider & model: Anthropic, Claude (extended thinking on, web_fetch tool enabled) Steps to reproduce: Start an Anthropic chat with the web_fetch server tool enabled. Ask something that makes the model call web_fetch, and let it also emit regular tool_use blocks in the same assistant turn. Continue the conversation for at least one more turn. Error message: messages.1: web_fetch tool use with id srvtoolu_01RYeaAtRGtJzhpnvMWP8ys7 was found without a corresponding web_fetch_tool_result block What's actually wrong: When BoltAI rebuilds the messages array for the follow-up request, the web_fetch_tool_result block belonging to the MOST RECENT server_tool_use is dropped. Earlier web_fetch calls in the same thread are paired correctly — only the latest one loses its result. Once another turn is appended after it, that server_tool_use is a permanent orphan in the history and every subsequent request 400s. The chat is unrecoverable without editing history. Note on the error text: Anthropic reports the wrong index. It says "messages.1" but the id it quotes belongs to a much later assistant message. Match by block id, not by the index in the message. Expected: the web_fetch_tool_result is persisted alongside its server_tool_use and replayed in every subsequent request. Note: the 2.15.0 changelog entry about "Anthropic-powered chats occasionally failing after tool calls when using extended thinking" does not fix this — I'm on 2.15.0 and still hitting it.
Brendan DeBeasi 29 days ago
Bug Reports
In QA
web_fetch server_tool_use block sent without its tool_result → Anthropic 400 on next turn
OS version: macOS 26.6 BoltAI app version: 2.15.0 Setapp user: No AI provider & model: Anthropic, Claude (extended thinking on, web_fetch tool enabled) Steps to reproduce: Start an Anthropic chat with the web_fetch server tool enabled. Ask something that makes the model call web_fetch, and let it also emit regular tool_use blocks in the same assistant turn. Continue the conversation for at least one more turn. Error message: messages.1: web_fetch tool use with id srvtoolu_01RYeaAtRGtJzhpnvMWP8ys7 was found without a corresponding web_fetch_tool_result block What's actually wrong: When BoltAI rebuilds the messages array for the follow-up request, the web_fetch_tool_result block belonging to the MOST RECENT server_tool_use is dropped. Earlier web_fetch calls in the same thread are paired correctly — only the latest one loses its result. Once another turn is appended after it, that server_tool_use is a permanent orphan in the history and every subsequent request 400s. The chat is unrecoverable without editing history. Note on the error text: Anthropic reports the wrong index. It says "messages.1" but the id it quotes belongs to a much later assistant message. Match by block id, not by the index in the message. Expected: the web_fetch_tool_result is persisted alongside its server_tool_use and replayed in every subsequent request. Note: the 2.15.0 changelog entry about "Anthropic-powered chats occasionally failing after tool calls when using extended thinking" does not fix this — I'm on 2.15.0 and still hitting it.
Brendan DeBeasi 29 days ago
Bug Reports
Can I dictate in Chinese?
Is there any way to do that, whether on a local model or via API to other providers?
resting about 1 month ago
Feature Requests
Can I dictate in Chinese?
Is there any way to do that, whether on a local model or via API to other providers?
resting about 1 month ago
Feature Requests
In QA
Constant halts using MCP file/directory reads/writes/searches per this:
BoltAI2's MCP file tools are thin wrappers around POSIX file APIs. They're designed for simplicity, not scale. The serializer bottleneck (JSON validation before payload size check) is architectural—it affects ANY tool in this MCP server that uses JSON parameter arrays. The serializer limit is a BoltAI2 server constraint, not a file-tool defect. Even if you swapped the underlying tool, you'd hit the same JSON validation ceiling on the MCP protocol layer. Better Strategy Than Tool Swapping: Instead of replacing BoltAI2's tools, adopt a hybrid workflow: For reads >100 kB: Use ripgrep-based search tools (no size limit on results). For writes >1,500 chars: Pre-split into chunks BEFORE calling edit_file (we're already doing this). For bulk file ops: Use the mcp__directory_tree_17ba7w to get the structure first, then target individual small edits. For escape-sensitive paths with spaces: NEVER use bash; always use the file tool wrappers.
Nigel Protter about 2 months ago
Bug Reports
In QA
Constant halts using MCP file/directory reads/writes/searches per this:
BoltAI2's MCP file tools are thin wrappers around POSIX file APIs. They're designed for simplicity, not scale. The serializer bottleneck (JSON validation before payload size check) is architectural—it affects ANY tool in this MCP server that uses JSON parameter arrays. The serializer limit is a BoltAI2 server constraint, not a file-tool defect. Even if you swapped the underlying tool, you'd hit the same JSON validation ceiling on the MCP protocol layer. Better Strategy Than Tool Swapping: Instead of replacing BoltAI2's tools, adopt a hybrid workflow: For reads >100 kB: Use ripgrep-based search tools (no size limit on results). For writes >1,500 chars: Pre-split into chunks BEFORE calling edit_file (we're already doing this). For bulk file ops: Use the mcp__directory_tree_17ba7w to get the structure first, then target individual small edits. For escape-sensitive paths with spaces: NEVER use bash; always use the file tool wrappers.
Nigel Protter about 2 months ago
Bug Reports
In QA
Bug: Instant chat bar on Mac app enters endlessly looping spasm of thinking and responses
Your OS version. Tahoe 26.4.1 Your BoltAI app version. 2.14.0 (build 77) Are you a Setapp user. No. The AI provider & model you’re using. OpenRouter. DeepSeek V4 Flash. Steps to reproduce the issue. Start a chat with the instant chat bar. See the video below to see what happens maybe ~20% of the time. The error message. NA.
Matt about 2 months ago
Bug Reports
In QA
Bug: Instant chat bar on Mac app enters endlessly looping spasm of thinking and responses
Your OS version. Tahoe 26.4.1 Your BoltAI app version. 2.14.0 (build 77) Are you a Setapp user. No. The AI provider & model you’re using. OpenRouter. DeepSeek V4 Flash. Steps to reproduce the issue. Start a chat with the instant chat bar. See the video below to see what happens maybe ~20% of the time. The error message. NA.
Matt about 2 months ago
Bug Reports
In QA
Error messages about API keys being encrypted
Tahoe 26.6 BoltAl 2 Version 2.14.0 (build 77) Not on setup I get random error messages about wanting a master password because my APIkeys are encrypted. 1) I have not encrypted them 2) Sometimes the same model is working and after restaing Bolt it is not ¯|(ツ)/¯
Christian Hofer about 2 months ago
Bug Reports
In QA
Error messages about API keys being encrypted
Tahoe 26.6 BoltAl 2 Version 2.14.0 (build 77) Not on setup I get random error messages about wanting a master password because my APIkeys are encrypted. 1) I have not encrypted them 2) Sometimes the same model is working and after restaing Bolt it is not ¯|(ツ)/¯
Christian Hofer about 2 months ago
Bug Reports
iOS App doesn't send image properly to llama-server
I share the same extract text from image prompt for gemma4 from macOS and iOS, but iOS never “gets” the file.
FossilizedCarlos about 2 months ago
Feature Requests
iOS App doesn't send image properly to llama-server
I share the same extract text from image prompt for gemma4 from macOS and iOS, but iOS never “gets” the file.
FossilizedCarlos about 2 months ago
Feature Requests
Allow Ollama provider to support Ollama Cloud directly
Currently I have added Ollama Cloud to BoltAI 2 as a custom OpenAI provider, howevr it would be nice (cosmetically) if the endpoint https://ollama.com could be added to the Ollama provider, along with an API key so that the Ollama icon is used.
paulgit 2 months ago
Feature Requests
Allow Ollama provider to support Ollama Cloud directly
Currently I have added Ollama Cloud to BoltAI 2 as a custom OpenAI provider, howevr it would be nice (cosmetically) if the endpoint https://ollama.com could be added to the Ollama provider, along with an API key so that the Ollama icon is used.
paulgit 2 months ago
Feature Requests
Add support for Cursor API
https://cursor.com/en-US/docs/cloud-agent/api/endpoints#create-an-agent describes how to access the Cursor via API-Key. Yet we’re not able to access their models, e.g. composer 2.5. Please add Cursor in the list of AI-Providers
Johannes H 2 months ago
Feature Requests
Add support for Cursor API
https://cursor.com/en-US/docs/cloud-agent/api/endpoints#create-an-agent describes how to access the Cursor via API-Key. Yet we’re not able to access their models, e.g. composer 2.5. Please add Cursor in the list of AI-Providers
Johannes H 2 months ago
Feature Requests
In QA
Local MCP server 𝐓𝐨𝐨𝐥-𝐂𝐚𝐥𝐥 𝐋𝐨𝐨𝐩 𝐁𝐮𝐠
The hanging behavior is a known technical issue in the integration between the local client application (the chat interface or terminal wrapper) and the LLM API. It is called a Tool-Call Loop Hang. Here is the step-by-step sequence that causes the freeze: AI Initiates Tool: The user requests a file modification or read. The AI generates a tool call (e.g., mcp_edit_file_6lpu9l) and stops generating text, as required by the API protocol. MCP Server Executes: The local MCP server successfully executes the file edit and returns the result (the diff or file contents) to the client application. The Integration Gap (The Hang): In a fully automated integration, the client application is supposed to immediately feed the tool's output back to the LLM to trigger the next text generation turn. However, in this specific client setup, the application fails to auto-trigger the next turn. It pauses and waits. The Wake-Up: Because the client is waiting for the AI, and the AI is waiting for the client to send the tool results, the interface hangs. When the user types any message (e.g., "are you stuck again?"), it forces the client application to package the entire conversation history—including the pending tool results—and send it to the LLM. This instantly wakes the AI up, resulting in the immediate "AI-OK" response. 𝐇𝐨𝐰 𝐭𝐨 𝐅𝐢𝐱 𝐨𝐫 𝐌𝐢𝐭𝐢𝐠𝐚𝐭𝐞 𝐭𝐡𝐞 𝐈𝐬𝐬𝐮𝐞 Client-Side Configuration (Permanent Fix): The developer of the client application or terminal wrapper must update the execution logic. The client must automatically post the tool output back to the LLM API endpoint to request the next completion turn without waiting for manual user input. User Workaround (Immediate Fix): Whenever a tool call completes (you will see the green tool response block in the interface) and the interface pauses for more than 3 seconds, type a single character (such as a period . or go) and press Enter. This forces the client to send the tool results to the LLM and resumes execution instantly. AI Mitigation (Combining Steps): The AI will minimize sequential tool calls where possible, combining reads or edits into single multi-file operations to reduce the number of turn transitions.
Nigel Protter 2 months ago
Bug Reports
In QA
Local MCP server 𝐓𝐨𝐨𝐥-𝐂𝐚𝐥𝐥 𝐋𝐨𝐨𝐩 𝐁𝐮𝐠
The hanging behavior is a known technical issue in the integration between the local client application (the chat interface or terminal wrapper) and the LLM API. It is called a Tool-Call Loop Hang. Here is the step-by-step sequence that causes the freeze: AI Initiates Tool: The user requests a file modification or read. The AI generates a tool call (e.g., mcp_edit_file_6lpu9l) and stops generating text, as required by the API protocol. MCP Server Executes: The local MCP server successfully executes the file edit and returns the result (the diff or file contents) to the client application. The Integration Gap (The Hang): In a fully automated integration, the client application is supposed to immediately feed the tool's output back to the LLM to trigger the next text generation turn. However, in this specific client setup, the application fails to auto-trigger the next turn. It pauses and waits. The Wake-Up: Because the client is waiting for the AI, and the AI is waiting for the client to send the tool results, the interface hangs. When the user types any message (e.g., "are you stuck again?"), it forces the client application to package the entire conversation history—including the pending tool results—and send it to the LLM. This instantly wakes the AI up, resulting in the immediate "AI-OK" response. 𝐇𝐨𝐰 𝐭𝐨 𝐅𝐢𝐱 𝐨𝐫 𝐌𝐢𝐭𝐢𝐠𝐚𝐭𝐞 𝐭𝐡𝐞 𝐈𝐬𝐬𝐮𝐞 Client-Side Configuration (Permanent Fix): The developer of the client application or terminal wrapper must update the execution logic. The client must automatically post the tool output back to the LLM API endpoint to request the next completion turn without waiting for manual user input. User Workaround (Immediate Fix): Whenever a tool call completes (you will see the green tool response block in the interface) and the interface pauses for more than 3 seconds, type a single character (such as a period . or go) and press Enter. This forces the client to send the tool results to the LLM and resumes execution instantly. AI Mitigation (Combining Steps): The AI will minimize sequential tool calls where possible, combining reads or edits into single multi-file operations to reduce the number of turn transitions.
Nigel Protter 2 months ago
Bug Reports
In QA
Main window not visible on launch
I have reopen windows when logging in checked during shutdown. But most times, after a restart, the main window doesn’t show when I switch to the app via Cmd+Tab. I believe its the same behavior if I tap on the dock icon. While restarting the app works, it’s starting to get to me since I don’t quit it. Hopefully its a quick fix?
resting 2 months ago
Bug Reports
In QA
Main window not visible on launch
I have reopen windows when logging in checked during shutdown. But most times, after a restart, the main window doesn’t show when I switch to the app via Cmd+Tab. I believe its the same behavior if I tap on the dock icon. While restarting the app works, it’s starting to get to me since I don’t quit it. Hopefully its a quick fix?
resting 2 months ago
Bug Reports
View Thoughts
I love to review the reasoning behind the output for any given post. I really like the way you have the reasoning/thoughts displayed while the model is processing, but upon completion, I see that the “View Thoughts” section is then constricted to a very small popup window. I’d love to be able to expand the “View Thoughts” section and read it in the main window along with the output. Maintaining the same formatting as it has while streaming would be really cool.
david.sheley 2 months ago
Feature Requests
View Thoughts
I love to review the reasoning behind the output for any given post. I really like the way you have the reasoning/thoughts displayed while the model is processing, but upon completion, I see that the “View Thoughts” section is then constricted to a very small popup window. I’d love to be able to expand the “View Thoughts” section and read it in the main window along with the output. Maintaining the same formatting as it has while streaming would be really cool.
david.sheley 2 months ago
Feature Requests