A 32K local model drove REA over MCP: 3 of 3 with 10 tools

[CassieFox23]

TL;DR: A local 27B model with a 32K window drove REA over MCP and got the right answer 3 times out of 3. It worked only when the model saw about 10 tools. With the full tool list, nothing fits. The tool families in PR #3026 shrink the list a lot. A client-side allowlist on top makes it fit.

Why this matters

REA's full tool list is far too big for most local models. That has been the wall for local AI. I wanted to know what it takes to get under it.

What I ran

• Model: Qwen3.8-27B (Apache-2.0), 32,768 context, through llama.cpp (MIT) on one 12 GB AMD card.
• Model files: the official base is Qwen/Qwen3.8-27B. The GGUF is the GSQ-RCO IQ3_XXS quant from ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF. It is not the OrcaRouter fine-tune.
• Client: OpenCode 1.18.33 (MIT), with every built-in tool off.
• REA: PR feat(mcp): scope advertised tools by family through REA_MCP_TOOL_FAMILIES #3026 at d993ffe, which is still open. It adds REA_MCP_TOOL_FAMILIES.
• Target: a tiny C program built for this test. One function checks a token against a hidden string.
• Ask: "use REA to find the string in check_token and say what the function does."

Results

Setup	Tools	Prompt tokens	Result
Full tool list	206	248,762	Refused at once: too big for 32K
session,direct + compact	62	28,628	12.7 min to read the prompt, then a GPU reset killed the run. No answer
Same, plus a 10-tool allowlist	10	4,407	Right answer, 3 of 3 runs

Each good run took about 80 seconds. Each made the same four calls: open the file, find the function, decompile it, close. All three found the string and explained the check.

The size of each part

I used the model's own tokenizer. I counted only what a model sees of each tool: its name, description and input schema.

What loads	Tools	Tokens
Everything	206	193,578
Everything, compact	206	79,788
session only	21	26,972
session only, compact	21	15,489
session,native, compact	44	21,313

open_binary lives in session. So any setup that can open a file starts near 15K tokens, even with compact schemas. Four heavy compare tools make up over half of session's bytes. The decompile and string tools sit in direct, not native.

What worked

Families on the REA side, then an allowlist in OpenCode's tools map:

{
  "rea_*": false,
  "rea_open_binary": true,
  "rea_close_binary": true,
  "rea_binary_session": true,
  "rea_list_procedures": true,
  "rea_search_procedures": true,
  "rea_procedure_pseudo_code": true,
  "rea_list_strings": true,
  "rea_search_strings": true,
  "rea_xrefs": true,
  "rea_procedure_references": true
}

OpenCode drops the tools you switch off. I checked the request body: 62 tools without the allowlist, 10 with it.

Not run

• More than one target and one prompt. Three runs that take the same path are not three separate proofs.
• Other local models, and other clients.
• A smaller session family, or a tool allowlist inside REA. Either would help clients that have no tool filter, but I haven't tried them.

Thanks, 0xLLVEL, for the tool families PR. Thanks, morluto, for wanting REA to run well on local models.

Edit (2026-10-14): added where the model files come from.

Test setup

• Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
• GPU: AMD Radeon RX 6700 XT, 12 GB
• Node: 24.18.0
• Head: d993ffe (PR feat(mcp): scope advertised tools by family through REA_MCP_TOOL_FAMILIES #3026)
• Base: bee73fc
• Other: Ghidra 12.1.4 (Apache-2.0)
• Other: llama.cpp with Vulkan (MIT)
• Other: OpenCode 1.18.33 (MIT)

How I counted

• The real prompt sizes come from llama.cpp's own usage numbers on the sent requests.
• The full-list row was refused, so its size comes from the server's error. It matched a dry count done with llama.cpp's template and tokenize endpoints.
• The size table counts the compact JSON of each tool's name, description and input schema. I used llama-tokenize with the model's vocabulary only.
• OpenCode alone, with no tools at all, is 1,959 tokens.

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