Improve observability (feedback from a new user)

[var1ableX]

Please explain the motivation behind the feature request.
I think goose is a great idea, but after a few days of messing around with it I think it's expensive and I think that's not great news for you. Helping me dispel this belief cheaply might be beneficial. Right now I think you're not prioritizing observability, but lets face it. Novices would not be able to use goose right now. It's too early and too fraught with weird problems that a novice wouldn't be able to figure out. So right now your market are power users and developers. I fall into the latter two brackets. What I struggle with is "is this actually working syndrome"? Is there something i could do differently that would make goose viable vs. cursor. But it's quite difficult to figure out whether any of my changes are doing anything. And at this point the only thing keeping me hanging on are my 3 days investment and excitement at a reputable brand creating a LLM provider agnostic solution to building your on PAI (a la Daniel Miessler).

Expensive because of context poisoning - it's hard to cut down input tokens when you can't easily see when and where they're being injected. It's like staring at a wall of logged jsonl OR hard to understand langfuse traces. But net you're watching your budget go down with every experiment. So far I've found the best experience with goose is with Sonnet 4.5, and that's what I'm trying to get away from (cost-wise).

Describe the solution you'd like

• Improve langfuse integration OR create a simple visualization alternative so we can see context switching between models; if I'm going to switch from cursor to goose but am struggling with output. So I'm switching to lead / worker mode OR /plan mode in cli, then I need to know it's working
• Show the active model in the cli e.g.
  ─── llm_search | router ──────────────────────────
  model: lead | worker (model name) <--- here
  extension_name: todo
  query: create a detailed todo list for porting the Python MCP server to TypeScript in a new directory mcp-server-openmeteots
• Please UPDATE the existing documentation to clearly state that you could waste many hours figuring out that you need LANGFUSE_URL NOT LANGFUSE_BASE_URL if you want your traces to show up.
• I think you need slightly better examples of what langfuse can do out of the box vs. what you can add to your code to make its traces better. Right now I don't think the latter is relevant tbh. But the native traces in langfuse from goose are pretty bad -- not worth the time I invested to figure out the LANGFUSE_URL problem. This has to do with something called "limited to SPAN" traces. My compare is LangSmith which I have been using with langgraph for a long time and it's much clearer what the inputs and outputs are.

Describe alternatives you've considered

• Build my own visualization solution on top of the jsonl logs you output for tracing.
• Stop using goose
• And consider my plan b options like Kilo, etc ... I short listed a bunch and ultimately settled on you guys.

Additional context
Add any other context or screenshots about the feature request here.

• I have verified this does not duplicate an existing feature request

[taniacryptid]

Thank you for taking the time to share your feedback! Observability is definitely necessary. The LANGFUSE_URL vs LANGFUSE_BASE_URL in documentation, will be sure to address that.

In terms of model visibility in CLI for lead/worker, in what way would you like to see it?

Going to the main part of your feedback, the context poisoning, are there specific kinds of context that seem unnecessary or redundant? And what specific workflows or tasks are you using goose for where costs are adding up quickly? This is helpful for us to know so we can best understand how to improve the experience.

[var1ableX]

Thank you for taking the time to share your feedback! Observability is definitely necessary. The LANGFUSE_URL vs LANGFUSE_BASE_URL in documentation, will be sure to address that.

In terms of model visibility in CLI for lead/worker, in what way would you like to see it?

Going to the main part of your feedback, the context poisoning, are there specific kinds of context that seem unnecessary or redundant? And what specific workflows or tasks are you using goose for where costs are adding up quickly? This is helpful for us to know so we can best understand how to improve the experience.

At a high level what I saw as costly with root cause of context poisoning was based on langfuse output. E.g. in langfuse I would see multiple calls (my interpretation) and each call would have a lot of json in it. The json is hard to read but glancing at it I got the impression that it is the extension context that is being passed from call to call. And some of that is quite verbose. That said, I appreciate that this context is part of the the magic sauce - it's what makes goose smart. So in my mind if I can find the right combination of models - cheap models - or a pairing (right now I'm testing gemini pro 2.5 (lead) with Grok 4.1 fast code 1 that doesn't really add up even with the context being passed around then I'm fine.

That said it would be good to know whether I can simply leave extension manager on and let goose figure out which extensions to light up using hints / recipes when it needs to be more explicit than that. These are the experiments I'm now running-- but i ran into an issue where Goose just stopped accessing my files ... wiped the whole thing and am starting again.

[var1ableX]

ok after spending another day on this, where I've landed is the fastest way not to lose time is to switch to Claude 4.5 Sonnet. Then things just fly. But I'm still locked in to Claude...

