Instructions on how to connect an agent using an API key (not via a subscription).
The problem
Opus 5 can't figure it out.
Roadmap progress
SHIPPED · 1.72.1PENDING
REVIEWING
PLANNED
—
IN PROGRESS
—
COMPLETED
- — Liamleadgen submitted this request
- — Khoa Nguyen moved it to Reviewing
- — Khoa Nguyen moved it to Completed
- — Khoa Nguyen moved it to Reviewing “reopen”
Discussion6
- Khoa NguyenSign in to reply
Yes - 1DevTool mounts MCP into Oh My Pi, but it does not force oversized inline tool schemas or inject a hidden “go work” prompt. The burn is Yolo + GLM-5.3 treating “ready to work?” as a job start.
You can send this:
Thanks for the detail. Your read is partly right.
Short version: 1DevTool does register its MCP server into Oh My Pi, and the default launch is auto-approve. It does not rewrite OMP’s tools.xdevDocs, pass a --mcp-config flag, or inject a hidden startup prompt. With GLM-5.3, a “ready to work?” ping in that setup is enough to start calling tools.
1. Does 1DevTool set tools.xdevDocs: inline, pass MCP config, or inject hidden prompts?
What What 1DevTool actually does
tools.xdevDocs Never written. 1DevTool does not touch OMP settings. OMP’s own default stays builtins.
MCP config Yes. On app start it upserts an onedevtool entry in ~/.omp/agent/mcp.json. That server exposes database, HTTP, Tasks, orchestration-draft, and in-app browser tools.
Spawn flags Default built-in launch is omp --auto-approve (Yolo). That pins tools.approvalMode: yolo for the session. Manual mode launches bare omp.
Hidden prompt No. 1DevTool does not type a secret first message. It only starts the CLI.
Skills Yes, if ~/.omp/agent exists. It installs 1devtool-tasks and 1devtool-orchestrator into ~/.omp/agent/skills/. The Tasks skill is meant to activate on “what should I be working on” / fresh dispatched sessions — “ready to work?” is uncomfortably close.
--mcp-config Not used. OMP reads its own mcp.json.
OMP also imports MCP from other tools (Claude, Cursor, Codex, Gemini, OpenCode, VS Code, Windsurf). The huge “mounted xdev/MCP tools” list at startup is often 1DevTool’s onedevtool server plus whatever those other clients already had. In OMP, /mcp list shows which file each server came from.Seeing that list in the TUI is not the same as inlining every schema on every request. With tools.xdev on (OMP default), MCP tools mount as xd:// devices; xdevDocs: builtins keeps MCP/extension schemas on demand. 1DevTool does not flip that to inline.
What does spend tokens:
Yolo. --auto-approve / OMP’s own default tools.approvalMode: yolo lets GLM-5.3 run tools with no confirmation.
A prompt that sounds like a job start. “Are you ready to work?” is not a ping for GLM-5.3. It treats it as “begin.”
A large catalog of available tools, even if schemas are on-demand. The model can still read xd://… and then fire dozens of calls.
Possibly the Tasks skill, if it activates on that phrasing.
Settings → Extensions toggles (browser / database / HTTP) do not shrink the tool list. They gate execution on our side; OMP still sees the schemas.2. Supported way to keep 1DevTool browser/MCP tools on demand, not in every request?
There is no 1DevTool setting that maps to tools.xdevDocs. That is OMP-owned.Keep 1DevTool MCP, but cheap and on-demand:
omp config set tools.xdevDocs catalog
catalog lists devices by name and fetches docs only when used. builtins (default) already keeps MCP schemas off the hot path; catalog is stricter.Confirm with:
omp config get tools.xdevDocs
omp config get tools.xdev
tools.xdev should stay true. If it is false, every enabled tool goes top-level.Keep MCP registered, but don’t auto-run it:
omp --approval-mode always-ask
Or in OMP config, set per-tool prompt/deny for mcp__onedevtool_*.Hide 1DevTool MCP from OMP only (Claude/Codex keep it):
In ~/.omp/agent/mcp.json:
json
Copy
{
"disabledServers": ["onedevtool"]
}
Then /mcp reload. That denylist wins even if 1DevTool re-writes the onedevtool entry on next app launch. There is currently no per-client “off for OMP” switch in Settings → MCP; that row is marked managed.Trim inherited servers (usual source of “dozens of tools”):
In OMP run /mcp list, then /mcp disable for anything you did not mean to bring over from Claude/Cursor/etc.
3. Recommended OMP startup for normal interactive use
In 1DevToolSettings → Terminal → Commands → set Agent permission to Manual. Built-in OMP then starts as omp, not omp --auto-approve.
Or a custom startup command:--approval-mode always-ask --auto-approve is for unattended/headless launches. It is the wrong default for “just chat.” ``` In OMP (once)config set tools.approvalMode always-ask omp config set tools.xdev true omp config set tools.xdevDocs catalog omp config set todo.eager defaultLeave todo.eager at default. always invents a todo list and starts working.How to ping it
Don’t send “ready to work?”, “are you ready?”, or “start”. Those read as dispatch.
Use:
Reply with one short sentence that you are idle and waiting. Do not use tools, do not read files, do not search the repo.
If it still tools, the model/Yolo path is the problem, not a hidden 1DevTool prompt.
OpenRouter GLM-5.3 as a coding agent is tool-eager. Combined with Yolo + a large MCP catalog, one vague prompt can become many round-trips.
Why this looks like the Qwen incident
Same class of failure: 1DevTool’s default for Qwen is --approval-mode=yolo, Qwen is also tool-happy, and a single “do the task” prompt can run until the quota is gone. 1DevTool is not silently submitting extra prompts; it is launching the CLI in full-permission mode with MCP available. For interactive chat, Manual / always-ask is the guardrail.If useful, send:
The exact startup command on that terminal
Output of OMP /mcp list
omp config get tools.xdevDocs and tools.approvalMode
Whether ~/.omp/agent/skills/1devtool-tasks exists
That tells us whether the extra tools were 1DevTool’s onedevtool server, inherited Claude/Cursor servers, or both. Session IDs and screenshots help confirm the first calls were read xd://… / tasks_next / workspace glob, vs a hidden injected prompt (we would not expect the latter). - LiamleadgenSign in to reply
Thanks, when I added an agent that way it just went wild with a simple "are you ready to work prompt" consumed thousands of tokens and made dozens of tools calls. We did some research and is it possible OMP in 1DevTool appears to send an oversized MCP/tool context and starts autonomous work??
I am running Oh My Pi 18.1.21 in 1DevTool with OpenRouter GLM-5.3. On startup, OMP shows a very large raw list of mounted xdev/MCP tools, including 1DevTool browser tools. A simple “ready to work?” in an existing project then triggered multiple model calls and tool actions, causing unexpectedly high OpenRouter usage.
OMP documents
tools.xdevDocs: builtinsas the default, which should keep MCP and extension tool schemas on demand rather than inline on every request. Can you confirm whether 1DevTool injects, mounts, or forces OMP tool schemas or prompt settings differently when it detects OMP as an AI agent?Specifically, please advise:
1. Does 1DevTool settools.xdevDocs: inline, pass an MCP configuration, or inject hidden startup prompts?
2. Is there a supported 1DevTool setting to keep its browser/MCP tools available on demand but out of every OMP model request?
3. Can you provide the recommended OMP startup command/configuration for normal interactive use, where “ready to work?” produces a brief response and does not begin workspace exploration?I can provide session IDs and screenshots if useful.
Thanks for your help. It does seem similar to the problem I encountered when trying to use Qwen about a month ago, all the 5 hour credits got used on 1 task.
- Khoa NguyenSTOICSOFT TEAMSign in to reply
yes, you can, you can add custom agent here in the Settings
- LiamleadgenSign in to reply
Thanks but I dont want to use Claude though.
I want to use different models on OpenRouter.
And I was wanting to create an Agent that I can select for work. like shown in the attachment.Is this possible?
Sign in to comment, vote and follow this request.
Sign in to reply