![\"Ancient](\"./alex-moliski-dn54JYggRs8-unsplash-dithered.png\")
\nTL;DR: Running Recursive's new Flint model in Oh My Pi (OMP) was a looping disaster of telegraphic \"caveman speak.\" But running the exact same user prompt in OpenCode was night-and-day articulate and competent. The contrast sent me digging through session traces and harness prompts—and reconsidering how quickly I'd judged the model.
\n\n\n\n\n\nAt work, I just got a new MacBook Pro with 64GB RAM and an M5 Max CPU. Just in time for news about M6 CPUs, but oh well. Still, I'm told this should be pretty capable at running local AI models.
\nSo, lately, I’ve been jumping between two harnesses: OpenCode and Oh My Pi (OMP). Both seem capable, but have different designs and flavors. OpenCode feels like a structured, modular developer workbench. OMP aims at raw terminal speed, token frugality, and minimal ceremony. I haven't done an exhaustive code comparison, so these are just vibey impressions.
\nAt the same time, I’ve been running Flint, an open-weight model released by Recursive Superintelligence. To serve the model locally, I've been using rec, Recursive's own inference engine, which exposes local OpenAI- and Anthropic-compatible endpoints.
The label on the tin says Flint is a sparse Mixture of Experts (MoE) with 40 billion total parameters, but only ~2.5 billion active parameters per token. It uses 4-bit NVFP4 output layer quantization, allowing the full model to fit and execute in unified memory on Apple Silicon via Metal kernels.
\nIn my own runs, actual decode throughput (pure generation speed, excluding prompt prefill and tool execution waits) clocked in around 60–80 tokens per second across sustained agent turns. I'm still wrapping my head around expected performance for local models on this machine, but this seems really good.
\nOf course, speed doesn't mean anything if the model is busy spewing garbage the whole time. So, I decided to put Flint through its paces on a real-world task: running an issue triage pass on the DecafClaw backlog using ghflow.
\nA quick word on ghflow: it's an agent skill I've been building to automate project workflows on GitHub. Instead of me manually clicking through project boards, labeling issues, branching worktrees, and writing pull request summaries, ghflow gives an agent a structured set of reference procedures to triage, scope, and deliver issues.
In a full-scale unattended burndown using a cloud model, ghflow often relies on subagents to parallelize work. But with this local model setup, driving concurrent subagents led to endless KV-Cache thrashing—chewing up GPU time recalculating prompt prefills much like frequent multi-material filament changes on my 3D printer with the MMU3.
So to lean into consistent caching, I explicitly instructed the agent to triage serially in a single session:
\n\n\n\n
@ghflow Let's triage issues not yet triaged, those without triage:* labels. Do so without using subagents, because we're only running one local model and cannot handle parallel requests
My first run with Flint in OMP was a disaster—here's how it started \"thinking\":
\nWe need respond/action. User invoked ghflow, asks triage untriaged issues. \nNeed follow skill. We need inspect. We have no actual tools listed beyond current, \nbut likely can use. Need likely task triage-issues. Must load task reference and \nshared context perhaps. Need not ask. Need gather state. Since they mention \nlong list untriaged. Need run ghflow facts perhaps. First must read selected task \nand shared context.\nMost auxiliary verbs, articles, and copulas have been dropped, leaving a staccato stream of verbs and nouns. I've heard of this caveman thing as an attempt to conserve tokens—i.e. \"why use many token when few token do trick\". But, I don't think this was intentionally that. And even if it was, it didn't work.
\nI let it keep going, if only to see what it would do. After 100 turns, I think the agent had entered what looked like an attractor basin:
\nthink: [\"We need continue. Need understand todo tool format...\"] → calls todothink: [\"We need continue. Need be careful. We need understand task and state...\"] → calls bashthink: [\"We need continue. Need be careful. We need understand task and state...\"] → calls bashthink: [\"We need continue task. Need carefully reason...\"] → calls todothink: [\"We need continue. Need be careful. We need understand task and state...\"] → calls bashthink: [\"We need continue. Need be careful. We need solve user task via tools...\"] → calls bashIt had locked onto a fixed mantra: \"We need continue. Need be careful.\" It repeated that exact phrase, picked a tool, failed to resolve the state, and immediately repeated it again. Seemed like it was lost in a maze of twisty little passages, all alike.
\n![\"Aerial](\"./rafif-prawira-SgTLuX6t8Yo-unsplash-dithered.png\")
\nDigging into the logs around Turn 123 showed one concrete failure inside the loop. Despite its clipped syntax, the reasoning was lengthy—it spent roughly 1,500 tokens of idiotic internal monologue over 30 seconds repeating its mantra without making useful progress, before finally running a bash command:
\n> gh issue view 1145 --json number,title,body,state,labels,comments --limit 20\nunknown flag: --limit\nCommand exited with code 1\nFlint failed to recover cleanly. While it did drop the --limit flag on its next attempt (gh issue view 1145 --json ... --comments), the output was truncated. It fell back to repeating the exact same reasoning chant, firing off piecemeal variants (gh issue view 1145 --json body --jq .body, gh issue view 1145 --json comments --jq '.comments') while constantly resetting its todo tool state without ever progressing to triage. It was stuck in a self-reinforcing spin cycle.
After killing the loop, I thought: Welp. That sucked. Back to Claude, I guess. I was ready to write Flint off as undercooked.
\nA bit later, mostly out of stubborn curiosity, I decided to point OpenCode at the same model and task. The result was night and day:
\nLet me parse this. The user is referencing the `@ghflow` skill and wants to triage \nissues not yet triaged, those without `triage:*` labels. They explicitly say not to \nuse subagents because only running one local model and can't handle parallel requests.\n\nLet me first load the ghflow skill to understand its workflow.\nOpenCode and Flint took the task in stride. It read the skill, loaded the task references, surveyed the open issues, and set about triaging them in a calm, orderly fashion. There was no caveman syntax, no wheel-spinning, and no doom loop. I let it run while I got lunch, and it had finished the job successfully by the time I was done eating.
\nAnd by \"finished the job,\" I mean it actually executed: it swept 35 untriaged issues down to 0 across five bounded batches, resolved decision bottlenecks on three stalled items, defined acceptance criteria on three more, triaged a newly opened mobile issue (#1192), and grew the board's triage:ready pool to 123 issues with clear evidence and labels posted directly to GitHub.
In the issues I checked, the classifications were sound, the summaries captured the actual acceptance criteria, and the decisions held up. No babbling, no loops—just steady work, the way I'd have done it myself.
\nFlint could clearly do this task in at least one setup. That made me reconsider my first impression: I had been judging the model through one particular harness configuration, when the choice of harness—its system prompt, tool schemas, and defaults—might explain the difference.
\nAt this point, pure bafflement took over, and I tumbled headfirst down a research rabbit hole. I wanted to understand how a harness could turn an articulate coding model into a grunting, looping mess without touching a single weight.
\nI'm in a little over my head with everything I read, but let's see if I can take a stab at writing out my hunches.
\nAutoregressive transformers perform a fixed amount of computation per token. In Show Your Work: Scratchpads for Intermediate Computation with Language Models, Nye et al. demonstrated that language models perform significantly better on multi-step reasoning tasks when allowed to generate intermediate tokens as an external scratchpad—a finding expanded by Wei et al. on Chain-of-Thought Prompting.
\nIntermediate reasoning tokens can help models work through multi-step plans, which makes brevity constraints worth investigating here. But these excerpts don't establish that missing grammatical words caused the failure: terse notes can still contain useful reasoning, and fluent prose can still be wrong.
\nThis run wasn’t short of generated reasoning tokens, though; it spent roughly 1,500 of them on one stalled turn. Whether the harness affected how productively it used those tokens is a separate question. (Also, I'm really glad this was on my laptop and not charged by the token in the cloud.)
\nIn other words, I suspect that by causing the model to write \"thinking\" like a caveman, it performed like a caveman.
\nYou can see this design philosophy directly in OMP's source code: its core system-prompt.md on GitHub uses compact wording and many explicit constraints. It defines strict RFC 2119 keywords (MUST, REQUIRED, NEVER) and wraps behavior in dense, inviolable contracts:
Forbidding reflection on limits or budgets: <critical> NEVER narrate/consider session limits, token/tool budgets, effort estimates, or possible completion; start unbounded: execute/delegate. </critical>
Mandating tight tool execution constraints, such as forbidding solo planning turns: NEVER make a todo-only turn: send todo in the same response as the turn's real call (parallel tool calls)—which could help explain why Flint insisted on bundling todo and bash together on every turn of its loop.
Those constraints make prompt design a plausible suspect, particularly the rule coupling todo updates to other tool calls.
\nBut, I haven’t tested whether relaxing them changes Flint’s behavior. The fuller sentences in OpenCode are an observable difference; whether they helped the model complete the task remains an open question.
\nThe repeated openings in OMP were a visible sign that the run had stalled. As Holtzman et al. explored in The Curious Case of Neural Text Degeneration, decoding choices and sampling parameters can easily produce repetitive loops where a model fixates on familiar patterns.
\nIn Flint's case, once it fell into repeating its stilted mantra (\"We need continue. Need be careful.\"), that pattern dominated recent context, resembling an attractor basin.
\nBut, I can’t tell from these traces alone whether the repetition helped sustain the loop or merely reflected it—and differences in default temperature, top-p, or repetition penalties between the two harnesses could be an important unexamined variable.
\nSo, again: These are all slightly-educated guesses. In practical terms, when using Flint, OpenCode works for me where OMP doesn't. That's fine for now. Tool work, me happy.
\nBut, if I really want to keep chasing this, the next step would be to see whether this contrast is reproducible. I could give both harnesses the same frozen set of issues, run each several times, and compare completed triage decisions, tool errors, and time spent going nowhere.
\nThen I’d narrow things down. The failed run corrected its invalid command flag but stalled after encountering truncated output. A tiny test with one issue and deliberately awkward tool responses might help distinguish trouble recovering from errors from trouble with the task itself.
\nI could also capture what each harness actually sends to rec: prompts, tool definitions, sampling settings, and conversation history. From there, I could change one thing at a time—relax an OMP instruction, match sampling settings, or adjust output truncation—and see whether completion improves. Fuller sentences would be interesting, but getting the work done would be the measure that matters.
As someone building both agent tools (ghflow) and harness systems (DecafClaw), this was a practical lesson in debugging local agent workflows:
\nTry another harness before writing off a model: If a local model stumbles or loops on a task, don't immediately assume the weights aren't smart enough. A different harness configuration might yield completely different results.
\nLook across the whole harness stack: Prompts get the most attention, but tool schemas, error formatting, sampling parameters (temperature, top-p), and how conversation history is truncated or summarized all shape model behavior.
\nWatch for repeated actions and check tool responses: When a run stalls, look past the assistant's narration and inspect what the tools actually returned. Repeated reasoning phrases can be a surface symptom of a tool call failing quietly underneath.
\nFor now, when running ghflow against local weights on my laptop, OpenCode remains my default driver. But it's a great reminder of how much the choice of harness shapes what an open-weight model can actually do.
\n\n