[var1ableX]

Update: Issue appears resolved, root cause still unclear

Resolution = I can now make tool calls consistently with cheaper models.

Question:

• Does the dev team know of potential conditions; maybe a file system, state corruption, missing ???, that would cause Goose to consistently try to use LLM Search query (extension_name, k) tool instead of the specific MCP tool?
• Do they have any recommendations for resetting Goose state to fix issues like this? (I plan to do a lot of work on goose over the coming weeks so any advice would be greatly appreciated).

Background

This issue started in Goose 1.15 and persisted through 1.16.1. Tool calls were not working reliably when MCP servers were involved.

Summary of the Problem (recap)

• When an MCP server was required, Goose would immediately invoke a generic
  LLM Search query (extension_name, k) tool instead of the MCP tool.
• The model would sometimes return messages like:
  • “no tools available, only resources”
• This behavior occurred across multiple models.
• A custom MCP server I built was most visibly affected, but that same server continued to work correctly in Cursor the entire time, suggesting the issue was in Goose rather than the MCP implementation.

---

Current Status

The issue is now resolved, but I cannot clearly identify what change fixed it.

• Tool calls now correctly resolve to MCP tools (e.g.
  Meteo-search Locations query: [location])
• No changes were made to the MCP server
• The server had been stable and working in Cursor throughout

---

Things I Tried While Debugging

I tried many changes during debugging, but reverting these does not reintroduce the issue, which makes it hard to pinpoint the fix.

Things attempted (in no particular order):

1. Deleted all extensions from config.yaml
2. Accidentally set GOOSE_SHIM=1
   • Later removed due to an Ollama port error
3. Switched from auto to smart mode
   • This generated a permission.yaml file
4. Ran goose update (I already had the latest version)

---

Post-Fix Validation

After things started working, I attempted to break it again:

• Deleted all extensions and the permissions file
• Restarted Goose
• Confirmed weather queries no longer worked (expected)
• Re-added the MCP server
• Tool calls worked immediately and correctly
• No generic LLM Search query tool usage observed

---

Observations / Hypothesis

This strongly suggests an internal Goose state, permissions, or tool-registry issue, rather than a problem with the MCP server itself.

It appears Goose can enter a state where MCP tools are not resolved and silently fall back to the generic search tool. Certain actions (mode switch, permissions regeneration, update, or restart path) may force a rebuild of internal tool state and resolve the issue.

[nealmcb]

@taniandjerry Re:

Going to the main part of your feedback, the context poisoning, are there specific kinds of context that seem unnecessary or redundant?

I want to provide a specific example of context poisoning. I asked goose 1.18.0 to solve Advent of AI day 2: (HTML / CSS / JS for choose-your-own-adventure web app with branching story paths, user choices, and beautiful winter styling).
I used auto mode, and it went crazy, spending $10 in Claude Sonnet 4 credits in 38 minutes. The underlying issue was that it didn't figure out how to debug a web app, but along the way it took 5 screenshots, and kept including all of them in the context for each LLM prompt. It was using $0.25 per prompt (78k tokens) by the end. All the while it also was showing a price of $0.00000 (which is misleading but you have to mouse over to see that the tool tip says "Pricing is unavailable for Claude Sonnet"!).
If it is worthwhile I can try to share my debugging zip file and a bunch of investigation of how that happened, that Claude did for me.
But for now I'm glad to have learned at least that Langfuse seems like the right direction since I'm a big fan of observability. Thanks for writing up this issue, @var1ableX !

[var1ableX]

No worries, I genuinely want to see more alternatives out there and keep the competition going. To tie my prior comment back to cost and context — Claude Sonnet 4.5 seemed to “just work” no matter what. Everything else was less consistent. But Somnet brined through $15 in less than an hour in my case.

In general developer extension needs to be on most of the time, so does extension manager. If you’re using cheaper models extension manager hit rate goes down quite a bit. I.e. sometimes it correctly activates the right extension sometimes it doesn’t. But the more extensions you have “always on” the more context and the more cost (or cheaper model confusion). I spent a lot of time wondering what I was doing wrong, experimenting with different extensions, switch todo on and off, wondering whether to use skills or not. Progress was slow. I did have some great moments when it all just worked. Then I’d try again and it wouldn’t.

I believe in providing products honest feedback so I will share that I have since switched to another platform which isn’t too costly at the moment and my productivity skyrocketed. But I had to lock into one model ecosystem.

I am hoping goose continues to evolve and thrive but for now I found it wasn’t consistent enough for non trivial stuff unless I go with Claude Sonnet.