goose

Use your Claude, ChatGPT or Gemini subscription in goose, no API key Most AI agents ask for a pay-per-token API key, even when you already pay for Claude, ChatGPT or Gemini every month. That means two bills for the same models. goose, the open source agent now run under the Linux Foundation's Agentic AI Foundation, has a way around it: its README says you can use your existing Claude, ChatGPT or Gemini subscription through ACP providers instead of API keys. This is the short version of how to set that up, plus what to check before you trust it. What goose is goose is a general-purpose agent that runs on your machine. It ships as a native desktop app (macOS, Linux, Windows), a CLI, and an API. It is written in Rust, works with 15+ providers (Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock and more), and connects to 70+ extensions through the Model Context Protocol. It is not only for code: research, writing, automation and data analysis are all in scope. Step 1: install it Either download the desktop app from the installation page, or install the CLI with the command from the README: curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash As with any piped script, read it first if you are cautious. It is the official release script from the repo, but it is still a remote script running on your machine. Step 2: pick the subscription route Open the ACP providers guide linked from the README (goose-docs.ai, under guides, ACP providers). ACP is the protocol goose uses to talk to a provider that you are already logged into. The idea is that goose drives your existing Claude, ChatGPT or Gemini plan instead of billing API tokens. Connect the provider you pay for, following the guide for that one. The exact flow differs per provider, so I will not guess at flags here. Use the guide as the source of truth, and check the repo for newer instructions, since this part moves fast. Step 3: run a small test task Do not start with a big job. Give goose something short and checkable, for example: > Research three open source tools that do X, and give me a table with name, licence, and last release date. Confirm two things: the task completes, and your provider's usage page shows the usage against your plan rather than a new API charge. If you see an API charge, you are on the wrong provider entry. Step 4: switch providers later Because goose supports many providers, you can swap models without changing how you work. That is the practical win: try Claude for one task, Gemini for the next, or a local Ollama model when you are offline, all from the same interface. Who this suits - You have a consumer or team plan and no appetite for API billing. - You want one agent UI across several model vendors. - You want an open source, inspectable agent rather than a closed app. Caveats - Subscription terms are set by each provider. Check that your plan allows this kind of use before you rely on it. - We wrote our walkthrough from the README, not from a test run, so verify each step against the docs. - Extensions give an agent real access to your machine. Add them one at a time. Where to go next The full card, with the steps and a ready agent prompt, is on Deduped: Use goose with your existing subscription. If you want other agents that work with the tools you already have, browse AI use cases for Claude Code. Source repo: aaif-goose/goose. Want the setup commands for 50 AI repos people actually ship with? Get the free AI Repos That Actually Ship pack: dedupedai.com --- Get one email every Monday with the week's hottest AI repos and exactly how to use them: subscribe free at dedupedai.com

