1. This is not a true Python SDK. It's merely a thin wrapper that spawns the Claude Code npm package as a subprocess and communicates through stdin/stdout. All the core logic—agent loops, tool execution, and prompt handling—exists in the npm package, not in Python.
2. There is no native tool interface. Users are forced to build custom MCP servers and wire them up manually in their Python code. Sure, MCP servers work as a way to group tools together, but having no other option doesn't seem ideal.
3. There is no proper health check implementation. In modern container orchestration environments such as EKS, health checks are critical for maintaining stable services. However, this SDK provides no meaningful health check capabilities. The `is_ready()` method simply checks a boolean flag, which doesn't verify whether the subprocess is actually responsive. When `await client.connect()` spawns the Claude Code npm package as a subprocess, there's no mechanism to ensure the agent daemon remains healthy over time—it could be hanging, deadlocked, or in a zombie state without detection.
4. There is a resource consumption issue as well. Actually this is from claude code cli because claude agent sdk is just a wrapper. You can check the capture at "https://github.com/jujumilk3/jujumilk3/issues/1". And if I run claude agent sdk with bypassPermission, it requires a non-root account, so I couldn't debug when this happened. Because the docker image was built with a non-root account. Memory spikes are from requests, so it appears this resource consumption is not related to the actual operations.
I wrote about my experiences over the last few weeks with claude agent sdk. If I used it in the wrong way, please let me know. Also please share your experiences when you're using this framework.