Token usage of nested skills - am I missing something?

[Twiglet1022]

I noticed that in the last update the /grill-with-docs skill has been replaced with this:

Run a /grilling session, using the /domain-modeling skill.

Am I wrong in thinking that this kind of pattern is just going to increase API costs with cloud models like Claude? The original version of this skill included everything it needed in one place, so your agent would just make one call to read the skill before continuing, costing you just one lot of input tokens as it appends the contents of the skill to the context window.

Now the agent has to take two extra steps to read /grilling, send your full context window back to the API costing you more input tokens, think briefly before calling /domain-modeling, send your full context window back to the API a second time, and only then continue.

I know that cached input tokens are cheaper than fresh input tokens, but is this not now much less efficient?

I mainly use Claude Code and I'm not 100% sure how it works under the hood, but I know that it can use sub-agents with fresh context windows for some things, so maybe it's just using sub-agents to read the skills and append them to the main thread's context which wouldn't be as bad.

But yea, I'm not sure that this new idea of nesting skills is really optimal. I think I'm going to revert mine back to one monolithic skill.

[Amar07Singh]

Hey @Twiglet1022 — how's your experience scaling Claude Code with skills?

Are you hitting those weird context walls where it starts losing track of files, or is it staying snappy?

[blmille1]

@Twiglet1022 I hear you that this has gotten a bit more complex as it has to make tool calls to fetch the instructions. Also, you will have to make sure to install the skills it references and if you only had this one skill installed and updated that one skill, now it's referencing a non-existent skill on your machine and might even hallucinate what it think the skill would do.

If you consider Matt's position where he's curating a list of skills that he uses every day, that he also has to balance duplication. These skills are getting tightly integrated into his overall workflow and there are interconnects in various places.

Agents get confused with duplication. Duplication requires maintenance to be accurate long-term or there's drift.

For those of us who install just the grill-me skill, now we have to either stop using grill-me and use /grilling or we have to install both.

But for him, it makes sense to keep them separate because he has all of them installed to support his overall workflow.

Now, I'm nobody special here, but you could just copy the skills you like, create your own skills repo, and check back from time to time to see if you should mutate your own.

Or, you have an option to install the skill at the specific version where it was unified.

[richardchen874-sys]

"Token usage of nested skills - am I missing something?" is the kind of thread where I would make raw usage and normalized cost visible before trying to optimize model choice.

I would keep provider, model, request type, prompt/output tokens, cached-token behavior, latency, retry count, and final billing bucket together in one event. That makes cost debugging and future routing decisions much easier.

I am testing a multi-model OpenAI-compatible API layer around official Chinese models, so the routing and usage-accounting parts of this are directly relevant to me. For skills, would the first win be user-facing cost transparency, internal spend debugging, or routing cheaper calls to cheaper models?