Leafy Goose: A Human-Led AI Assistant for Maintainers’ Community Work How I built a human-led community assistant with Goose Agent and Skill.md Every tech community knows this moment: a newcomer joins, says hi, and asks "What should I do first? Please help!" Welcoming one newcomer is easy. Welcoming new people every single week, with the same questions, is a different story. In a Discord open source community I help with, the same "how do I get started?" questions come back again and again: Do I need to attend every meeting? Where do I share my idea? The answers are already in our guides. But I get it: people want a quick answer in the place where they asked. They don't have time to dig through pages, and they want to feel there is a person on the other side. Most moderators from this community are volunteers, so those answers sometimes wait days. A bot that answers on its own is not the fix either. It is fast, but it loses the human connection, and it can be wrong. So I kept thinking: how can we answer faster, right where people ask, and still keep a human in the loop? My answer this time was a build with goose, a SKILL.md and Discord. I started with a small bot called Goose Bot v1 and ended with Leafy Goose 🍃🪿, an open source bot where AI drafts the answer and a human always decides what gets posted. In this post, I share how I got there, step by step + a link to the public repo at the end to test it yourself with your community Build the workflow once, reuse it anywhere I wanted to build a reusable workflow that other trusted community members could help review and maintain. I also wanted to adapt it to other communities I’m involved with by changing the resources goose reads, without touching the code. That led me to use goose as the AI layer behind the Discord bot. The bot handles the Discord interaction, while goose uses the community’s resources and instructions to draft answers to questions phrased in different ways. Why goose over a direct API call? This is a fair question I got from folks who have been following my work. I could have connected the bot directly to a model API. None of the building blocks below is unique to goose, but goose gives me all of them in one open source tool, ready to use: - Provider changes without code changes: the model provider is configured in goose's settings, so switching providers doesn't require editing the bot. - Reusable instructions: the same SKILL.md can be used outside Discord, making the workflow useful beyond the bot (more on this in step 2). - Tools when needed: extensions add capabilities as the workflow grows. For example, a calendar integration could let the bot check when the next community call is scheduled, something I could add in the future. > Today the bot is built for Discord, so other chat tools would need some extra work. But only one part of the architecture would change: the chat layer. The guide, goose and the answer checks can stay the same. The Architecture Leafy Goose has one rule: AI drafts, a human publishes. A reviewer (a moderator, maintainer or community manager) picks a member's question. The bot asks goose for a draft, using only the community guide. The reviewer reads the private draft and decides. !Leafy Goose architecture Only the prompt goes out to the model provider, and only a reviewer's click puts an answer in a public channel. Before you start You need four things: - Node.js 20 or later - goose CLI signed in to a model provider - A Discord app from the Developer Portal - Manage Server permission on your Discord server, so you can add the bot. Only the person who installs it needs this. Other reviewers don't need it (the person who runs the bot adds their Discord user IDs to the settings) 1. The prototype My first bot was simple. A slash command took the question, sent it to goose, and showed the answer. It worked and taught me fast what can go wrong when a model talks to real people: - Acronyms are ambiguous: the community name is an acronym, and the model at first answered about a popular web framework with the same initials - The model has its own style and that lack of customization was odd in a community channel. - There are old links, meeting times, channels that are private that the model cannot tell which facts are still true unless you give them proper instructions Each of these became one rule in the next version !Image description 2. One guide, one source of truth All the facts live in one Markdown file: the community guide. Changing what the bot says means editing that file, not the code. The guide has a few simple rules: - Public information only. The bot may quote anything in it, so no passwords, private links or personal data. - A Last reviewed: <date> line. Drafts show a warning when the guide is older than 30 days. - Every link in the guide is an approved link, and every <#channel> mention is an approved public channel. The bot builds its allowlists from this file (more on that in step 5). At first it was a plain .md file. Later I turned it into a goose skill, so the same guide could also works beyond the bot if more people want to make use of it (more in the side story below). --- name: drf-community-guide description: Approved facts, links and public Discord channels for the community. Use it to draft answers about getting started, community calls, events, contributing and conduct. --- ... Plain .md vs SKILL.md With a plain .md, an agent does not know the file exists: you have to paste it or ask the agent to read it every time. A skill is found automatically: the agent sees its name and description in every session, and loads the full guide only when a question matches or when you ask for it. So why does the bot not load it as a skill? goose loads a skill only when it decides the question matches the description. For a bot that must always stay on facts, "maybe" is not good enough. The bot reads the file itself, removes the top block, and puts the whole guide in every prompt > 🪿 Side story: a skill beyond the bot. Because the guide is a standard SKILL.md, it is useful outside Discord too. Community managers, moderators, or anyone curious about the community can add it to their favorite AI agent (goose, or any other agent that supports skills). Then they can ask it for help with a welcome post, an answer in GitHub Discussions or a newsletter. Same facts and links, wherever they work. 3. Keeping a human-review in every answer This is the heart of Leafy Goose. Every answer starts as an ephemeral message: only the reviewer who asked can see it. Under the draft there are three buttons: Publish, Edit and Discard. A reviewer can start a draft by right-click a member's message, then Apps, then Answer with Leafy Goose !Image description !Image description Discord wants a first response within 3 seconds, and goose needs longer. So the bot defers the reply first, then asks goose: async function createDraft(interaction, question, target) { // ...allowlist, cooldown and "one request at a time" checks... await interaction.deferReply({ flags: MessageFlags.Ephemeral }); const raw = await guideLib.askGoose(guide, question, { timeoutMs: GOOSE_TIMEOUT_MS }); const result = guideLib.checkAnswer(raw, guide); if (!result.answer) { return interaction.editReply( `🤔 Leafy Goose has no approved answer for this (${result.noAnswerReason}).`); } const id = interaction.id; drafts.set(id, { id, answer: result.answer, warnings: result.warnings, reviewerId: interaction.user.id, interaction, target, timer: setTimeout(() => expireDraft(id), DRAFT_TTL_MS), // 14 minutes }); await interaction.editReply({ content: renderDraft(...), components: draftButtons(id) }); } Drafts expire after 14 minutes, because Discord interaction tokens last 15. This is what a reviewer sees. Only they can read it: !Image description When the reviewer clicks Publish, the bot replies to the member's message when there is one. That way the answer stays next to the question: const channel = await interaction.client.channels.fetch(draft.interaction.channelId); if (draft.target) { const message = await channel.messages.fetch(draft.target.messageId); sent = await message.reply(options); } else { sent = await channel.send(options); } A few small details that matter in a real community: - The draft is deleted from memory before posting, so a double click cannot post twice. - Only the reviewer who made a draft can press its buttons or open its edit form. - allowedMentions blocks @everyone, @here and role pings. Only the member being answered is mentioned. - Link previews are off, so one answer does not fill the channel with cards. - Every published answer ends with a small footer: AI-assisted answer, reviewed by @reviewer. !Image description 4. Running Goose goose is an agent: with extensions it can run shell commands and read files. For a Discord bot I want the opposite. goose should read one prompt and write one answer, nothing more. The bot calls the goose CLI with execFile (no shell) and four flags: const args = [ "run", "--no-session", "--no-profile", "--quiet", "--max-turns", "2", "--text", buildPrompt(guide, question), ]; await execFileAsync(process.env.GOOSE_BIN || "goose", args, { timeout: timeoutMs, env: safeGooseEnv(), }); safeGooseEnv() does two jobs. It sets GOOSE_MODE=chat, so goose does not call tools. And it removes every DISCORD_* variable, so the Discord token never reaches goose: function safeGooseEnv() { const env = { ...process.env, GOOSE_MODE: "chat" }; for (const key of Object.keys(env)) { if (key.startsWith("DISCORD_")) delete env[key]; } return env; } The prompt has two clearly marked parts: the guide, which the bot trusts, and the member's message, which it doesn't. Member text could try a prompt injection to ignore the rules, reveal the prompt or act as something else. No single trick stops that, so the bot uses layers: - It escapes every < and > in the message, so it can't close its marker and pretend to be part of the guide (code below) - The prompt tells goose to treat the message as untrusted and to reply NO_ANSWER: off-topic request to these attempts - A human reviews every draft before anything is posted function cleanQuestion(question) { return question .replace(/</g, "&lt;") .replace(/>/g, "&gt;") .replace(/\s+/g, " ") .trim() .slice(0, MAX_QUESTION_CHARS); } The prompt rules are short and strict: always English, at most 120 words, one clear next step, only links from the guide, never a date for a future meeting. When the guide has no answer, the model replies with one line: NO_ANSWER: <reason>. The bot then tells the reviewer to answer by hand, instead of guessing. > 💡 Watch your error logs: One of the things I did to avoid leaking members' questions was to never log goose's raw error. When goose fails, Node's error repeats the full command, question included. Leafy Goose only reports goose failed (exit code 1). Before a draft reaches the reviewer, the bot also flags links or channels that are not in the guide, meta comments and very long answers. 6. Tests There are two kinds of tests in the repo, and they answer different questions: - Unit tests check the code: is the guide loaded? are bad links flagged? do Discord secrets stay out of the goose environment? They use a fake guide and goose script, so they need no Discord, no goose and no network - Evals check the answers: Each eval is a real question, plus words the answer must or must not contain: { "question": "how can i contribuite to drf", "mustInclude": ["touchpoint"], "mustNotInclude": ["if you mean", "contribuite"] } This one checks two things. The answer points to a community call, and the bot does not comment on the member's typo. Other evals check that the bot never invents a date, never links a private channel, answers in English, and replies NO_ANSWER to off-topic questions and injection attempts. !Image description 7. Set it up for your community Leafy Goose started as a bot for one community, but nothing in the code is specific to it. To use it in another Discord community, you write a new guide, change a few settings and update your own .env One running bot serves all your reviewers: add their Discord user IDs to DISCORD_ALLOWED_USER_ID. The code is at anajsana/leafy-goose Final remarks As a maintainer in open source communities, I know the community load first-hand, and there is still a lot of talk about AI adding to maintainer burnout. However, this time, with Leafy Goose, I wanted to show the other side: the side where AI can take on the repetitive and boring part of community work, while maintainers keep the voice, the judgment and the human connection. I also wanted another community manager to be able to take this, point goose to their own community's guide, and review the answers without having to rebuild the Discord bot. If you try it in your community, I'd love to hear how it goes! 👋

