But it got me interested in a topic I have been calling "token economization." I'm sure there's a more common term from it but I'm a newb to this tech. Basically, how to optimize the "run rate" for token utilization per request down.
Have you taken a stab at anything along this vein? Like prompt optimization, and so on? Or are you just letting 'er rip and managing costs by reducing request volume? (Now that I've typed this comment out I realize there is so much I don't know about basic stuff with commercial LLM billing and so on.)
[1] https://github.com/mattdeboard/itzuli-stanza-mcp
edit:
I asked Claude to educate me about the concepts I'm nibbling at in this comment. After some back-and-forth about how to fetch this link (??), it spit out a useful answer https://claude.ai/share/0359f6a1-1e4f-4ff9-968a-6677ed3e4d14
I may take a crack at this tool next week.
Lexega is asking a different question though. sqlfluff asks "is this SQL well-written?", while Lexega asks "is this SQL dangerous?". It parses into a full AST and emits signals (categorized AST components) that can be matched against YAML rules to block PRs or execution in agent runtime mode. DELETE without WHERE, GRANT to PUBLIC, PII exposure without masking, DDL that drops tables in production pipelines. The output isn't "fix your style", it's "this query violates an organizational risk policy and shouldn't be allowed to hit production".
Think code quality vs. risk analysis. Both useful, different jobs.
Good call on the GitHub link - I need to fix that.
You work with junior devs that have those abilities? Because I certainly don't.
I know that's been a meme since forever, but my first hand experience supports it to the extreme.
Did the bad route cause an overload? Was there a code error on that route that wasn’t spotted? Was it a code issue or an instance that broke?