What We Built at the OpenClaw Global Unhackathon

We spent the weekend at the OpenClaw Global Unhackathon with agent-meter — our open-source metering infrastructure for AI agents. The project was already live before the event. What we built during the hackathon was the demo that makes the problem visceral.

What agent-meter is

Agents are getting wallets, API keys, and autonomy — but nobody is metering them. agent-meter is a usage metering layer that gives every agent a budget and every API a kill switch. Three lines of middleware. No code changes in your handlers.

The stack:

TypeScript SDK on npm
Rust crate on GitHub
Hosted backend live at api.agentmeter.io
MCP server so agents can query their own usage conversationally

All of this was shipping before the hackathon. What we didn’t have was a way to show it.

The demo

We built a live simulation: four agents hitting an API with different consumption patterns, rendered in a real-time dashboard.

agent-meter dashboard showing four agents — research-bot, billing-agent, data-crawler, and rogue-bot — with live usage breakdown and activity feed

What you’re seeing: research-bot and billing-agent are well-behaved — steady request patterns, staying within budget. data-crawler is busy but predictable. Then there’s rogue-bot. It floods the API, blows through its rate limit, and starts getting 429’d — while every other agent continues unaffected.

The punchline: metering IS budget enforcement. The same system that tracks usage also enforces limits. And through the MCP server, agents can introspect their own budgets conversationally — “what’s my usage summary?” — no dashboard required.

Three conversations we kept having

The hackathon wasn’t just about building. The best parts were the conversations. Three topics came up repeatedly:

Tool distribution and discovery. How do agent infrastructure tools get discovered? MCP is the protocol, but there’s no npm-for-MCP yet. We wanted to talk to the Composio team and anyone thinking about tool ecosystems. The distribution problem for agent-native infrastructure is fundamentally different from human-facing SaaS.

Agent-to-agent metering. If you’re building multi-agent workflows, how do you handle usage tracking between agents? Agent A calls Agent B’s API, which calls Agent C’s. Who pays? How do you attribute cost? We think metering is the missing primitive that makes agent-to-agent commerce possible.

Agent identity and auth. Per-tenant keys, trust boundaries, identity for non-human actors. Where does authentication meet metering? This is the question that keeps pulling us deeper — you can’t meter what you can’t identify, and agent identity is still unsolved infrastructure.

Architecture

┌─────────────┐     POST /v1/usage/batch     ┌──────────────────┐
│  Agent SDK  │ ────────────────────────────▶ │  agent-meter     │
│  (3 lines)  │ ◀──── 200 OK or 429 ──────── │  server (Rust)   │
└─────────────┘                               │                  │
                                              │  SQLite + rate   │
┌─────────────┐     GET /v1/summary           │  limits per      │
│  Dashboard  │ ────────────────────────────▶ │  (service,agent) │
│  (browser)  │ ◀──── real-time JSON ──────── │                  │
└─────────────┘                               └──────────────────┘
                                                       ▲
┌─────────────┐     MCP tools (13 total)               │
│  Claude +   │ ───────────────────────────────────────┘
│  MCP server │    "what's my usage summary?"
└─────────────┘

What’s next

The hackathon validated what we suspected: the people building agent systems right now are all hitting the same wall. They can orchestrate agents, give them tools, even give them budgets — but they can’t meter what those agents actually consume. The metering layer is missing, and everyone we talked to recognized the gap.

We’re shipping. The SDK and hosted backend are live today. If you’re building agent infrastructure and want metering that works, start at agentmeter.io.