goose: your native open source AI agent for code, workflows, and everything in between (56k stars) What it does All text below is quoted directly from the project README. >goose is a general-purpose AI agent that runs on your machine. goose: - A native desktop app for macOS, Linux, and Windows. - A full CLI for terminal workflows. - An API to embed it anywhere. - Built in Rust for performance and portability. - goose works with 15+ providers: Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock, and more. - Use API keys or your existing Claude, ChatGPT, or Gemini subscriptions via ACP. - Connect to 70+ extensions via the Model Context Protocol open standard. >curl -fsSL github.com/aaif-goose/goose/releases/download/sta… | bash Repository aaif-goose/goose Repository stats |Metric|Value| |:-|:-| |Stars|55,954| |Forks|6.5k| |Last release|v1.57.0 (2026-10-28)| |Languages|Rust 71.7%, TypeScript 23.6%, Python 1.3%| |Contributors|686| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (206 commits), @Copilot (69 commits), @cursoragent (8 commits)| |AI co-authored commits|Claude: 207, Cursor: 8, Copilot: 70| Main contributor |Field|Value| |:-|:-| |Name|Douwe Osinga| |GitHub|@DOsinga| |Commits to this repo|364 (top contributor)| |Bio|Blockerdieblock| |Company / Location|Block / Miami Beach| |Followers|208| ────────────────────────────── 📌 If you want to browse more repos like this, we've organized them by category and rankings here: bestgithubrepositories.com 🗂️ We're also archiving repos where possible, so useful projects don't disappear when they're removed from GitHub.

