That rename of the Finops foundation to tokenomics foundation or whatever sucks. This is just a cash grab attempt to have a foot in the AI bubble and gather more money for their “non-profit” 200k+ salaries each. We’re still doing Finops, AI is just one additional topic we should manage.
Just add “AI cost management” as a discipline of Finops, and that’s freaking it. Everyone sees through your bs.
After building a multi-agent research pipeline, I realized that useful information about AI token efficiency is scattered everywhere.
There are separate tools and papers for:
- token monitoring
- prompt and semantic caching
- context compression
- model routing
- memory
- multi-agent orchestration
- pricing and benchmarks
- verification and evaluation
So we started collecting the best resources in one place.
The result is Awesome AI Tokenomics, currently with 197 verified entries across tools, research, practices, concepts, claims, and reusable setups.
It is not meant to be only another long link list. We also track maintenance and freshness, require primary sources, and keep the descriptions factual.
I would especially appreciate feedback on:
- important projects we missed
- categories that should be reorganized
- claims that need stronger evidence
- practical token-saving setups worth adding
Disclosure: I maintain this repo as part of my work at Quesma.
I’ve been working on an open-source project called AVE (Agentic Vulnerability Enumeration), the behavioral classification standard and would really appreciate feedback from security professionals.
The motivation is that we’re starting to secure things like:
- MCP servers
- Skill files
- System prompts
- Agent plugins
- Agent workflows
But today’s vulnerability identifiers (CVE, OSV, etc.) are designed around software packages and versions. They don’t describe behavioral attacks that exist only because an LLM interprets instructions.
For example:
- Prompt injection hidden inside a skill
- Tool description poisoning
- MCP server-card injection
- Memory poisoning
- Cross-agent prompt injection
- Silent tool registration
- Unsafe delegation chains
These aren’t tied to a vulnerable library version, they’re behavioral attack classes.
So AVE attempts to provide:
- Stable IDs for behavioral attack classes (currently 59)
- A JSON schema for interoperability
- AIVSS scoring (built on CVSS concepts with agent-specific risk factors)
- Crosswalks to OWASP MCP Top 10, MITRE ATLAS, NIST AI RMF, and other AI security frameworks
- A reference scanner (Bawbel Scanner) that detects AVE patterns in skill files, MCP manifests, and related agent artifacts
I’m not claiming this is the right solution, and I know standards only become useful if practitioners find them valuable.
I’d really appreciate criticism on questions like:
- Does this solve a real problem, or are existing standards already sufficient?
- Should these behavioral classes live under something like CVE/CWE instead of a new namespace?
- Are the attack classes too broad or too granular?
- Does the AIVSS scoring model make sense, or is there a better way to score agentic AI risk?
- What important attack classes am I missing?
- If you were building security tooling for AI agents, would a registry like this be useful?
I’m especially interested in feedback from people working in AppSec, AI security, offensive security, detection engineering, or anyone building MCP/agent ecosystems.
I’m looking for honest technical criticism more than praise. If you think this is the wrong direction, I’d genuinely like to know why.
Thanks for taking a look.