DEV Community: Bargan Constantin

The scarce resource is not tokens, it is my attention — why I built ccdeck

Bargan Constantin — Thu, 01 Oct 2026 19:01:28 +0000

I build ccdeck, a local dashboard for Claude Code and Codex sessions. This is the story behind it.

Four agents running, and the machine has been quiet for twenty minutes.

One of the four had stopped to ask me something — a permission prompt for a shell command — and I had not seen it go by. From the outside every terminal tab looked the same: the one that was working and the one that had been holding a prompt since I went for coffee. I found it by clicking through the tabs, and of course it was the agent that had been closest to finished.

The agent was not slow. I was. And nothing in my setup could tell me that. That situation is the one ccdeck was built for.

A tree, drawn as a scroll

The second problem is wider. An agent session is a tree: a main agent, subagents it spawns, tool calls under each of them. A terminal shows that tree as a scroll. Five subagents working in parallel arrive as one interleaved column of text.

The questions I actually had were:

what is running right now?
what did that subagent do?
which one is stuck?
what is this costing?

Those are exactly the questions a scroll answers worst. So the first version of ccdeck did one thing: it drew the tree.

Day one

The first commit is dated 12 June 2026: a live graph of Claude Code agents, fed by Claude Code's own hooks. Versions 0.1 to 0.6 are all commits from that same day — richer nodes, a detail view for tool calls, persistence, token usage.

By the end of September the repository had a little over 3,000 commits and about 390 tagged releases. It grew Codex support, cost and quota, several Claude accounts, a desktop app, a machine panel. But the thing I use most is still the narrowest one.

The wait is the metric

Tokens matter, and ccdeck shows them. But tokens were never what I ran out of. I ran out of attention. The expensive part of that afternoon was not the API bill; it was twenty minutes of an agent waiting for me while I did not know.

So the sharpest job of the deck became one sentence: say which agent is blocked on a human, and for how long. Every session stopped on a permission prompt, a question or a finished turn goes to the top of the list, longest wait first, and the count in the topbar jumps to the oldest one. The question stops being which terminal tab and becomes this one.

Everything else on the canvas is context for that sentence.

What I decided it must never do

There are four rules I keep for it.

1. Measure, do not steer. A hook that runs on every tool call could, in principle, allow, deny or rewrite that call. ccdeck's hook cannot: it posts the event to the deck on 127.0.0.1, prints nothing and always exits 0, and a test checks both the source and the running script for exactly that. A dashboard you install on every tool call should not be able to become a participant. The README's sentence for it is the one I hold myself to: it never steers an agent or edits your code, but it is not read-only either — it manages two tools it relies on and refreshes the Codex token it reads quota with, and says so.

2. Name the blindness. When the deck cannot know something, it says so instead of guessing quietly. Codex records no approval request in its log, so a Codex session is never shown as waiting — and the docs say that, rather than leaving the queue to look complete. The tool name next to a wait is an inference, so it is labelled as one.

3. It must work from a cold npx. No config file, no account, nothing to read first. npx ccdeck and a page opens. The npm package has no runtime dependencies at all; anything the deck fetches for itself, it fetches after it is already up.

4. Local first, and honest about what is not. Your sessions, prompts, files, project names and paths never leave the machine. What does go out is listed in the README: a version check, the tools it installs, quota reads signed with your own credentials, status pages — and usage reports about the deck itself (version, system, IP address, a device fingerprint, errors), on by default, with one switch to turn them off. I would rather you read that list than a slogan.

Things I got wrong

A few, because they taught me more than the things that worked.

The hook was slower than its own timeout. The hook declared a 2-second timeout to Claude Code, and its internal deadline started when its main() ran. Measured against a stalled deck, the whole process took 1.84 s idle and up to 2.19 s on a loaded machine — the shell fork, Node's startup and reading a large payload all happened outside the budget. Now the cap counts from process start, the declared timeout is a 3-second backstop, and a test pins the two numbers against each other.

A second deck nobody asked for. Typing ccdeck beside a deck that was already running used to start a second one: port 4317 was busy, so the new deck took a random port, and neither mentioned the other. Now a plain ccdeck opens the running deck's tab — after the deck on that port proves it is yours with the same token handshake the hook uses.

Temperatures that do not exist. I wanted a temperature row on every machine. On a Windows 11 laptop with an Intel i5-9300H, the firmware declares no thermal zones at all, and the one source that has the sensors refuses anyone but an administrator. There is no standard user-mode API for CPU temperature on Windows. So the deck shows a Thermal section only where the machine actually answers, and no row at all where it does not.

What it is not

ccdeck is an instrument panel and a flight recorder, not an orchestrator. It does not schedule agents, assign work or supervise anything. One canvas, no tabs, no kanban is a constraint I keep on purpose: the moment a feature wants a tab bar, it is asking for the canvas.

It cannot answer a prompt for you either. You still switch to the terminal. It tells you which one.

Where it is now

npx ccdeck

Or the desktop app for macOS, Windows and Linux, with the waiting count in the menu bar. Claude Code and Codex CLI on one canvas, local, AGPL-3.0, and every guide on ccdeck.dev says which version it was checked against.

