{"slug": "debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost", "title": "Debugging AI Coding Agents: How to See Prompts, Tool Calls, Token Usage, and Cost", "summary": "A developer built ccglass, an open-source local proxy and dashboard that lets engineers inspect the full request flow of AI coding agents, including system prompts, tool call schemas, tool results, per-request token usage, and cost. The tool addresses the difficulty of debugging agentic coding tools by revealing what is actually sent to the model, helping identify issues like context bloat, malformed tool calls, and provider errors.", "body_md": "When a coding agent fails, the visible error is rarely the whole story.\n\nYou might see:\n\n`400 Bad Request`\n\nThe usual reaction is to tweak the prompt and try again.\n\nSometimes that works. But for agentic coding tools, guessing is not enough. You need to inspect what the agent actually sent to the model.\n\nThat is the problem **ccglass** is built for.\n\nGitHub: [https://github.com/jianshuo/ccglass](https://github.com/jianshuo/ccglass)\n\nModern coding agents are not simple chatbots.\n\nTools like Claude Code, Codex, OpenCode, CodeBuddy, Qoder, and similar systems usually run a loop like this:\n\n``` php\nuser request\n  -> model request\n  -> tool call\n  -> local command / file read / edit / search\n  -> tool result\n  -> next model request\n  -> final answer\n```\n\nWhen something goes wrong, the bug can be in any part of that loop.\n\nFor example:\n\nYou cannot debug that reliably from the final answer alone.\n\nWhen an agent behaves strangely, I usually want to see five things.\n\nThe system prompt often explains behavior that looks mysterious from the outside.\n\nIt may contain rules about:\n\nIf the agent ignores your instruction, first check whether the system prompt is pushing it in a different direction.\n\nTool calling depends heavily on the schema sent to the model.\n\nIf a tool is described vaguely, has confusing parameter names, or contains a schema shape the provider does not like, the model may choose the wrong tool or produce invalid arguments.\n\nThis matters even more with MCP servers and custom tools.\n\nThe question is not \"what did my code define?\" The real question is:\n\nWhat tool schema was actually sent in the model request?\n\nA tool call bug can come from the model, the client, or the provider adapter.\n\nYou want to inspect:\n\nFor example, if the model emits something that looks like a tool call but the client renders it as text, the agent may continue as if the tool ran even though no tool result exists.\n\nTool results are often the hidden source of context bloat.\n\nA single file read, search result, stack trace, or command output can add thousands of tokens to the next turn.\n\nIf the agent suddenly becomes expensive or confused, check what tool results were fed back into the model.\n\nToken totals are useful, but per-request token usage is better.\n\nYou want to know:\n\nThat is the difference between \"this session was expensive\" and \"this specific tool result caused the spike.\"\n\nccglass is a local proxy and dashboard for coding-agent traffic.\n\nIt lets you inspect what supported agents actually send to the model:\n\nIt works locally. It is open source.\n\nInstall:\n\n```\nnpm install -g ccglass\n```\n\nStart it:\n\n```\nccglass\n```\n\nOr choose a client directly:\n\n```\nccglass claude\nccglass codex\nccglass opencode\nccglass qoder\nccglass codebuddy\n```\n\nFor generic OpenAI-compatible or Anthropic-compatible clients, you can also run proxy-only mode:\n\n```\nccglass proxy --provider openai\nccglass proxy --provider claude\n```\n\nThen point your client or IDE at the printed local base URL.\n\nSuppose an agent repeatedly fails to call a tool correctly.\n\nInstead of changing the prompt first, inspect the actual request flow:\n\nThat gives you a factual answer to questions like:\n\nAnother common problem:\n\nWhy did this one coding-agent session use so many tokens?\n\nIn ccglass, inspect the request list and session summary.\n\nLook for:\n\nThen use turn-to-turn diff to see what changed between two requests.\n\nThis is often more useful than looking only at the final cost.\n\nProvider errors are another good use case.\n\nIf an Anthropic-compatible or OpenAI-compatible endpoint rejects a request, you need the exact payload.\n\nCheck:\n\nThis is useful when working with:\n\nThe failure is often not \"the model is bad.\" It is often a request-shape problem.\n\nccglass can export captured requests:\n\n```\nccglass export <session>/<seq> --format raw\nccglass export <session>/<seq> --format md\nccglass export <session>/<seq> --format json\nccglass export <session>/<seq> --format har\n```\n\nThat is useful when reporting bugs to an agent project, provider, or proxy maintainer.\n\nInstead of saying:\n\nThe agent failed.\n\nYou can show:\n\nThis exact request contained this tool schema, this model response emitted this malformed tool call, and this provider returned this error.\n\nThat is much easier to debug.\n\nccglass is not a universal network sniffer.\n\nIt works best when the client can be pointed at a local base URL or local proxy. For example, API-key based OpenAI-compatible and Anthropic-compatible traffic is a good fit.\n\nSome clients have special transports. For example, Codex authenticated through ChatGPT login may use a WebSocket path that does not honor `OPENAI_BASE_URL`\n\n, so local base URL inspection will not see that traffic.\n\nFor CodeBuddy, ccglass uses a forward-proxy mode because CodeBuddy hardcodes its upstream endpoint.\n\nAs coding agents become more autonomous, debugging needs to move one layer deeper.\n\nIt is no longer enough to ask:\n\nDid the agent produce the right diff?\n\nYou also need to ask:\n\nWhat did the agent see, what tool did it choose, what result came back, and what context entered the next turn?\n\nThat is what ccglass tries to make visible.\n\nGitHub:\n\n[https://github.com/jianshuo/ccglass](https://github.com/jianshuo/ccglass)\n\nInstall:\n\n```\nnpm install -g ccglass\n```\n\nIf you build with coding agents, request-level debugging is worth having in your toolbox.", "url": "https://wpnews.pro/news/debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost", "canonical_source": "https://dev.to/houleixx/debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost-4omm", "published_at": "2026-06-21 02:33:55+00:00", "updated_at": "2026-06-21 03:06:48.912373+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "large-language-models", "ai-infrastructure"], "entities": ["ccglass", "Claude Code", "Codex", "OpenCode", "CodeBuddy", "Qoder", "Anthropic", "OpenAI"], "alternates": {"html": "https://wpnews.pro/news/debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost", "markdown": "https://wpnews.pro/news/debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost.md", "text": "https://wpnews.pro/news/debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost.txt", "jsonld": "https://wpnews.pro/news/debugging-ai-coding-agents-how-to-see-prompts-tool-calls-token-usage-and-cost.jsonld"}}