Goose Alternative: How to Run a Local Agent With Memory on Your Mac or PC in 2026 (Asks First) --- title: "Goose Alternative: How to Run a Local Agent With Memory on Your Mac or PC in 2026 (Asks First)" published: true description: "Off Grid AI adds local memory of your meetings and mail, approved actions and a phone app, Pro $79.99 once. Goose is a free open-source desktop agent." tags: ai, privacy, productivity, opensource canonical_url: getoffgridai.co cover_image: getoffgridai.co --- Goose is a capable open-source agent. It runs as a desktop app, a CLI or an API, and its README lists more than 15 model providers and 70 MCP extensions. Since April 2026 it can also run local models with built-in llama.cpp. Off Grid AI does local models too. What it adds is context and control: a local memory of your meetings, mail and screens, and actions that wait for your yes. It also runs on your phone. Download Off Grid AI · Get Pro for $79.99 once <figure> <img src="getoffgridai.co" alt="Off Grid AI Desktop Pro showing a drafted action waiting for approval." loading="lazy" /> <figcaption>In OGAD Pro, a drafted action waits for your approval.</figcaption> </figure> Off Grid AI and Goose side by side | | Off Grid AI | Goose | |---|---|---| | License and price | AGPL-3.0, free; Pro optional | Apache-2.0, no price listed | | Desktop | Mac (Apple silicon), Windows, Linux | macOS, Linux, Windows | | CLI | Server-only launch for the gateway | Yes, full agent CLI | | Local models | Yes, llama.cpp, kept current in the background | Yes, embedded llama.cpp since April 2026 | | Cloud model providers | Remote servers you add | 15+ providers, including Anthropic, OpenAI and Google | | MCP tools | Yes, stdio and HTTP | Yes, 70+ extensions | | Memory of screens, meetings and mail | Yes, with Pro | Not listed | | Images and voice in and out | Yes, free | Not listed | | iPhone and Android app | Yes, with on-device models | Not listed | Checked 30 October 2026 against Goose's GitHub README, releases, docs site and local inference post. "Not listed" means the feature is not on Goose's own pages. Where Goose is strong Goose ships fast. v1.57.0 came out on 28 October 2026, five days after v1.56.0. The project has more than 55,000 GitHub stars. It is built for builders. Recipes save a workflow as YAML you can share, parameterise and run in CI. Subagents run tasks in parallel. Its docs list a sandbox mode and prompt injection detection. You can also bring an existing Claude, ChatGPT or Gemini subscription. Local models: what the Goose post says Goose's local inference post is honest about limits. The first request takes "30–120 seconds" while the model loads. Most local models handle about 4K to 8K tokens of context. Tool calling works well with Gemma 4. Other models use emulated tool calls, limited to shell commands. Off Grid AI Desktop (OGAD) is built around local models first. The Models screen shows which models fit your memory before you download. Since 0.0.55, its engines (llama.cpp, whisper.cpp and stable-diffusion.cpp) update in the background, so a new model loads without a full app release. What Off Grid adds: context and a yes An agent is only as good as what it knows about you. Goose knows the task you give it. Off Grid Pro knows your workday. - Memory. Your screens, meetings, mail and documents become one local memory. Ask a question and get the answer with its source. See how much Off Grid remembers. - Meetings without a bot. Calls are recorded, transcribed and summarised on your computer. - Actions you approve. It drafts replies and issues through Gmail, Linear, Jira and Notion. Every action waits in a queue. Nothing goes out without your yes. - God, your chief of staff. A morning brief, meeting prep and to-dos people owe you. - Computer Use and Web Use. Pro works through visible apps or its built-in browser while you watch. See how to automate repetitive Mac tasks. Free features Goose does not list The free OGAD app also makes images on your GPU, listens with Whisper and talks back with Kokoro. Projects answer from your files with citations. For your scripts, OGAD serves an OpenAI-compatible API at http://127.0.0.1:7878/v1 for chat, vision, images, speech and embeddings. Any tool that takes an OpenAI base URL can use it. See the local API guide. On your phone too Off Grid AI Mobile (OGAM) runs on-device models on iPhone and Android. It can also reach the bigger model on your computer over your home network or VPN. With Pro, Sync keeps chats and Projects in step, device to device. When Goose is the better pick Pick Goose if you live in the terminal, want recipes in CI, or want to switch between many cloud providers in one agent. Pick it if you need an Apache-2.0 license to build on. Pick Off Grid if you want an assistant that already knows your meetings and mail, acts only after your yes, and runs on your phone. What Pro costs On 30 October 2026, Pro costs $79.99 once, a limited-time price down from $119, or $7.99 a month. One key covers up to 5 devices. The free app, images, voice, Projects and the local API never need Pro. Start in ten minutes 1. Download OGAD for Mac (Apple silicon), Windows or Linux. 2. Pick a text model. The app shows which models fit your memory. 3. Get Pro and enter your key. 4. Connect Gmail or Linear, and approve your first drafted action. No account at any step. FAQ What is Goose? Goose is an open-source AI agent under Apache-2.0, part of the Agentic AI Foundation at the Linux Foundation. It runs as a desktop app on macOS, Linux and Windows, as a CLI, or through an API, and connects to more than 70 MCP extensions. Can Goose run local models? Yes. Since April 2026, Goose embeds llama.cpp in its desktop app. Its blog notes the first request can take 30 to 120 seconds to load a model, and most local models handle about 4K to 8K tokens of context. What does Off Grid AI do that Goose does not? Off Grid AI Pro keeps one local memory of your screens, meetings, mail and documents, records meetings without a bot, and drafts work in Gmail, Linear, Jira and Notion that waits for your yes. It also has iPhone and Android apps with on-device models. Is Goose free? Goose is open source and its pages list no price. Cloud model providers you connect bill you separately. Off Grid AI Desktop is also free; Pro costs $79.99 once on 30 October 2026, a limited-time price. Does Off Grid AI work with MCP tools? Yes. Off Grid AI Desktop runs MCP connectors over stdio or HTTP on your computer. With Pro, each proposed action waits in an approval queue before anything happens. Get Off Grid AI Pro and give your agent a memory of your work, with your yes on every action.

