these days, i spend my time zooming in on why certain commands or tools take so long to execute from a hardware standpoint. i always find crazy inefficiencies in so many tools i use every day. this is why reverse engineering is so lovely. the tools we have, including long training runs and evals, etc... are bottlenecked by assembly factories (or compilers!). training is limited by the MFU achieved, compilers like bun or cargo or nvcc are bottlenecked by parts of their own compilers like lowering, which such code was compiled by something else. everything just goes back to how good our compilers are and what decisions were made around them given the humans or use cases they were intended for. except now we are using them in weird ways the humans who built them didnt expect, and they are slowing us down a lot. have you ever asked a model to look back into its own traces to see what was taking the most wall clock time? > thinking > code gen > tool calls > specific commands > waiting on something to finish theres a pretty high chance you are never actually bottlenecked by the tokens per second. those in a lot of my cases end up being less than 10% of the time. having a slower more intelligent model which is aware of its own time and how efficient the tool is that its about to call is a serious gap for progress. of course this can be RLed... but the tuning will be a beast of its own for the labs. giving my models some skills around this and hooks for awareness of time has been paying off well in my workflow. hope u enjoyed the ramble haha