The primary reason tools cannot be invoked is that the model you're using isn't included in https://models.dev. You can search to see if your model exists. If it does exist, there might be an issue with the recorded capabilities for that model, indicating it doesn't support tool invocation. Alternatively, the model itself may inherently lack tool invocation capabilities, such as models in the Deepseek series. The current workaround is to locate the corresponding model within its Provider on the Settings page and manually enable its Tool Calling capability:

yetone 6 months ago

💡

Feature Request

描述： Alma 离线期间，Telegram 服务器缓存的多条消息在上线后被逐条拉取，每条独立创建为新 thread，导致左侧聊天列表出现大量单条对话。 而离线结束后从同个对话发送的消息，因走实时通道，又能正确归属于已有 thread。 建议： 在批量拉取离线消息时，增加一个聚合逻辑—— 按 sender（同一来源账号） 按消息时间差（如相邻消息间隔 < 5 分钟） 上线后拉取的第一批缓存消息归入同一个 thread 而不是「每拉一条就开一个新 thread」。 复现场景： 离线期间从 TG 发 n 条消息 → 上线后左侧出现 n 个独立 thread → 再从 TG 发一条 → 归入最后一个 thread。

oppih Xue 2 days ago

💡

Feature Request

更新最新的版本后，使用Quick Chat 快捷键等待弹出窗口需要 1 到 2 分钟

钟俊杰 2 days ago

💡

Feature Request