Which coding agent should you run on a local 27B? I lined up 10 on a 64 GB MacBook and counted tokens The hardware I used: MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4 on llama.cpp If you're picking an agent for a local model, here's one data point. Same model, same server, same 5 small coding tasks for all ten. Results |#|Agent|Passed|Median time|Median tokens|Cache reuse|Tried to go online| |:-|:-|:-|:-|:-|:-|:-| |1|Pi|5/5|38 s|9.2k|72%|no| |2|DeepSeek Harness|5/5|60 s|35.3k|83%|no| |3|Codex CLI|5/5|94 s|36.3k|79%|every run| |4|OpenClaw|5/5|106 s|39.0k|72%|unclear| |5|Cline|5/5|152 s|29.6k|79%|every run| |6|OpenCode|4/5|50 s|32.4k|75%|every run| |7|Hermes|4/5|80 s|64.9k|93%|no| |8|Atomic Agent|5/5|56 s|30.4k|86%|no| |9|goose|4/5|98 s|20.3k|76%|every run| |10|Qwen Code|4/5|183 s|107.9k|74%|unclear| Heads up: one run per task, so it's noisy. Going over 5 min counts as a fail. What I'd take from it - They all work on a 27B. Every agent passed at least 4 of 5 tasks. - Tokens are the real difference. Pi used about 9k tokens per task, Qwen Code about 108k, on the same model. On a local box that's a lot of extra waiting. - Watch the defaults. Cline and Qwen Code have usage stats on by default, DeepSeek Harness uploads session logs (per their docs). I turned it all off. - Some still try to go online. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it. Memory, since people ask With one agent and 64K context, llama-server sat at about 33 GB on the 64 GB Mac. The Q4 model itself is about 17.5 GB, the rest is KV cache and llama.cpp's prompt cache. On a 32 GB machine I'd cut context to 32K, use q8 KV cache and set --cache-ram 0, or pick a smaller model. A few setup gotchas - Codex needs llama-server's /v1/responses now - Hermes needs at least 64K context - Atomic Agent was the only one talking to llama.cpp's native endpoint with a grammar for tool calls. The other nine used the OpenAI-style API The log task got two agents. They grepped "ERROR" and got 244 instead of 64, because some normal lines just mention errors. OpenCode and goose fell for it. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it, so I don't know what they were calling. OpenClaw and Qwen Code are "unclear" because they run as plain nodes and I couldn't tell them apart. Which column matters most to you when you pick an agent for a local model: passing, speed, tokens, or staying offline?

Which coding agent gets the most out of a local Qwen 3.8 27B? I lined up 10 and logged tokens, cache and sandbox blocks Yet another agent test. Last time it was a 4B model, and you asked for the hardware, token counts and more agents. I used a MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4 on llama.cpp. Results |#|Agent|Passed|Median time|Median tokens|Cache reuse|Tried to go online| |:-|:-|:-|:-|:-|:-|:-| |1|Pi|5/5|38 s|9.2k|72%|no| |2|DeepSeek Harness|5/5|60 s|35.3k|83%|no| |3|Codex CLI|5/5|94 s|36.3k|79%|every run| |4|OpenClaw|5/5|106 s|39.0k|72%|unclear| |5|Cline|5/5|152 s|29.6k|79%|every run| |6|OpenCode|4/5|50 s|32.4k|75%|every run| |7|Hermes|4/5|80 s|64.9k|93%|no| |8|Atomic Agent|5/5|56 s|30.4k|86%|no| |9|goose|4/5|98 s|20.3k|76%|every run| |10|Qwen Code|4/5|183 s|107.9k|74%|unclear| How it ran - same model and server for everyone - 5 small coding tasks, each with a little trap - each agent locked in a sandbox: it can only touch its own folder and only talk to the model - auto-approve on, telemetry off, 5 min limit What I noticed Pi is crazy lean: about 9k tokens per task, the lowest on every single task. Qwen Code was the hungriest at about 108k per task. The log task got three agents. They grepped "ERROR" and got 244 instead of 64, because some normal lines just mention errors. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it, so I don't know what they were calling. OpenClaw and Qwen Code are "unclear" because they run as plain node and I couldn't tell them apart. Atomic Agent is the odd one out in how it works. It was the only one talking to llama.cpp's native endpoint with a grammar that forces the tool calls into shape. The other nine all went through the OpenAI-style API. It's also built to keep its prompt the same from step to step, which is why it reused 86% of the cache (2rd of 10). It stayed offline the whole time and passed 5/5. DeepSeek Harness was the surprise. It’s still an alpha, but it went 5/5, never tried to go online, and had the best cache reuse after Atomic Agent. Setup notes - Cline and Qwen Code have usage stats on by default, DeepSeek Harness uploads session logs (per their docs). I turned it all off - Codex needs llama-server's /v1/responses now - Hermes needs at least 64K context - no Copilot CLI or Crush since I kept it open source. Strata isn't an agent, it's an inference engine What’s the one number in this table that would make you switch agents for your local models?

10 coding agents, one Qwen 3.8 27B, same llama-server: tokens and cache reuse differ more than pass rates Part 2 of my agent test (part 1 was a 4B model) Hardware I used: MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4 on llama.cpp, thinking off. Setup - same model and server for everyone - 5 small coding tasks, each with a little trap - each agent locked in a sandbox: it can only touch its own folder and only talk to the model - auto-approve on, telemetry off, 5 min limit Results |#|Agent|Passed|Median time|Median tokens|Cache reuse|Tried to go online| |:-|:-|:-|:-|:-|:-|:-| |1|Pi|5/5|38 s|9.2k|72%|no| |2|DeepSeek Harness|5/5|60 s|35.3k|83%|no| |3|Codex CLI|5/5|94 s|36.3k|79%|every run| |4|OpenClaw|5/5|106 s|39.0k|72%|unclear| |5|Cline|5/5|152 s|29.6k|79%|every run| |6|OpenCode|4/5|50 s|32.4k|75%|every run| |7|Hermes|4/5|80 s|64.9k|93%|no| |8|Atomic Agent|5/5|56 s|30.4k|86%|no| |9|goose|4/5|98 s|20.3k|76%|every run| |10|Qwen Code|4/5|183 s|107.9k|74%|unclear| Tokens and cache Pi is crazy lean: about 9k tokens per task, the lowest on every single task. Qwen Code was the hungriest at about 108k per task. Atomic Agent is the odd one out in how it works. It was the only one talking to llama.cpp's native endpoint with a grammar that forces the tool calls into shape. The other nine all went through the OpenAI-style API. It's also built to keep its prompt the same from step to step, which is why it reused 86% of the cache (2rd of 10). It stayed offline the whole time and passed 5/5. DeepSeek Harness was the surprise. It’s still an alpha, but it went 5/5, never tried to go online, and had the best cache reuse after Atomic Agent (83%). The trap and the network The log task got three agents. They grepped "ERROR" and got 244 instead of 64, because some normal lines just mention errors. OpenCode, goose and Atomic Agent fell for it. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it, so I don't know what they were calling. OpenClaw and Qwen Code are "unclear" because they run as plain node and I couldn't tell them apart. llama.cpp notes - Codex needs llama-server's /v1/responses now - Hermes needs at least 64K context - Cline and Qwen Code have usage stats on by default, DeepSeek Harness uploads session logs (per their docs). I turned it all off Which column matters most to you when you pick an agent for a local model like Qwen 3.8 27B: passing, speed, tokens, or staying offline?