If you run more than one agent at a time, I would like to know what you lose track of. Issues and discussions are open:

Repo: https://github.com/BarganConstantin/ccdeck
Discussions: https://github.com/BarganConstantin/ccdeck/discussions
Site: https://ccdeck.dev

From 15 Minutes to 30 Seconds: Cutting Build Time in a Large .NET Project

Bargan Constantin — Mon, 06 Oct 2025 11:09:49 +0000

Tired of waiting forever for your .NET builds? Our project had 400+ EF Core migrations and builds took 15 minutes — until we tried these two fixes.

When you start a new .NET project, everything feels smooth — builds are fast, migrations are few, and iteration is quick. But as projects evolve into long-term, business-critical systems, reality starts to look very different.

In one of the projects I’m working on, we’ve accumulated more than 400 EF Core migrations over several years of development. On paper, this doesn’t sound too bad — migrations are just C# files, right? But in practice, the build process became painfully slow:

Even with solid hardware, a full build took 10–15 minutes.
Small surface-level changes still needed 3–4 minutes to build.
Changes in the application or domain layer (where entities live) triggered full rebuilds.

At that point, the development process looked like this: you could realistically build and test 3–4 times per hour. And as every .NET developer knows, waiting on builds is one of the fastest ways to lose focus and momentum.

So I started digging into ways to optimize this. What I discovered turned out to be surprisingly simple at first — and then led me to a more sustainable long-term solution.

In this article, I’ll share:

A quick win you can apply in minutes to cut build time drastically.
A more elegant solution with a dedicated migrations project.
Some thoughts on the bigger picture (modular monoliths, legacy realities, microservices).

The Problem

EF Core migrations are useful and necessary — they keep your database schema in sync with your evolving domain. But in very large projects, they can also become a hidden bottleneck.

Here’s what we found when analyzing why our builds had become painfully slow:

Every migration is just C# code: EF migrations are stored as generated .cs files. When you have a handful, it’s fine — but with hundreds of migrations, every build must recompile all of them.
Deep changes trigger everything: Modifying code in the domain layer means the compiler re-checks all dependencies — migrations included. Even a small change can cause a full rebuild.
Builds become painfully long: With 400+ migrations, a clean build can take 10–15 minutes, even on powerful hardware.
Developer experience suffers: Productivity drops fast. Developers start avoiding builds “just to save time,” which delays feedback loops and slows the whole team down.

Of course, in theory, you wouldn’t end up here. Bounded contexts, modular monoliths, or even microservices could have prevented such a massive DbContext. But in real life, many long-term projects grow this way — often under business pressure where refactoring isn’t a priority.

So instead of a rewrite, we needed practical fixes that worked immediately.

First Solution: Exclude Migrations from Build

The first discovery was almost embarrassingly simple.

If you’re not actively working on migrations, you don’t need them compiled every time. In .NET, you can exclude files or folders from the build inside your .csproj:

<ItemGroup>
  <Compile Remove="Migrations\**\*.cs" />
</ItemGroup>

That’s it. Just one line.

The Results

As soon as we added this, build times dropped dramatically:

From 10–15 minutes → to 30–60 seconds.
Incremental builds felt instant again.
Developer flow was restored.

The first build after excluding migrations felt almost magical. Of course, the trade-off is obvious: if you need to create or apply migrations, you’ll have to temporarily remove the exclusion. But migrations are usually touched less frequently, so this trade-off is worth it.

The Bigger Picture

This is where the architecture conversation comes in.

Yes, ideally, you wouldn’t have hundreds of migrations in a single DbContext. Modern approaches like modular monoliths encourage splitting the system into modules — each with its own DbContext and migrations. That way, you get strong boundaries without the full complexity of microservices.

In hindsight, adopting a modular monolith could have kept our migrations more manageable over time. But for a legacy project, it’s not always realistic to refactor the entire architecture just to speed up builds.

That’s why small steps like excluding migrations or moving them into a separate project can be game-changers. They don’t erase architectural debt, but they give developers back their time.

In our case, we went from:

3–4 builds per hour → to as many as needed without frustration.
Developers stopped avoiding builds “just to save time.”
The feedback loop became fast again, which improved both focus and morale.

Conclusion

Long build times silently kill productivity. In our case, EF Core migrations were the culprit — and the fixes were surprisingly simple.

Exclude migrations from build when you don’t need them.
Move migrations into their own project for a sustainable long-term solution.
Keep modular monoliths or bounded contexts in mind to prevent this issue in the future.

These changes helped us cut build times from 15 minutes to under 1 minute — and restored developer flow in a project that had grown massive over the years.

💬 What about you?

Have you faced similar issues with EF Core migrations in large projects?

Did you solve them with modular monoliths, microservices, or something else entirely?

I’d love to hear your experience in the comments 👇

✍️ Author Note

Appreciate you reading this! I’m a software developer and computer science engineer exploring .NET, architecture, and productivity. I might be wrong sometimes — and that’s why I’d love to hear your feedback or alternative approaches in the comments.