刚盯到个本机开源 Agent：桌面和终端都能直接干活，研究、写稿、跑脚本都行。
Goose 装上就能执行命令、改文件、跑测试，还能挂 MCP 扩展；模型用你自己的 Key 或订阅。开源 Apache-2.0，本体 $0。
curl -fsSL github.com/aaif-goose/goose/releases/download/sta… | bash
1 like · 8 views
Apache-2.0, 450+ contributors, part of the Agentic AI Foundation at the Linux Foundation.
Helps devs who want one agent for code, research and automation across models.
Honest limit: it runs commands on your machine, so review what it does.
aaif-goose/goose
2 likes · 12 views
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, "<")
.replace(/>/g, ">")
.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! 👋
1 reaction
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.
6 points
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?
2 points · 6 comments
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?
1 point · 1 comment
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?
36 points · 36 comments
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?
23 points · 19 comments
Mentions
刚盯到个本机开源 Agent：桌面和终端都能直接干活，研究、写稿、跑脚本都行。 Goose 装上就能执行命令、改文件、跑测试，还能挂 MCP 扩展；模型用你自己的 Key 或订阅。开源 Apache-2.0，本体 $0。 curl -fsSL github.com/aaif-goose/goose/releases/download/sta… | bash
Apache-2.0, 450+ contributors, part of the Agentic AI Foundation at the Linux Foundation. Helps devs who want one agent for code, research and automation across models. Honest limit: it runs commands on your machine, so review what it does. aaif-goose/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, "<") .replace(/>/g, ">") .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?