How well do coding agents drive Qwen 3.8 27B locally? I lined up 10 of them on one hardware My hardware: MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4 on llama.cpp, thinking off. I put Qwen 3.8 27B behind one llama.cpp server and gave 10 coding agents the same 5 tasks. |#|Agent|Passed|Median time|Median tokens|Cache reuse|Tried to go online| |:-|:-|:-|:-|:-|:-|:-| |1|Pi|5/5|38 s|9.2k|72%|no| |2|DeepSeek Harness|5/5|60 s|35.3k|83%|no| |3|Codex CLI|5/5|94 s|36.3k|79%|every run| |4|OpenClaw|5/5|106 s|39.0k|72%|unclear| |5|Cline|5/5|152 s|29.6k|79%|every run| |6|OpenCode|4/5|50 s|32.4k|75%|every run| |7|Hermes|4/5|80 s|64.9k|93%|no| |8|Atomic Agent|5/5|56 s|30.4k|86%|no| |9|goose|4/5|98 s|20.3k|76%|every run| |10|Qwen Code|4/5|183 s|107.9k|74%|unclear| Pi is crazy lean: about 9k tokens per task, the lowest on every single task. Qwen Code was the hungriest at about 108k per task. The setup - same model and server for everyone - 5 small coding tasks, each with a little trap - each agent locked in a sandbox: it can only touch its own folder and only talk to the model - auto-approve on, telemetry off, 5 min limit What I noticed The log task got three agents. They grepped "ERROR" and got 244 instead of 64, because some normal lines just mention errors. OpenCode, goose and Atomic Agent fell for it. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it, so I don't know what they were calling. OpenClaw and Qwen Code are "unclear" because they run as plain node and I couldn't tell them apart. Atomic Agent is the odd one out in how it works. It was the only one talking to llama.cpp's native endpoint with a grammar that forces the tool calls into shape. The other nine all went through the OpenAI-style API. It's also built to keep its prompt the same from step to step, which is why it reused 86% of the cache (3rd of 10). It stayed offline the whole time and passed 5/5. Setup notes - Cline and Qwen Code have usage stats on by default, DeepSeek Harness uploads session logs (per their docs). I turned it all off - Codex needs llama-server's /v1/responses now - Hermes needs at least 64K context Would you pick an agent for fewer tokens or for passing every task?

