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.
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.
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.
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.
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).
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.
I was thinking more if you write a prompt into an IDE that has first-party integration with an LLM platform (e.g. VS Code with Github Copilot), it would make sense on their end to reduce and remove redundant input before ingesting the token into their models, just to increase throughput (increase customers) and decrease latency (reduce costs). They would be foolish not to do this kind of optimisation, so surely they must be doing it. Whether they would pass on those token savings to the user, I couldn't say.
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.
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.
My opinion is I think that there is a massive gulf between 'wrote the spec' and 'validated the output'.
I think if the answer to "could I do this again without claude" is no then it is difficult to claim ownership.
If you're just adding endpoints to some web project and doing feature work then whatever, if you are "rewriting tree sitter in rust" which a lot of these posts seem to be I think it deserves some skepticism.
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.
> The person who commissions a painting doesn't design the composition
They often do! Of course the artist has creative liberty to make it work, similar to how LLM's will deviate from the spec.
Was your automated test suite also AI generated?
You probably could have avoided all criticism by simply writing the article yourself instead of publishing raw LLM output. If someone isn't willing to write about a project they made, it's usually an indicator that they spent an equal amount of effort on the code as well.
And why did you make a commit to remove em dashes? That seems odd.
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
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.
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?
He did some stuff, he didn't do some other stuff. Nothing about this story is automatically invalid or pointless or misleading or unwholesome.
And does 8ms really matter when you're shunting bulk crap back and forth from the cloud?
"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'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.
I think if the answer to "could I do this again without claude" is no then it is difficult to claim ownership.
If you're just adding endpoints to some web project and doing feature work then whatever, if you are "rewriting tree sitter in rust" which a lot of these posts seem to be I think it deserves some skepticism.
They often do! Of course the artist has creative liberty to make it work, similar to how LLM's will deviate from the spec.
Was your automated test suite also AI generated?
You probably could have avoided all criticism by simply writing the article yourself instead of publishing raw LLM output. If someone isn't willing to write about a project they made, it's usually an indicator that they spent an equal amount of effort on the code as well.
And why did you make a commit to remove em dashes? That seems odd.
edit: lol https://github.com/fielding/nit/commit/d83f7cbf4dc540def2708...
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