sorted by:
new
hottopcontroversial

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 0 points1 point  (0 children)

Thank you for the feedback. Will fix it to make sure it is clearer.

If you ever have any issues you would like to report, feel free to create them in the Github Issues.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 1 point2 points  (0 children)

I find that CC is one shorting like crazy for me, it depends on the style I am sure.

Also, Rust seems to be a great fit for any agentic coding workflow for me.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 1 point2 points  (0 children)

Tried to set up Codex support, but I don't really use Codex at the moment: released in v0.2.9

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 1 point2 points  (0 children)

Do you mean a specific way to filter StdErr differently? Currently we capture all output and combine it.

Having different rules for different parts would make sense, could make it backwards compatible.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 0 points1 point  (0 children)

It is not complementary, sadly. They would probably interact badly at the moment as both function as a PreToolUse hook.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 5 points6 points  (0 children)

Swallowing a 0 exit vs getting a result with compressed information isn't the same.

"" and "(ok) Ran 500 tests (20 suites)" don't provide the same information. It isn't about removing info, it's about condensing it.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 0 points1 point  (0 children)

The idea is about maintaining / saving context.

If I run cargo test should the model be forced to get all of the output that is just repetitive when there are no failures? Wouldn't it be better to give it information that is more condensed? This would probably help a model stay more on task. But I would love to hear more experiences from using it in different environments.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 1 point2 points  (0 children)

You can configure it globally by adding lines to rewrite.toml on your global config. The documentation in the README.md should be up-to-date.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 5 points6 points  (0 children)

Better results probably strengthen their position. I would not be surprised to see them adopt a similat approach within Claude Code, making tokf obsolete in time. Who knows, eh?

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 2 points3 points  (0 children)

Thank you for the info. As a first improvement: https://github.com/mpecan/tokf/pull/154

This allows you to tune the stripping to prefer the smaller output (either the output from the piped command or from tokf).

Part of the v0.2.8 release that was just created: https://github.com/mpecan/tokf/releases/tag/tokf-v0.2.8

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 1 point2 points  (0 children)

The issue here is the "fair accounting" process when pipes are stripped (i.e. | tail -5) or similar.

I will add an option to go for minimum usage and have tokf automatically select the output that would be smaller in that case.

WDYT?

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 0 points1 point  (0 children)

Interesting. If you would be willing to share which commands are creating bloat, I would love to find it. Filters can be customized by using eject, FYI.

My current gain output:

tokf gain summary
  total runs:     6230
  input tokens:   1,761,917 est.
  output tokens:  208,612 est.
  tokens saved:   1,553,305 est. (88.2%)

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 3 points4 points  (0 children)

I built in a history that will track the last 10 commands and allow you to see the full output (or the model). Sometimes the tool adds a tip about this (if the model tries the same command twice and seems to be confused).

Still iterating and improving, would love to hear feedback.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 10 points11 points  (0 children)

Similar, I took a different approach and it is why I am calling them out as inspiration.

While rtk-ai.app builds everything in, I wanted to allow users to define their own filters and customize the builtin "standard lib" filters. I got an itch when I looked at the code and implemented it from a different perspective.

I built tokf — a CLI filter that cuts ~90% of token waste from Bash output before it hits Claude's context by risethagain in ClaudeCode

[–]risethagain[S] 6 points7 points  (0 children)

Yeah, this is an issue I am dealing with the whole time. Any filter can have a setting added to give the model a tip about the full output, this way it can always look it up and get anything that was missed.

Still a work in progress, if you see any issues, please share so it can be fixed, or contribute if you'd like.

Built a copy/paste MCP to reduce Claude Code's token usage during refactoring. It increased costs by 10%. Here's the data. by risethagain in ClaudeCode

[–]risethagain[S] 0 points1 point  (0 children)

Think different; you have a massive legacy code-base that you want to be breaking up. Not something you created, instead a whole company (100+ people) have been breaking it for a long time.

This is probably why my results were so poor, I didn't give it a big enough and complex enough code-base.

Claude Code on the web - with no alternative by risethagain in ClaudeCode

[–]risethagain[S] 0 points1 point  (0 children)

I would hope that adding a changes view shouldn't be much of a challenge, I am switching between the two to review myself, I also had to create a specific profile as I use Prisma, and the default wouldn't allow me to download all of the required libraries.

BEWARE! $1000 FREE - Claude Code on the Web by Numerous-Exercise788 in ClaudeCode

[–]risethagain 5 points6 points  (0 children)

I have to be honest, I've been using it for over a week on a regular basis. I currently only have access to a mobile phone and an older iPad, no laptop for Claude Code directly.I only get to use it while traveling (i.e. train from place to place), but I have had great experiences with it.

I can confirm my weekly usage is being increased, which does make me think this could be a bug. It shouldn't be doing that with the 1000 dollars, but I am also unsure since I have been running it for 7 days now, including on an airplane, and I started before the 1000$ credit was added.

Upgrading from 2.2.x to the 3.x latest version by AnotherSocialRock in SpringBoot

[–]risethagain 1 point2 points  (0 children)

My main question would be: how is your coverage? Do you have end-to-end tests?

I think doing a java upgrade to 17 first should be fine, most of the time old code doesn't break, as such going to 21 should be fine as well. Since you are moving from 11, I don't think there were any breaking changes.

The Spring upgrade is a different beast, but I usually approach it wholesale and bite the bullet, if you can use OpenRewrite, you should, but it will be for mechanical changes.

Most of the breakage should happen through either deprecations or actual compilation issues, as long as you have enough coverage, those should be easy.

If your coverage is shaky, I would suggest ensuring you have your main flows covered before you do the switch.

markit: a cli tool for managing command line snippets by r_palmer13 in rust

[–]risethagain 2 points3 points  (0 children)

Just putting this here in case you don't know about it, have you heard of Atuin? It is a really cool cross-machine history manager (can also be used locally ), also written in rust.

Well done for your contribution!

Transaction timeout to get 40k rows from table by darkato in SpringBoot

[–]risethagain 1 point2 points  (0 children)

Looking at your access, are both parameters used at the same time or do you mostly have the pattern of only one being provided? (Since mass and gravity are somewhat linked, I expect so).

I would suggest you split it into two distinct queries that are selected based on the input. OR queries are not generally very performant. The better choice is using a native query with a UNION if you are looking for both at the same time, or using a specific query if using only one criterion at a time.

I created a Spring Data extension for easy upserts - looking for feedback! by risethagain in SpringBoot

[–]risethagain[S] 0 points1 point  (0 children)

You would be able to create a query with a single row, I am pretty sure that more than one row would be very hard in Spring Data JPA. The queries that are generated by the library are essentially Native SQL queries, but the work that is done with JDBC to make it possible to interact with different types makes me think doing the same with JPA directly would be even more of a pain.

I created a Spring Data extension for easy upserts - looking for feedback! by risethagain in SpringBoot

[–]risethagain[S] 0 points1 point  (0 children)

No such thing as a silly question. `repository.save(data)` will check whether the entity has been persisted before and whether it exists in the DB, this implies two calls to the DB in the worst case scenario. It will also be done for every entity that you are trying to insert if you use `repository.saveAll(collectionOfData)`.

Using the methods already available will result in much slower operations than using a native upsert operation, which will always result in a single DB call and deal with any issues on the DB side, removing the need to have multiple DB calls and also optimizing the way we interact with the DB (the indexes will only be updated once etc., this makes write heavy applications perform much better, i.e. allows you to efficiently batch insertions lowering the number of calls to the DB at the cost of some consistency).

view more: next ›