Stop Switching Tabs: Uplevel The SRE Chat Window with Amazon OpenSearch Service MCP Apps Your investigation agent finds the root cause in seconds. Then you open four browser tabs to check whether it is right. MCP Apps bring the evidence into the chat. Your investigation agent can hand you a root-cause hypothesis about as fast as you can read the page. A hypothesis is not yet a fix, and before you act on one in the middle of an incident you need to see the evidence for yourself. That usually means opening the observability UI in a browser, finding the trace waterfall, pulling up the service map to scope the impact, and checking each view against what the agent said, ping-ponging between tabs while the pressure builds. The agent saved you the query time and left you the tab-switching. Amazon OpenSearch Service MCP Apps move that verification into the chat thread, so the evidence arrives next to the claim. This post builds on Implement Agent Observability: Extend Your OpenTelemetry Stack on Amazon OpenSearch Service, which covers how agent telemetry joins the OpenTelemetry stack you already run. The proof arrives with the answer A standard MCP tool call returns text. The agent reasons over it, and you go somewhere else to check it. MCP Apps extend the protocol with a second response channel. If a standard tool call is stdout only, an MCP App writes to two streams: a structured text summary for the agent, and an interactive visualization that your chat client renders in the conversation thread for you. A trace investigation shows how the two halves divide the work. The agent passes a trace ID, or a service name and time range, and the tool returns a summary with the trace ID, total duration, span count, critical path, and where the failure started. The agent uses that text to choose its next step, such as pulling the log entries around the failing span. Meanwhile the same response renders a trace waterfall in the thread, and you can expand spans, inspect their attributes, and confirm the root cause yourself. OpenSearch UI builds that visualization server-side by running the query against your data, so the chart is deterministic. You are looking at the actual query result, not the model's description of it. !Image description An MCP App renders a checkout trace waterfall in the chat thread, with the span hierarchy, span details, the AI analysis, and suggested next questions in one view. The chat client, Goose in this case, renders both the text and interactive graphic response. When checkout errors spike, the whole investigation can start from one question about the cause. The agent queries the alerts, correlates logs with traces, and checks the service map, and its reply carries those views alongside its explanation. The waterfall above comes from exactly that kind of session. The analysis points at CartService/EmptyCart failing with a FailedPrecondition error after about 15 seconds, and the span hierarchy beneath it lets you trace the failure from the load generator through checkout to the cart service yourself. The suggested follow-ups at the bottom, such as showing the logs for this trace or checking cart service health, keep the next step in the same thread, whether that is digging deeper, drafting the incident summary, or starting the remediation. Setting up the local server The architecture is a local MCP server that sits between your chat client and an OpenSearch UI application. OpenSearch UI is the serverless interface for observability, and it already connects to your OpenSearch Service domains, OpenSearch Serverless collections, and Amazon Managed Service for Prometheus workspaces. Each tool call goes from your client to the local server, which signs the request with your AWS credentials and forwards it to the OpenSearch UI endpoint. The server runs on your machine, and your data stays in your AWS account. You need an OpenSearch UI application with an Observability workspace connected to at least one data source, Node.js 22 or later, and credentials that allow es:ESHttpGet and es:ESHttpPost on the application. Supported clients include Claude Desktop, VS Code with GitHub Copilot, Cursor, Goose, and ChatGPT. Download and extract the server package, then add it to your client's MCP configuration: { "mcpServers": { "opensearch-observability-stack-mcp": { "command": "node", "args": ["/path/to/opensearch-observability-stack-mcp/server/server.js"], "env": { "OS_UI_ENDPOINT": "application-abc123.us-west-2.opensearch.amazonaws.com", "AWS_REGION": "us-west-2", "AWS_PROFILE": "my-profile" } } } } The endpoint is the Application URL on the Applications page of the Amazon OpenSearch Service console. Restart the client and ask it to list the available observability data sources. If your domains, collections, or Prometheus workspaces come back, the connection works. The setup creates no cloud resources, so removing it means deleting the configuration entry and the local directory. The launch post walks through each step. The chat window becomes the console The previous post made the case for bringing application and agent telemetry together, with logs and traces in OpenSearch Service and metrics in Amazon Managed Service for Prometheus. MCP Apps are where that unification pays off for the person on call. The signals still live in several stores, but the SRE no longer has to remember which store holds which signal or which UI shows it. The agent does that routing, and the chat thread becomes one surface over every source. In that sense the agent is the new user experience for observability: you describe what you need, and the right query against the right store comes back with the right view. Behind that surface, each tool handles a different stage of an investigation and returns the view that suits it. Triage tools surface active alerts, correlate them across data sources, and break them down by severity so the agent knows where to start. Log tools search for error patterns and cluster similar entries into a failure signature. Trace tools find the distributed trace and draw the span hierarchy and latency breakdown. To size the impact, metric tools run PromQL with threshold analysis, service performance tools report rate, errors, and duration for each service, and topology tools draw the service map with call volume and error rate on every edge. Dynamic visualization tools build line, bar, area, and metric charts from queries you describe, and a set of specialized tools covers the agents themselves, tracing LLM calls and rendering agent trace maps, alongside cluster health reports and instrumentation scoring that finds gaps in your telemetry coverage. With those tools behind it, the console stops being a wall of dashboards you navigate and becomes a conversation you drive. You ask what is wrong, and the waterfall that shows it arrives with the answer. You ask how far it spreads, and the service map renders with the failing edges marked. You ask for the error rate since the last deploy, and the chart is built for that window when you ask, rather than waiting on a dashboard someone had to anticipate. Trust in that conversation depends on what sits underneath it. The agent works through your permissions, and every result reports its own status. An empty result means the query finished and found nothing, which is different from a timeout, a partial scan, or a permission denial, and that status carries through each step of the investigation. The same thread can also carry the response. A runbook for a known failure can live as a skill the agent runs, so the procedure and the data it depends on show up together instead of in a wiki tab. This approach suits teams that run observability at scale and want to own the stack: large telemetry volumes, engineers who build their own tooling, and a preference for open, extensible components. If you already run OpenSearch for logs or search, the MCP server works against the same engine and the same data you already query. Bringing it together Agents made root-cause analysis fast, which left verification as the slow step. Amazon OpenSearch Service MCP Apps close that gap by returning each answer twice: as text the agent reasons over, and as a deterministic visualization you can inspect in the same thread. Setup takes a local server, your existing OpenSearch UI application, and your AWS credentials, and the tools cover an investigation from the first alert to the service map. For SREs working alongside agents that investigate at machine speed, the chat window is no longer a lighter view of the observability console. It is the console.

