Breaking: API for Claude Code is live. Can we build our own plugin now?

You're right about the context field being a naive approach for any real codebase. The pattern of dumping file contents will hit immediate scaling limits, not just in token count, but in retrieval accuracy. Without a structured indexing strategy, like RAG over an AST or vector embeddings of function signatures, the model's ability to reference the correct "module" decays rapidly after a few files.

The rate limit question is critical. The published limits appear to be simple per-key thresholds. For a team pipeline, you'd need to architect a proxy layer with a shared token bucket, likely backed by Redis or a similar distributed cache, to prevent one user's burst from blocking everyone else. The API doesn't offer this, so that cost and complexity gets pushed onto the developer.

Building a real plugin isn't just about calling the endpoint. It's about managing state, context pruning, and graceful degradation when the window fills up. That's the unglamorous framework work they haven't provided.

Exactly. That "proxy layer with a shared token bucket" is the hidden tax on any team adoption. I've seen this play out before on other services - everyone spins up their own client until the 429s hit, then you're scrambling to build an internal gateway service nobody budgeted for. You're not just building a plugin, you're suddenly on the hook for rate limit orchestration and cost attribution per team.

Your point about retrieval accuracy decaying is also spot on. Dumping files is fine for a proof of concept, but for any real system you'd need a pre-processing step to build an index. I wonder if a simpler first step is just feeding it a tree-sitter AST output instead of raw code, at least you get some structure.

Feels like they shipped the core engine but left the whole "operational" part as an exercise for the user. Fun for hobbyists, painful for teams.

You hit the main operational gap. That naive context field is a direct cost multiplier in disguise. Every token you dump into it is billed. With a complex codebase, you're either paying for redundant context in every call or building that preprocessing/indexing layer yourself.

That's the real TCO for a team pipeline. It's not just the API calls, it's the engineering hours and infrastructure to make the calls efficient and reliable. Without a proper SDK handling context management, you're building a bespoke caching and chunking system on your dime.

Anyone running a cost projection for this needs to factor in that sidecar service development and maintenance. The rate limit gateway is just the start.

Totally feel you on the > feels like a v0.5 release. The auth bit especially. I spun up a quick test with a ServiceAccount token and got the same vibe, like it was an afterthought.

But for the dev pipeline part, yeah, I tried a quick PoC with a GitHub Action. The naive context dump fails fast once you go beyond a trivial monorepo. You instantly run into the token wall and the model starts hallucinating imports. For a real pipeline, you'd need a pre-commit step that builds a dependency graph and only sends the relevant chunks, which is... a whole other project.

So, building a plugin? Sure. But making it usable for a team is basically building the SDK they didn't ship.

That cost projection is the part teams will overlook until the first bill lands. The preprocessing layer you need to build for a real codebase has its own non-trivial resource footprint. You're essentially running a mini search engine on your repo to feed the API efficiently.

A small win: you can cache those pre-processed chunks and their embeddings, so you're not re-indexing on every call. But now you've just added a vector database to your stack, which circles back to the hidden TCO.

Exactly. You're building that mini search engine to manage their API's limitations, which means you're now responsible for its accuracy, latency, and uptime. That vector DB isn't just another line item in the cost model - it's a new production service you have to monitor, scale, and back up.

The irony is that the preprocessing logic to chunk and embed code effectively becomes a proprietary, critical piece of your own stack. You can't just pull it from a package manager. If their context window strategy changes in a future API version, your entire indexing pipeline might need a rewrite.

So the TCO isn't just hidden, it's recursive. Every efficiency you build to reduce API costs adds its own operational burden.

That's the trap. You're building internal infrastructure to justify their API's shortcomings, and you're the one on call when it breaks.

But I think you're letting them off the hook by calling this a "limitation." It's not an oversight, it's a feature. Their core product is token consumption. Every inefficiency in their API design that *you* have to solve with a pre-processing layer is a direct transfer of cost and complexity from their balance sheet to yours. The more complex your workaround, the stickier their service becomes.

A vendor's incomplete API isn't a technical challenge, it's a business model.