You're deep into a feature. Claude Code is handling changes across three services. You're watching it work, and it looks good — until you realize session A renamed a field in auth-service two hours ago, and session B has been building order-service against the old shape ever since.
Nothing failed loudly. It just drifted.
This is the problem I kept hitting when using Claude Code on a multi-service project. Inside a single repo, it's genuinely impressive. But the moment a change needs to flow through interconnected services — API contracts, shared models, downstream consumers — the coordination falls apart. Not because Claude Code is bad, but because it was never designed for this. Each session has its own context. They don't talk to each other. There's no shared awareness of what changed where.
The result: field names diverge quietly, contracts go stale, and downstream services code against schemas that no longer exist. You don't find out until something breaks in staging.
The coordination gap
The core issue is session isolation. When you run Claude Code across multiple services, each session only knows what's in its own context window. If service A changes its API response shape, service B has no idea. If you're renaming a field that exists in six places across four services, you have to manually track what changed where, in what order, and whether anything was missed.
This doesn't scale. The more interconnected your services, the worse it gets.
What's missing is a layer that sits above all the services, maintains awareness of the full dependency graph, and coordinates changes in the right order — upstream first, then downstream.
What I built
Cascade is a Claude Code plugin that adds exactly that layer. One orchestrator session sees all your services, understands their dependencies, and coordinates changes across them.
It uses five specialized agents:
- Planner — analyzes impact before touching any code. Which services are affected? In what order?
- Worker — implements changes one service at a time, following TDD when tests exist
- Contracts — updates API contracts immediately after each service, not at the end
- Verifier — checks for stale references and contract mismatches across all services when the work is done
- Orchestrator — coordinates everything in dependency order
The key design decision was keeping this as a single session rather than multiple parallel sessions. One session means consistent naming across all services. Dependency order is enforced naturally. When the verifier runs, it has full context of every change that happened.
Services that don't depend on each other run in parallel. Services that do run in strict dependency order.
Why contracts-after-each-service matters
One thing I learned building this: if you sync API contracts at the end of a multi-service change, you will catch drift too late. By the time the verifier runs, downstream services have already been implemented against stale contracts.
Cascade syncs contracts immediately after each service change, before the worker moves to the next service. The downstream service always has an accurate contract to code against. This alone eliminated most of the cross-service inconsistencies I was seeing.
Install and try it
/plugin marketplace add alibrahim/cascade
/plugin install cascade@cascade
Then in your multi-service project root:
/cascade-init
This scans your project, detects services and their dependencies, and generates a cascade.yaml. After that, any cross-service change request automatically activates the orchestrator.
It's stack-agnostic. Python, TypeScript, Go, mixed stacks — anything with HTTP APIs and text-based source files works.
It's also complementary to Superpowers and gstack. Those handle how to write good code within a single repo. Cascade handles how to coordinate across repos.
Open source, MIT: github.com/alibrahim/cascade
What I'd love feedback on
If you're running Claude Code across microservices or a multi-repo setup, I'd genuinely like to hear what breaks for you. The coordination gap I described is what Cascade targets, but there are probably failure modes I haven't hit yet.
Try it, break it, and let me know what you find.
Top comments (0)