Use DeepSeek V4.1 Flash and Kimi K2.7 Code in goose with a custom provider file --- title: "Use DeepSeek V4.1 Flash and Kimi K2.7 Code in goose with a custom provider file" published: true description: "One JSON file in goose's custom_providers folder, one environment variable, and goose can talk to DeepSeek, Kimi, GLM and MiniMax models on CloudGPU's OpenAI-compatible endpoint." tags: goose, ai, deepseek, tutorial cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com --- Short answer: copy the JSON below into ~/.config/goose/custom_providers/cloudgpu.json, run export CGW_API_KEY="cgw-sk-your-key", then start goose with --provider cloudgpu --model deepseek-v4.1-flash. Disclosure: I work on CloudGPU, and the endpoint in this post is ours. We haven't tested goose against this endpoint ourselves; the steps follow goose's docs (Configure Custom Provider). Treat the checks below as things you run, not results we measured. Note: Tool calling through this endpoint isn't tested by us. goose leans on tool calls for real work, so run the self-checks in Step 5 before you hand it a task that matters. Why a file and not a built-in provider goose's CONTRIBUTING.md asks services with an OpenAI-compatible API to publish a goose custom-provider JSON file with their own documentation, so users can drop it into their local custom_providers directory without waiting for a goose release. This post is that documentation for CloudGPU. What you need - goose (CLI or Desktop), installed from its own docs. - A CloudGPU API key. Go to API Console and create a key. Copy the cgw-sk-... value — it's shown once. The quick start is on the API docs page. Step 1: Get the JSON Copy this into a file named cloudgpu.json: { "name": "cloudgpu", "engine": "openai", "display_name": "CloudGPU", "description": "DeepSeek, Kimi, GLM and MiniMax models through CloudGPU's OpenAI-compatible API.", "api_key_env": "CGW_API_KEY", "base_url": "https://cloudgpu.app/v1", "dynamic_models": false, "models": [ { "name": "deepseek-v4.1-flash" }, { "name": "deepseek-v4-pro" }, { "name": "kimi-k2.7-code" }, { "name": "glm-5.3-flash" }, { "name": "minimax-m3" } ], "supports_streaming": true, "requires_auth": true, "model_doc_link": "https://cloudgpu.app/api/docs", "setup_steps": [ "Sign in at https://cloudgpu.app, then go to API Console: https://cloudgpu.app/api/console", "Create a key. Copy the cgw-sk-... value — it's shown once.", "Top up your balance via Billing. Model IDs are listed on https://cloudgpu.app/api", "Set the CGW_API_KEY environment variable to your key before starting goose" ] } What the fields do, in goose's terms: - name is the provider ID you pass to --provider. - engine: "openai" tells goose to speak the OpenAI-compatible chat format. - base_url is the CloudGPU endpoint. goose adds chat/completions after the /v1. - api_key_env is the name of the environment variable goose reads the key from. There is no key in the file, and there never should be. - models is the list goose shows. With dynamic_models: false, goose uses only these five IDs and doesn't fetch a model list from the endpoint. - No context_limit is set. It's optional in goose's format, and we don't publish context sizes for these models, so goose uses its own defaults. Step 2: Put it where goose looks goose's docs give one folder per OS: - macOS/Linux: ~/.config/goose/custom_providers/ - Windows: %APPDATA%\Block\goose\config\custom_providers\ On macOS or Linux: mkdir -p ~/.config/goose/custom_providers cp cloudgpu.json ~/.config/goose/custom_providers/cloudgpu.json Self-check: goose info prints the configuration file location. custom_providers sits in that same config folder. If CloudGPU doesn't show up in the provider list, restart goose. Step 3: Set the key export CGW_API_KEY="cgw-sk-your-key" Use your own key in place of cgw-sk-your-key, and run goose from that same shell. Two things from goose's config docs worth knowing: - goose does not read provider API keys from config.yaml. A key there is ignored. - If you'd rather keep the key in goose's keychain, open the provider in goose Desktop and enter the key there. - If goose Desktop changes the variable name, use the one shown in the provider's settings (Settings, then the Models tab, then Configure providers, then click CloudGPU in the list). Self-check, outside goose: this is the request from our API docs. If it fails, fix it before going further. curl https://cloudgpu.app/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $CGW_API_KEY" \ -d '{"model":"deepseek-v4.1-flash","messages":[{"role":"user","content":"Say hi in one sentence."}]}' Step 4: Pick a model These are the model IDs in the file. Each one is in the model table on our API page: | Model ID | Model | |---|---| | deepseek-v4.1-flash | DeepSeek V4.1 Flash | | deepseek-v4-pro | DeepSeek V4 Pro | | kimi-k2.7-code | Kimi K2.7 Code | | glm-5.3-flash | GLM 5.3 Flash | | minimax-m3 | MiniMax M3 | IDs are case-sensitive and the dots matter. A wrong ID comes back as 400 model_not_found. - goose CLI: pass the provider and model per run, as in goose's CLI docs: goose run --provider cloudgpu --model kimi-k2.7-code -t "...". goose also reads GOOSE_PROVIDER and GOOSE_MODEL from the environment. - goose Desktop: goose's docs say custom providers appear in the provider list like any other provider. Open Settings, then the Models tab, then Switch models, choose CloudGPU, and pick a model (or Use custom model to type an ID). Confirm with Select model. Step 5: Quick test Start with a plain prompt and no session file: goose run --no-session --provider cloudgpu --model deepseek-v4.1-flash \ -t "Reply with one short sentence that names the model you are." Self-checks (what to look for, not what we saw): - You get a reply from the model, not an error. If you see 401 missing_authorization or 401 invalid_api_key, the key isn't reaching goose. Check that CGW_API_KEY is set in the shell that runs goose. - 400 model_not_found: compare the --model value with the table above, character for character. - cloudgpu isn't recognised as a provider: check the file is at the path from Step 2 and that it parses (python3 -m json.tool ~/.config/goose/custom_providers/cloudgpu.json). Then try a first coding task in a scratch folder, with goose's developer extension turned on: mkdir -p ~/goose-cloudgpu-test && cd ~/goose-cloudgpu-test goose run --no-session --provider cloudgpu --model kimi-k2.7-code --with-builtin developer \ -t "Create hello.py that prints the numbers 1 to 5, then show me the file." This one needs tool calls, which we haven't tested through our endpoint. Self-check: hello.py exists in the folder and contains what you asked for. If goose answers in text but no file appears, the model's tool calls didn't make it through. Try another model ID from the table and tell us which one failed. Where to go next - goose's own reference for this file format: Configure Custom Provider. - goose CLI flags (run, --provider, --model): goose CLI commands. If something in these steps doesn't match what your goose shows, leave a comment with your goose version and the error text (never the key), and we'll update the post.