Edit 工具在 Windows 下损坏 CRLF 换行符 环境 项目 值 OS Windows (\r\n CRLF) 工作目录 C:\JIUWU\platform\lowshop 文件类型 Java 源码 (.java) 日期 2026-06-15 现象 调用 Edit 工具修改文件后，文件中每行之间出现多余空行。Git diff 显示整个文件所有行都被标记为变更。 根因 用 cat -A 检查原始字节，发现换行符从正常的 ^M$（\r\n）变成了 ^M^M$（\r\r\n）——多了一个回车符。 修改前： TUserRequestLog finalRequestLog = new TUserRequestLog();^M$ try {^M$ 修改后： TUserRequestLog finalRequestLog = new TUserRequestLog();^M^M$ finalRequestLog.setId(id);^M^M$ try {^M^M$ 复现步骤 在 Windows 环境下，对任意 CRLF 文本文件调用 Edit 工具 用 cat -A 查看文件原始内容，换行符变为 \r\r\n 影响范围 每次 Edit 后都需要手动修复 Git 历史污染（diff 显示全文件变更） 代码可读性差（IDE 中显示多余空行） 临时 Workaround tr -d '\r' < file | unix2dos > file.tmp && mv file.tmp file 期望行为 Edit 工具应保持原文件的换行符格式不变，不额外插入 \r。

唇洁 5 days ago

🐛

Bug Reports

使用 codex-acp:gpt-5.5 作为模型时，新线程的第一条 Assistant 回复前会被自动拼入： Hi. What would you like to work on? 复现现象： 只发生在新线程第一条 Assistant 消息 历史保存的线程 markdown 中也能看到该句被写入正文 普通聊天模型没有这个问题 当前使用 @zed-industries/codex-acp@0.16.0 本机进程显示 Alma 启动了 node /usr/local/bin/codex-acp -> codex-acp 推测原因： ACP/Codex agent 初始化时返回的默认 greeting 没有被 Alma 过滤，导致它被当作正常 assistant content 拼接到首条回复里。 期望： Alma 在 ACP 会话初始化阶段过滤 Hi. What would you like to work on? 这类默认 greeting，或者不要把 agent 初始化消息写入用户可见回复和线程历史。

亚马逊的雪 6 days ago

🐛

Bug Reports

### Bug: Auto-update 下载完成后静默安装失败 **版本**: 0.0.806 → 0.0.825（以及更早版本） **平台**: macOS (arm64) #### 现象 - 自动更新能正常检测和下载更新包到 ~/Library/Caches/alma-updater/ - 但下载完后从不自动安装，App 重启后仍是旧版本 - alma update install 同样返回 "restarting with new version" 但实际没生效 #### 根因 macOS 下 electron-updater 依赖 Squirrel.Mac 的 ShipIt 替换 App Bundle。当 Squirrel 首次启动安装失败（LaunchAgent 未注册），autoUpdater.quitAndInstall() 静默失败——API 返回了 {status: "installing"}，底层什么都没做。 #### 代码层 ```js // /api/update/install handler this.app.post("/api/update/install", (e, t) => { t.json({ status: "installing" }), setTimeout(() => ui(), 1000) }) function ui() { Qr().quitAndInstall(!1, !0) } ``` 逻辑本身没问题，但 quitAndInstall() 失败时没有 try/catch、没有版本号校验、没有错误回调。 #### 建议修复 重启后做一次版本号自检，如果版本号未变就向前端返回安装失败。 #### 临时 workaround ```bash unzip -o ~/Library/Caches/alma-updater/pending/alma-*.zip -d /tmp/alma-update/ cp -R /tmp/alma-update/Alma.app /Applications/Alma.app ```

Wei Chang 6 days ago

💡

Feature Request

想请yetone大人能不能解决一下 Windows 的 UI 问题。 比如说上面的 Python 显示不对称，它显示在整个聊天框的中间，其实很影响体感，并且代码是截断的没有自动换行之类的。

Ma Marg 7 days ago

1

💡

Feature Request

在macOS上，只要点击chrome extension，就会在`~/`下建立`alma/chrome-extension`文件夹。此外还会建立默认的工作空间文件夹、配置文件夹(`~/.alma`)。感觉这些有点乱。能否增加功能，可以修改chrome extensionm默认的手工安装位置？（我个人会倾向于放到工作空间的文件夹下面） 谢谢

ern 7 days ago

💡

Feature Request

Windows版本，一直没有自动重命名会话的功能。

Hongqiu Gu 7 days ago

💡

Feature Request

Version Alma v0.0.822 Environment OS: Windows App type: Electron desktop app Install path: D:\Program Files\Alma Problem After a fresh install or after clearing app data, the sidebar is visible on the first launch. However, after closing and reopening Alma, the sidebar disappears visually. The task/thread list is no longer visible, but clicking in the original sidebar area still works: the hidden thread/task items can still be selected. So the sidebar is not removed from the DOM and is not collapsed. It is only invisible. Reproduction Steps Install Alma or clear Alma user data. Launch Alma. Confirm the sidebar is visible. Close Alma. Launch Alma again. The sidebar becomes invisible. Click where thread/task items should be; they are still clickable. Actual Behavior The sidebar container remains mounted and interactive, but is rendered with opacity 0. Runtime DOM inspection shows: className: absolute left-0 top-0 h-screen z-10 transition-all duration-500 ease-in-out opacity-0 opacity: 0 pointer-events: auto width: 256 height: 752 The sidebar content text is still present in the DOM. Expected Behavior The sidebar should be visible after relaunch, or if it is intentionally hidden, it should not continue receiving pointer events. Suspected Cause This appears to be caused by the initial reveal animation state. In the renderer bundle: PersistentSidebar uses sidebarVisible ? "opacity-100" : "opacity-0". RevealProvider initializes sidebarVisible as false. After onboarding is dismissed, AppContent calls startReveal(true). On cold launch after onboarding has already been dismissed, the reveal state sometimes does not advance to sidebarVisible: true, leaving the sidebar stuck at opacity-0. This does not look like the sidebar data, width, or collapsed state is broken. It looks like a renderer reveal-state race during startup. Suggested Fix For users who have already completed onboarding, avoid relying on the delayed reveal animation for the persistent sidebar. For example: if (dismissed && !needsPermissionsStep) { markHasLaunchedBefore() setIsMainVisible(true) skipReveal() } Or initialize the reveal state as already visible for returning users. Also, as a defensive fix, invisible sidebar state should disable hit testing: sidebarVisible ? "opacity-100" : "opacity-0 pointer-events-none" This would prevent the confusing state where the sidebar is invisible but still clickable. Workaround Manually changing the sidebar container from opacity-0 to opacity-100 in DevTools makes it visible again for the current session, but the issue can return after relaunch.

Rui Du 7 days ago

🐛

Bug Reports

找了半天没找到，配置了optional{ "anthropic": { "thinking": { "type": "enabled", "budgetTokens": 16000 }, "effort": "max" } }就可以了吗，前端左下角还是推理强度还是默认显示中等

安静永动机 9 days ago

2

💡

Feature Request

弹窗报错

debugbb 9 days ago

8

🐛

Bug Reports

我想问下现在minimaxi的话是手动添建供应商还是已经可以直接配置了 我没找到minimax的这个选项

gwofanzhang 11 days ago

💡

Feature Request

描述： 我在 Windows 上使用 Alma 的 Claude Subscription / Claude CLI 模式时遇到问题。这个问题是在从 8.1.0 升级到 8.1.1 后开始出现的，8.1.0 版本没有遇到这个问题。 问题 1： Alma 显示 “Claude CLI not found”，但实际上 Claude Code 已经通过 npm 全局安装，并且命令行里可以正常运行。 环境： 系统：Windows Alma 版本：8.1.1 上一个正常版本：8.1.0 Claude Code 路径：C:\Users\22965\AppData\Roaming\npm\claude.exe claude --version 输出：2.1.161 (Claude Code) 可能原因： Alma 的 Claude CLI 检测逻辑似乎调用了 which claude。 但 Windows 默认没有 which 命令，Windows 下应该使用 where claude，或使用支持 PATHEXT 的跨平台可执行文件查找方式。 问题 2： 绕过检测问题后，Claude Subscription 模式的回复里会出现工具调用/历史消息内容，例如： Human: [tool result] {"stdout":"...","stderr":"","exitCode":0,"cwd":"..."} AssistantHuman: 这些内容看起来是内部工具调用结果或历史消息转换时产生的，不应该出现在最终回复里。 期望行为： Windows 下应该能正确检测到已安装的 Claude Code。 工具调用结果不应该以 [tool result]、stdout、stderr、exitCode 等原始文本形式混入 Claude 的上下文或最终回复。 空的 Human: / Assistant: 前缀也不应该出现在回复中。 可能修复方向： Windows 下使用 where claude，或使用跨平台命令查找逻辑。 在 Claude CLI 历史消息转换时，跳过 tool 类型消息，或者用结构化方式传递工具结果，避免把工具 JSON 当成普通聊天文本拼进 prompt。

Lateautumns 13 days ago

2

💡

Feature Request

官网的 Download 模块显示，linux coming soon，我还以为没 linux 版本呢。

msdone 13 days ago

💡

Feature Request

当 AI 调用 Edit 工具修改文件后，聊天界面中同一文件路径会出现两次可点击的链接卡片。 **现象** 1. 工具调用输出自动生成文件路径卡片 2. AI 文本回复中提到同一文件路径时，渲染器再次生成链接卡片 **根因** 渲染层将文本中的路径链接化时，没有检查该路径是否已在当前消息的工具输出中以卡片形式存在。 **预期行为** 渲染层应去重：当前消息中工具调用已涉及的文件路径，文本中不应再被链接化。 **影响** - 同一信息出现两次，降低信息密度 - AI 侧无法根治（只能靠行为纪律避免，但必要时文本中提文件名是合理的上下文） **环境** Alma 0.0.798 macOS (Apple Silicon) 每次调用 Edit 工具后在回复中提及文件名即可复现。

Gong Cheng 14 days ago

💡

Feature Request

问题: 设置中 Activity Recorder 点击后,窗口只有三个操作按钮,窗口是透明的. 电脑配置: macmini m4 15.6.1 (24G90) alma版本: 0.0.813(记不得多久了,好像最近的几个版本都有问题,最开始有这个功能的时候是正常的)

lucacici 15 days ago

💡

Feature Request

Hi, I'd love to suggest a feature that could significantly reduce API costs while maintaining response quality: **intelligent query routing**. **The idea:** Before sending a request to the main LLM, a lightweight local model (e.g., a small classifier or a tiny model like Phi-3-mini / Qwen2.5-0.5B running via Ollama) evaluates the complexity of the user's query and routes it to the appropriate model: - **Simple** → fast, cheap model (e.g., Claude Haiku, GPT-4o-mini) - **Medium** → balanced model (e.g., Claude Sonnet, GPT-4o) - **Complex** → powerful model (e.g., Claude Opus, o1) **Why this matters:** In practice, 60–70% of everyday queries are simple or medium complexity. Routing them to cheaper models could cut API costs by 40–60% with little to no quality loss. There's even an open-source framework for this — [RouteLLM by Berkeley](https://github.com/lm-sys/RouteLLM) — that validates this approach. **Suggested implementation:** 1. A local routing layer that classifies each query before it's sent out 2. Three configurable tiers (Simple / Medium / Complex), each mapped to a user-selected model 3. An optional override — users can manually force a specific model for a request 4. A routing log or indicator showing which model was used and why This would be especially valuable for power users who send a high volume of mixed queries daily. It turns the app into a cost-aware assistant, not just a model wrapper. Would love to hear your thoughts on feasibility. Happy to elaborate or test a prototype if helpful! Thanks for building such a great tool.

Koben Alex 16 days ago

💡

Feature Request

Description Image generation fails when using the openai/gpt-image-2 model with the following error: Image generation failed: Unknown parameter: 'response_format' The error occurs because the image generation code passes a response_format parameter to the OpenAI API that is not supported by the gpt-image-2 model. Steps to Reproduce Set image generation model to openai/gpt-image-2 Send a message that triggers image generation (e.g. "generate an image of ...") Image generation fails with the error above Expected Behavior Image generation should work with gpt-image-2 without passing unsupported parameters. Root Cause The gpt-image-2 model (newer OpenAI image API) does not accept the response_format parameter. This parameter was used by older models like dall-e-3 (values: url or b64_json), but the newer model API schema differs. The image generation implementation likely hardcodes or defaults response_format in the API request body, causing the request to be rejected. Suggested Fix Omit response_format when the selected model is gpt-image-2 (or any model that doesn't support it) Alternatively, detect the model family and only include supported parameters Environment Alma version: v0.0.810 Model: openai/gpt-image-2 Platform: macOS (ARM64)

hh0592821 17 days ago

💡

Feature Request