Codpilot Fusion is a piece of shit. Wasted 80% of my tokens for no usable output.

[NeoSparkTechnology]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Models

Body

For context, I'm a full-stack developer currently working on a DevOps team as a Site Reliability Engineer (SRE), with 15 years of professional experience and 3 years of intensive AI-assisted development. During my working weeks, I typically generate 10,000–15,000 lines of code. I also build and orchestrate agentic workflows using gated execution, optimized context-window management, cached journals, plans, and other persistent artifacts to minimize context consumption, prevent drift, and avoid common agentic failure modes. I commit after every turn and use Fork to review diffs before approving progression to the next gate.

I've been trying to recreate a similar agentic workflow that I developed at work, since I'm unable to export that environment. Unfortunately, the experience has been extremely frustrating. K3 started out promising but eventually became increasingly token-hungry. I switched to Copilot Fusion in VS Code, only to encounter further token waste, excessive compaction, and context drift. Ultimately, the workflow became unusable. No this is not a result of context window mismanagement.

What makes this particularly disappointing is that I've seen what's possible when agentic workflows are structured correctly. At work, we host Kimi K2.6 internally at Alarm.com, where it costs us nothing per use. With the right gated structure, I've seen it outperform Claude in our workflow. That workflow takes work from Jira through planning, phased and gated implementation, coordinated agentic development, PR review, and iterative remediation when changes are rejected. Agents work within clearly defined boundaries, and nothing advances without approval.

I wanted to recreate that same engineering discipline in my personal development environment. Instead, I've spent four hours and nearly exhausted my token budget with nothing functional to show for it.

I've watched agents spin their wheels, waste turns, repeatedly consume context, make assumptions, and implement changes they were never authorized to make. Compaction compounds the problem, context drifts, and the original objectives and constraints gradually disappear.

Honestly, I'm angry and deeply disappointed. Burning through approximately 80% of my available tokens, which won't renew until November 30, on an unusable result is incredibly frustrating.

At this point, it genuinely feels as though the system prompt and agent orchestration are working against the user rather than helping them. I shouldn't have to spend more time correcting an agent's unauthorized assumptions, recovering from context drift, and managing unnecessary token consumption than actually engineering the solution.

Four hours of engineering effort and nearly an entire token allocation, with nothing usable to show for it, is not a good developer experience.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[markusswedpal]

100% agree. The main selling point of Fusion is that it selects the right model for the task, but in practice it feels like it is consistently over-selecting expensive models.

As a web developer working mostly on frontend tasks, Fusion drained my credits in two days because it selected Claude Fable 5. Sol and Luna had handled these same tasks perfectly well before, so I don’t see why Fusion needs to route routine frontend work to a much more expensive model.

I initially assumed the high usage was caused by Fusion running multiple subagents in parallel, but based on GitHub’s documentation, Fusion works separately from subagents and does not start them. The more likely explanation is that Fusion can use additional model calls for review/orchestration, especially at higher effort levels, and each model used is billed at its standard rate. That may explain the credit consumption, but it still does not feel like “the right model for the task” when a cheaper model would have been sufficient.

Previously, Auto mode worked fine for this kind of work. Right now, Fusion mainly feels like a way to increase usage-based billing rather than a meaningful improvement in model selection.

What would help:

• Make the selected model and execution pattern visible before or during each request.
• Provide clearer per-request usage breakdowns: which model ran, how many tokens/credits it consumed, and whether review passes were used.
• Add stronger cost-aware routing for routine tasks such as frontend UI changes, styling, refactoring, and small bug fixes.
• Let users set a spending cap or prefer lower-cost models by default.
• Ensure Fusion Standard genuinely behaves like a single-model request for simple tasks, rather than escalating to expensive models unnecessarily.

Without better transparency and cost controls, it is hard to justify using Fusion for everyday development work.