nit's defaults go beyond what --short does. The token savings come from stripping headers, padding, instructional text, etc. Headers and decorative text ends up tokenizing poorly, so it helps quite a bit there.
It defaults to being a wrapper around git when it's not custom implemented, and it's recommended that you alias nit as git so the agent can work the way it normally would, just faster and cheaper.
It goes beyond what I was able to do with git settings alone. Specifically stripping the headers/padding/decorative and it doees it across all output (or well a lot of it).
You should expect to be gently ridiculed if you submit this as a serious project. Do not use LLMs to claim knowledge or abilities you don't actually have.
It's not impressive, and it's obvious to anyone with more than a year or two of actual programming experience.
- The claim of "71% token savings" is misleading. You've already told us that git output is 7% of the "bash commands", so your token savings is really ~5% of bash command output. Also, the "200K tokens saved" refers the total saved across more than 3000 agent sessions. So it's really just ~60 tokens saved per session. That's a fraction of a fraction of a penny. Did you check your math here? Or just trust the model?
- You have not rebuilt git, you have replaced a small part of its porcelain CLI. Most of what makes git git is in the library code.
- Zig is a high-performance systems programming language that requires the programmer to manage memory manually. You've used it here to handle command line options (and yes, to call into libgit). That is overkill, and that matters, because:
- The performance difference (e.g. 8ms vs 16ms) might be real, but it still doesn't matter at all. For one, there's no way you yourself could tell the difference. The slower time is still a single frame of 60fps. For another, this is not a hot path. These git commands - however fast - are swallowed up by the time it takes the agent to do inference. There's no question that inference itself will take orders of magnitude more time than a 16ms shell command.
The tokens still land in the context window either way. Prompt caching gives you a discount on repeated input, but only for stable prefixes like system prompts. Git output changes every call, so it's always uncached, always full price. Nit reduces what goes into the window in the first place.
no because tool calls are all client side generally. unless you mean using a remote environment where Claude Code is running separately but usually those aren't being charged by the token.
The 71% reduction is interesting but I'd want to see where those tokens are actually going in a typical agent session. In my experience running multi-step coding agents, the git output itself is rarely the bottleneck...
Not saying it is the bottleneck. It's bloat. 7.4% of all shell tokens across 3,156 sessions is a lot of unnecessary context. It won't make or break a session, but it adds up across thousands of calls.
Every "I created <xyz>" or "I rewrote x (y lang) into z lang" should really read "I prompted Claude Code to <insert thing>"
"I" create stuff all the time with AI Agents but am real uncomfortable claiming ownership over them. Others don't seem to have this problem though so /shrug
p.s. - in this case the commits are claude commits, even if they tell it not attribute itself you can tell because good commit messages were incredibly rare (even my own) until the last year or so when they started to look like entire pull requests
I designed the system, wrote the spec, validated the output, and ran it through a test framework I'm building that generates constraints in isolation. Then checks the implementation against those constraints in a feedback loop until they all are met/pass. But yes, claude wrote the code.
I'm comfortable calling that building something. If you're not, that's fine, but the distinction between 'prompted an AI' and 'designed and validated a system using AI tooling' is important.
Yeah, like whatever I prompt I'm fine sharing it, but I'm not gonna claim I made something. It's like claiming I'm an artist because I paid a guy to paint someone.
Is it though? The person who commissions a painting doesn't design the composition, validate every brushstroke, and run the output through an automated test suite. The analogy breaks down pretty fast.
Yeah, Claude is a co-author on the commits. On purpose. You can turn that off in one line, I left it on because I'm not trying to hide it. I do have a day job that takes up the majority of my time, so yes, I absolutely use claude to build side projects.
Nit was actually one of the first projects built via a framework I'm building (specter) that generates code and test constraints in parallel isolation (to prevent gaming the tests/constraints), then uses the constraints as a feedback loop against the generated code.
The agent writes the code, I designed the system, wrote the spec, and validated the output. Perhaps not the way we've built things in the past, but didn't feel all that different to me other than having more time to work on other things while it was running the feedback loop on the implementation
Maybe I'm missing something. If I use `git status --short` or `git log --oneline`, I see output similar to your tool's.
nit's defaults go beyond what --short does. The token savings come from stripping headers, padding, instructional text, etc. Headers and decorative text ends up tokenizing poorly, so it helps quite a bit there.
Why a complete rewrite rather than a wrapper around the cli commands?
Also, aren’t LLMs RLHFd a lot with using tools like git and as such have a better time interacting with it than custom tools?
TFA says there is no difference since it falls through and does act as just a wrapper for anything that it doesn't implement itself.
But that’s my problem, I don’t want it to implement anything itself, I just want it to transform git output.
It's using libgit. IE it is basically still just a wrapper for official reference git implementation. I think you are worried anbout nothing.
correct
It defaults to being a wrapper around git when it's not custom implemented, and it's recommended that you alias nit as git so the agent can work the way it normally would, just faster and cheaper.
So the big token saving was changing a setting that Git already allows you to change?
And does 8ms really matter when you're shunting bulk crap back and forth from the cloud?
It goes beyond what I was able to do with git settings alone. Specifically stripping the headers/padding/decorative and it doees it across all output (or well a lot of it).
You should expect to be gently ridiculed if you submit this as a serious project. Do not use LLMs to claim knowledge or abilities you don't actually have.
It's not impressive, and it's obvious to anyone with more than a year or two of actual programming experience.
To elaborate:
- The claim of "71% token savings" is misleading. You've already told us that git output is 7% of the "bash commands", so your token savings is really ~5% of bash command output. Also, the "200K tokens saved" refers the total saved across more than 3000 agent sessions. So it's really just ~60 tokens saved per session. That's a fraction of a fraction of a penny. Did you check your math here? Or just trust the model?
- You have not rebuilt git, you have replaced a small part of its porcelain CLI. Most of what makes git git is in the library code.
- Zig is a high-performance systems programming language that requires the programmer to manage memory manually. You've used it here to handle command line options (and yes, to call into libgit). That is overkill, and that matters, because:
- The performance difference (e.g. 8ms vs 16ms) might be real, but it still doesn't matter at all. For one, there's no way you yourself could tell the difference. The slower time is still a single frame of 60fps. For another, this is not a hot path. These git commands - however fast - are swallowed up by the time it takes the agent to do inference. There's no question that inference itself will take orders of magnitude more time than a 16ms shell command.
check out rtk that does this for a bunch of commands
Do the larger LLM platforms just do this for you? Or perhaps they do this behinds the scenes, and charge you for the same amount of tokens?
The tokens still land in the context window either way. Prompt caching gives you a discount on repeated input, but only for stable prefixes like system prompts. Git output changes every call, so it's always uncached, always full price. Nit reduces what goes into the window in the first place.
no because tool calls are all client side generally. unless you mean using a remote environment where Claude Code is running separately but usually those aren't being charged by the token.
this is awesome! thanks for sharing rtk.. going to check it out.
The 71% reduction is interesting but I'd want to see where those tokens are actually going in a typical agent session. In my experience running multi-step coding agents, the git output itself is rarely the bottleneck...
Not saying it is the bottleneck. It's bloat. 7.4% of all shell tokens across 3,156 sessions is a lot of unnecessary context. It won't make or break a session, but it adds up across thousands of calls.
Was this entirely created by an LLM? The article clearly was.
Every "I created <xyz>" or "I rewrote x (y lang) into z lang" should really read "I prompted Claude Code to <insert thing>"
"I" create stuff all the time with AI Agents but am real uncomfortable claiming ownership over them. Others don't seem to have this problem though so /shrug
p.s. - in this case the commits are claude commits, even if they tell it not attribute itself you can tell because good commit messages were incredibly rare (even my own) until the last year or so when they started to look like entire pull requests
I designed the system, wrote the spec, validated the output, and ran it through a test framework I'm building that generates constraints in isolation. Then checks the implementation against those constraints in a feedback loop until they all are met/pass. But yes, claude wrote the code.
I'm comfortable calling that building something. If you're not, that's fine, but the distinction between 'prompted an AI' and 'designed and validated a system using AI tooling' is important.
Yeah, like whatever I prompt I'm fine sharing it, but I'm not gonna claim I made something. It's like claiming I'm an artist because I paid a guy to paint someone.
There are certainly artists that have helpers that do the actual execution.
Is it though? The person who commissions a painting doesn't design the composition, validate every brushstroke, and run the output through an automated test suite. The analogy breaks down pretty fast.
Yes: https://github.com/fielding/nit
edit: lol https://github.com/fielding/nit/commit/d83f7cbf4dc540def2708...
Yeah, Claude is a co-author on the commits. On purpose. You can turn that off in one line, I left it on because I'm not trying to hide it. I do have a day job that takes up the majority of my time, so yes, I absolutely use claude to build side projects.
Nit was actually one of the first projects built via a framework I'm building (specter) that generates code and test constraints in parallel isolation (to prevent gaming the tests/constraints), then uses the constraints as a feedback loop against the generated code.
The agent writes the code, I designed the system, wrote the spec, and validated the output. Perhaps not the way we've built things in the past, but didn't feel all that different to me other than having more time to work on other things while it was running the feedback loop on the implementation