AI coding agents are getting better at writing code, calling tools, editing files, and coordinating multi-step tasks. But when something goes wrong, the most useful evidence is often not visible in the chat window.

The agent may call the wrong tool. It may send too much context. It may behave differently across providers. A streaming response may look fine in the UI but fail in the client. A tool schema may be slightly different from what you expected.

In those cases, reading the final answer is not enough. You need to inspect the request and response layer.

## The debugging gap

When working with OpenAI-compatible APIs or coding-agent tools, I often want to answer questions like:

- What exact prompt was sent to the model?
- Which tool schemas were included in the request?
- Did the model actually return a tool call?
- What did the tool result look like?
- How many tokens did this turn use?
- How much latency came from the model response?
- Did two providers receive the same request?

Most application logs are not designed for this level of inspection. Provider dashboards can help, but they are often separated from the local development workflow. Custom proxy logging works, but it quickly becomes another small internal tool to maintain.

That is why I found ccglass interesting.

## What ccglass does

ccglass is an open-source local dashboard for inspecting AI coding-agent traffic. It is designed for developers who want to see what their agent or OpenAI-compatible client actually sends to the model.

It can help inspect:

- request bodies
- prompts and message history
- tool schemas
- tool calls and tool results
- response bodies
- streamed chunks
- token usage
- cost
- latency
- differences between requests

The useful part is that it focuses on the traffic itself. Instead of only asking “why did the agent answer this way?”, you can look at the actual payload and ask a more precise question: “what did the model receive, and what did it return?”

## Where it fits

ccglass is not a replacement for an IDE, an agent framework, or an observability platform. It is closer to a local inspection layer for AI development.

That makes it useful in scenarios such as:

- debugging tool calling behavior
- comparing requests across different model providers
- checking whether a client is serializing messages correctly
- understanding token usage across agent turns
- investigating slow or expensive requests
- reproducing issues from coding-agent workflows

It can be especially helpful when working with tools and setups such as Claude Code, Codex, Qoder, Ollama, LM Studio, OpenRouter, and other OpenAI-compatible clients.

## A practical example

Suppose an agent fails to use a tool correctly.

Without request-level visibility, you may only see the final failure: the agent did not call the tool, or it called it with the wrong arguments.

With a local inspection dashboard, you can check:

1. Whether the tool schema was included in the request.
2. Whether the schema matched what the client expected.
3. Whether the model returned a tool call.
4. Whether the client parsed the tool call correctly.
5. Whether the tool result was sent back to the model.

This changes the debugging process from guessing to inspection.

## Why this matters

As coding agents become more capable, their behavior becomes harder to debug from the UI alone. The interesting problems are no longer only about prompts. They are also about context size, tool schemas, streaming formats, provider compatibility, latency, and cost.

For developers building or using AI coding workflows, request-level visibility is becoming a basic debugging requirement.

ccglass is one open-source tool that addresses this need in a lightweight way.

GitHub:
https://github.com/jianshuo/ccglass

Product Hunt:
https://www.producthunt.com/products/ccglass-2