Live data from Hacker News

Show HN: Badge that shows how well your codebase fits in an LLM's context window

github.com

21–30 of 47 posts

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#21
post #17
post #15

It's a fun, in the "style of the time" thing to track, but within a year or two, context window limitations won't be a thing. Doubt me? Think back 2 years. Now compare today. Change is at massive speed, and this issue is top line to be resolved in some fashion.

I’m not so sure an increasingly large context window will be seen as a critical enabler (as it was viewed 6 months ago), after watching how amazingly effective subagents and tool calls are at tackling parts of the problem and surfacing the just the relevant bits for the task at hand. And if increasing the context window isn’t the current bottleneck, effort will be put elsewhere.

I agree. My suspicion is that token efficiency is what will drive more efficient tool calls, and tool building. And we want that. Agents should rely less on raw intelligence (ability to hold everyting in context), and more on building tools to get the job done.

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#22

[flagged]

It’s interesting but I think it’s measuring the wrong thing. Abstraction is a fundamental principle in software. As a human, I’ve worked with classes and modules far larger than what fits in my head, just because I’m only fitting the function signatures and purpose into my head, and not the implementation details. In practice I find Claude really good at extracting useful information in a human-like way from a codebase. It doesn’t usually stuff the entire codebase into its context window.

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#23
I haven't cared too much about repo tokens in a good while.

But my coolest app was a better context creator. I found it hard to extend to actual agentic coding use. Agentic discovery is generally useful and reliable - the overhead of tokens can be managed by the harness (i.e. Claude Code).

https://prompttower.com/

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#25
post #22

[flagged]

It’s interesting but I think it’s measuring the wrong thing. Abstraction is a fundamental principle in software. As a human, I’ve worked with classes and modules far larger than what fits in my head, just because I’m only fitting the function signatures and purpose into my head, and not the implementation details. In practice I find Claude really good at extracting useful information in a human-like way from a codeba…

Also this rewards dynamic languages over typed languages, penalizes comments, descriptive function names, etc. Though frankly, it'd be interesting to see whether AI would work better with a project in Javascript that barely fits in context, or the same thing in typescript that overflows. I could imagine either, but my guess is "it depends". Though, "depends on what" would be interesting to know.

Still, this seems useful for being able to see at a glance. I have no idea where most of my own projects would land.

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#26
Maybe it’s useful to dig out the concept of modularization with a distinction between interface and implementation again, and construct agents that are able to make effective use of it.

In the case that interfaces remain unchanged, agents only need to look at the implementation of a single module at a time plus the interfaces it consumes and implements. And when changing interfaces, agents only need to look at the interfaces of the modules concerned, and at most a limited number of implementation considerations.

It’s the very reason why we humans invented modularization: so that we don’t have to hold the complete codebase in our heads (“context windows”) in order to reason about it and make changes to it in a robust and well-grounded way.

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#27
post #26

Maybe it’s useful to dig out the concept of modularization with a distinction between interface and implementation again, and construct agents that are able to make effective use of it. In the case that interfaces remain unchanged, agents only need to look at the implementation of a single module at a time plus the interfaces it consumes and implements. And when changing interfaces, agents only need to look at the in…

Blogged about modular code and LLMs few days ago

https://www.slater.dev/2026/02/relieve-your-context-anxiety-...

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#28
Outside of packages I doubt few of my code bases would fit into this. But the individual domain areas would. I don't care about users in a orders context, I don't care about payments when dealing with imports, no reason an ai should care either. It shouldn't care about implementations if there's an interface referenced, it shouldn't worry about front end when it's dealing with the back etc.

Scoping the Ai to only use the things you'd use seems far wiser than trying to reduce your codebase so it can look at the whole thing when 90% of it is irrelevant.

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#29
Im curious if there is a deep need for entire codebase to be consumed in the first place?

It would be better to have the architecture support a more decoupled/modular design if you're going to rely heavy on LLMs.

That or let it consume high quality maintained documentation?

Re: Show HN: Badge that shows how well your codebase fits in an LLM's context window

#30
post #26

Maybe it’s useful to dig out the concept of modularization with a distinction between interface and implementation again, and construct agents that are able to make effective use of it. In the case that interfaces remain unchanged, agents only need to look at the implementation of a single module at a time plus the interfaces it consumes and implements. And when changing interfaces, agents only need to look at the in…

Maybe it could just measure the number of tokens for the examples (and then summarize what the examples show, under the assumption that that’s the actual functionality of the project). I’m 90% joking… but that last 10% makes me wonder…
Post reply on HN