model-bfcl

Glyphh encodes semantic relationships between files into hyperdimensional computing vectors at index time. At query time, it’s a dot product — no tokens, no LLM, ~13ms. I wired it up as an MCP server for Claude Code and ran head-to-head “what breaks if I edit this file?” comparisons on FastMCP. Across 3 tests: 1 tool call vs 14–36, 3.6–5x faster API time, 26–50% cheaper. Same answer quality — Glyphh just skips the Explore subagent’s grep/read loop because the relationships were pre-computed. The tradeoff: there’s a one-time indexing cost. For novel codebases you haven’t indexed, the Explore agent is still the right tool. Repo: github.com/glyphh-ai/model-bfcl

I've been building Glyphh, a hyperdimensional computing runtime, for two years. This is the first HDC-based entry on the Berkeley Function Calling Leaderboard (BFCL V4), to my knowledge. The idea: LLMs run at build time to generate intent exemplars. At runtime, function routing is pure HDC vector math — sub-ms, zero tokens, deterministic. Claude Haiku handles argument extraction only. The model code is fully open source. Results: 74.50% overall (#2 behind Opus), 83.30% agentic (best on board, beating Opus), 88.71% non-live AST (top 3). Total eval cost: $2.08. Opus runs the same eval at $87 (results not yet verified by bfcl team). The README is transparent about where it struggles (multi-turn: 53.75%) and where the LLM does the work vs HDC. There's also an independent code review in the repo. Happy to answer anything about the architecture