NIMBL - Devlog #7

for some reason i got way to many hours on this project and this is prob because my hackatime tracks my benchmarks so Iam gonna request that they like cut it in half idk, dont wanna be fraud reviewed. This phase was about resetting and reconfiguring

Benchmarks

The benchmarks were horrendus and I realized that something is going insanly wrong so i decided to do a full reset. Scrap my architecture and go back to a opencode baseline architecture and just remove and add diferent parts. this took only 6 hours but as said my hackatime is bugging prob hoing to try removing 30hours because i just noticed it doesnt make sense.

Next Steps

Optimizing the archtitecutere and not running anymore benchmarks till Iam sure of this architecture also contactiing stardance cause aint now way iam getting fraued reviewd.

NIMBL - Devlog #6

I noticed that the last few devlogs were quite lazy and to be frank trash. So this section is just getting you upto date. Explaining the problem, goal, benchmarks and architecture and just giving you a short summary.

What is NIMBL?

NIMBL which stands for nimble which describes a person as being fast, agile and efficent.

Nimbl’s goal is it to allow users to get a coding harness which is half the cost and dobule as fast and allows for them to keep around 80% of the intelligence.

It also includes 4 modes learn,explain,plan and build. Plan and build are just the typical modes you see in all harness like opencode and explain is a copy of plan but adjusted, so it shows examples and is able to retrieve the codebase ligthning fast and offer detailed explanation. Learn is the same as build but with measurements in place so you cant just prompt it rather it give you example code or code with simple mistakes and you have to fix them yourself.

What have I done?

So since fully porting the Opencode tui I have decided to work on nimbles effectivnes I first starded with indepth analysis of other harness and how they work their benefits and their drawbacks. So for example how Pi is ligthweight or how Aiders gathers context. Afterwards I summarized everythign i learned and implemented it, and then came the benchmarks i first started with a local 75 test benchmark across all kinds of test from lh, mf to retrival tasks on which nimbl performed great with being 3x cheaper and achieving a 98% solve rate.

Benchmarks

The next step was running NIMBL on offical benchmarks for that I choose SWE Lite as it one of the more reputable ones and smaller ones. OF course I wouldnt be able to run even that size as it around 120GB and I dont have that much money for benchmarks. Just so you know evey benchmark I have run used openrouter credits and Iam the person paying for them. So i sliced it, Slicing means instead of running all you take out a certain part and download only that and run only that.
On that slice NIMBL was miserable solving 1 out of 15 task. After further optimizing the logic behind it NIMBL is now at a point where it reaches around 80% accuracy and is a third of the price.

How does NIMBL work?

NIMBL's main architecture is built around a layered context and execution pipeline.

The project is indexed using lexical search, structural parsing, and dependency-graph relationships.

When a task is received, NIMBL classifies it and retrieves only the most relevant files, symbols, and related dependencies.

The retrieved context is compressed and placed into a stable prompt structure, allowing provider-side caching to reduce cost and latency.

The agent then works through the task using tools, tests, diagnostics, and bounded execution loops.

The result is tracked through token usage, cache hits, cost, latency, and success metrics.

This allows NIMBL to stay lightweight while still having access to the important parts of a codebase. The goal is not to send less context blindly, but to send better context.

Combined with the different learning modes, this gives NIMBL the foundation to become a faster, cheaper, and more educational coding harness.

in the screenshot you can see how much credits i got left i had 10 at the start of the development. Hopefully this made NIMBL easier to understand and gave a short overview

NIMBL - Devlog #6

This phase was still about benchmarking optimizing reading papers to see if i can implement some new logic and benchmarking again. I burnder through atelast 400mil tokens which were used in the benchmarks whihc like 10$ openrouter credits and a bit of opencode go

Benchmark

The results were overhemlingy postive with nimbl achieving a 300/300 fix while being 2.2x cheaper accros all task combined this came mainly from retrival which is understandable as nimbls architecture is build on the idea of rag and we further refined it but even on lh(long horizon) and mf(multi files) it was great

#Next steps
Damn i take everything i just said back iam runnign offical swe lite tests now and nimbl is performing like shit because of our inbuild steps limit which i forgot its unable to solve the tasks and is failing, so its back to bug fixing see you in a few days.

NIMBL — Devlog #5:

This Devlog ran another benchmark: 25 tasks × 3 samples, hidden golden tests only, and the same model on both harnesses (deepseek-v4-flash). I also used these results to fix the mistakes I found and run the benchmark again, which is running rn.
NImbl is ca 40% more token efficent half the price and caches better.

The Results

NIMBL: solved 68/75 tasks, with total tokens of 2,386,450, wall time of 37.7 min (2,264 s) and throughput 1,054 tk/s.

opencode: solved 75/75 tasks, with total tokens of 2,436,642, wall time of 71.2 min (4,270 s), throughput 571 tk/s.

NIMBL finished 1.9× faster and actually used fewer total tokens than opencode. The tradeoff is that it didn’t finish 7 tasks, and those failed runs still spent real tokens, so this wasn’t a cheap excuse to give up early.

On the 4-mode run NIMBL also used around 40% fewer tokens per solved task (26.2–28.0k vs opencode’s 46.8k, −40% to −44% in every mode). That shows the savings were never only coming from retrieval tasks.

By Category results

bug-fix tasks: −7.2%
retrieval tasks: −51.1%
multi-file tasks: −16.3%
running agent delegation: +130.2%
long-hunt: −35.3%
shell-loop: +6.3%
test-write: +116.9%

What It Says

The results are pretty decent, and they are getting better. Retrieval now uses half the tokens at a third of the latency: 7 seconds compared to opencode’s 19 seconds.

NIMBL is faster in every category, even delegation, where opencode takes 116 seconds per task. The architecture is doing great, and reference cost lands at about half of opencode’s (~$0.26–0.28 per solved task vs ~$0.51).

The losses are concentrated in two specific places. Delegation costs 130% more tokens — 373,493 compared to 162,256 — and test-write costs 117% more and it did all this and still failed so it practically wasted tokens

The reason for that is simple: we had a hardcoded limit of 8 tool calls, which wasn’t enough for these long tasks, opencode ran ~100. So NIMBL kept reading files and crashed when trying to run an edit, because it ran out of tool calls. The fix was basic: instead of hardcoding every tool call limit universally, adjust them according to the task.

Running Now

A new benchmark is running rn trying to use these fixes to finally close that gap of tool calls and get fully functional harness which is cheaper and better after local benchmarks work I will run it in a real benchmark like swe lite or sth

NIMBL - Devlog #4:

This devlog is about the one thing NIMBL was built for: proving it saves tokens without making answers worse. I built a real benchmark, ran it against opencode, and got cooked.

The Tier B benchmark

I generated a ca 150-file TypeScript “storefront” app with planted bugs, decoy files, and hidden golden test suites. 25 tasks spread across retrieval, bug-fixing, multi-file work, test-writing, shell loops, delegation, and long-horizon fixes.

The key part: every bug is only caught by hidden tests, so an agent can’t cheat by reading the grader. Ran it live on the same model for both harnesses: deepseek-v4-flash, 3 samples per task, 75 runs per side.

And critically — every single result is saved raw, not summarized. Full event streams, tool calls, token splits, everything, so nothing can be hidden.

The results

solved mean tokens NIMBL (hybrid) 68/75 28,004 opencode 75/75 23,352

opencode solved more and used fewer tokens. That stings, but it’s the truth, and the raw data is committed.

Where NIMBL genuinely won: retrieval tasks (+63% fewer tokens) and latency (26s vs 49s per task). Pure lookup-and-answer is where the context index shines.

What went wrong

• Shell mismatch (the big one). NIMBL runs commands through PowerShell but never told the model that. So the model wrote POSIX (find | sort, 2>&1, head) and 60 of 113 shell calls failed. opencode tells the model it’s PowerShell, and the same model wrote working commands. The fix is a one-line hint in the tool description.

• Analysis paralysis. One long-horizon task spent 78 tool steps reading files, never ran a single test, never edited anything. All 3 samples failed while opencode fixed it every time.

• Delegation overhead. Subagent “research” cost 7k-27k tokens per task with no payoff. opencode solved the same tasks inline for a fraction of that.

• Hallucinated answers. One retrieval task answered “42” with zero tool calls, never reading the file that had the answer.

Where it stands

NIMBL has permissions, sessions, providers, budgets, context selection, structural extraction, tokenizers, and a real benchmark harness that saves raw output for every run. It’s genuinely usable for simple coding.

But the benchmark says what the benchmark says: the token win is retrieval-only for now. The next devlog should be about the shell fix, the delegate budget, and seeing if the numbers move.

NIMBL - Devlog #3: Full redesign

In this section I did a lot I used AI to port the opencode UI to mine and then did the changes so it fits mine more appropiate such as more modes instead of just build and plan and did indepth work on the backend

The UI: Port Opencode and credit them

The first NIMBL chat screen was heavily inspired by OpenCode. I realized that it didnt make sense to deign it myself if opencode is under the MIT lisence and I love their UI so I used the downloaded opencode directroy to port it into nimbl with the help of AI and routed the backend to it. Of course I didnt forget that I need to update my readme so they get all the credit they deserve

The app now has a transcript, persistent prompt, modes, autocomplete, dialogs, provider/model controls, message actions, paste handling, and token/cost status. So its fully functional for a beta and got all necessary commands

The Backend

The early version could call a model but thats it, it couldnt read files or write them. So i implemented File operations but made it they reject project or symlink escapes, .env files, Git metadata, NIMBL state, credentials, and private keys. Commands have allowlists, timeouts, bounded output, abort support, and explicit permissions. Build mode gets write tools so with that you can code but all other 3 modes do not.

Also implemented sessions so you can open old sessions just like in opencode, this project is proball going to be a more token efficent opencode but in noway an alternative

Also worked on how cost are caculated but this was quite hard and I still dont understand it I let AI do it without understanding it but I will try to learn more of it later.

Context

Dumping a whole repository into a prompt is expensive and bad. To fix this, NIMBL keeps a lightweight local index of your project. It automatically respects .gitignore rules, skips binary files and oversized logs, and watches for changes in real time so it never wastes time rescanning everything from scratch.

Finding the right files isn’t handled by rescaning the entire directory but saved in its memeory. it uses straightforward text matching based on terms, symbol names, and file paths. More importantly, NIMBL shows what it did, you can see exactly which files were picked, why others were skipped, and how many tokens the prompt actually used.

Where It Stands

The project now posses, permissions, sessions, providers, budgets, context, structural extraction, tokenizers, and much more and I tried it myself and it can be used for simple coding.

The next step is proving NIMBL saves tokens on tasks without making answers worse. Which it was orignally designed for

NIMBL — Devlog #2: TUI Design(Hell)

This devlog covers how I actually built the thing, and the nasty bugs I had to fix. Also that I should probably pause this to further learn frontend. Cause iam trash at frontend

Choosing OpenTUI (and Fighting It)

I needed a terminal UI framework that could run under Bun on Windows. Textual was too heavy. Ink (React) had reconciler conflicts. OpenTUI was the right call. It’s what OpenCode uses in production, it’s fast, and its SolidJS works well with the reactive state model. But it wasn’t plug and play. Which I didn’t expect.

Out of the 9 hours I spent on this phase, maybe 2 were actual feature work. The rest was bug fixing.

First wall: the native DLL kept crashing. OpenTUI tries to pass color objects to a Windows native DLL, but the way they format the data doesn’t match what the DLL expects. Every time the TUI tried to draw anything, Bun would crash. I couldn’t figure this one out on my own. Had to get help from an AI coding agent (the newly bought OpenCode Go) to trace through the crash logs and find the fix. The solution was simple once found: use color hex strings like "#06402b" everywhere instead of color objects. OpenTUI handles the conversion internally and the DLL stops crashing.

Second wall: wrong import path. OpenTUI’s SolidJS build tries to import from a file path that Bun 1.3.14 can’t load properly, causing a different kind of crash. One line change in the library file. Change solid-js/dist/solid.js to solid-js and it worked. Small fix, but took hours to find because the error message just said “Cell” with no explanation. Probally should have used Ai for that

Studying OpenCode’s Architecture

Instead of guessing the layout, I got AI to pull anomalyco/opencode from GitHub and read through their TUI package. Two key discoveries:

The prompt input works like OpenCode’s. I tried using the single-line input component first, but it wouldn’t submit on Enter. OpenCode uses a multi-line textarea with a trick: they grab the text directly from the component on every keystroke, and when you press Enter (without Shift or Ctrl), they intercept it, stop it from making a new line, and send the message instead. I do the exact same thing now and it actually works.

The green bar on the left. Every input box and every message in OpenCode has a thin vertical colored line on its left edge. It’s just a simple border, but it makes the whole interface feel structured and intentional. I borrowed that. Green accent bar for user prompts, dimmer gray for NIMBL replies. Cheap to render, huge visual upgrade.

TUI Structure

Two screens, one signal: view() toggles between "home" and "chat".

Home screen – Centered layout with the ASCII NIMBL logo, tagline, and a bordered textarea. The green left-border accent matches my brand.

Chat screen – Scrollbox of message bubbles (each has an accent bar + label), with a persistent input at the bottom. Token count and estimated cost update in the status bar on every response. /quit and /clear are wired in both views.

What’s Next

the app works. I type a prompt, Enter submits it, the API calls, and the response renders in the chat view with token usage shown. The next plan is adding all the modes, AI provider switching, plan and build mode, and letting the AI read and write files. Plus the /compact command from OpenCode. The screenshots show how it looks now and how it looked before. Heavily inspired by OpenCode and some elements are even copied, so the readme will fully credit them. Also I’m allowed to use them as they are under MIT license. Bless OpenCode.

Stack: Bun 1.3.14 · OpenTUI 0.4.5 · SolidJS 1.9.10 · TypeScript strict · Vercel AI SDK 7

NIMBL — Devlog #1: Building a Token-Efficient CLI Companion

I started NIMBL because I wanted a coding assistant that lives in the terminal and actually conserves tokens instead of burning through context windows. The goal for this first phase was to build a lightweight, responsive tool with a polished feel without unnecessary bloat.

---

Adapting OpenCode’s TUI Architecture

My initial approach was building a terminal interface from scratch using standard Textual widgets. I got a basic mockup working, but the component architecture felt rigid and didn’t scale well. Instead of continuing with a fragile layout, I pulled down the OpenCode CLI source code (anomalyco/opencode), studied its TUI architecture, and adapted its two-column layout system for NIMBL.

• Decoupled Components: Refactored the app into a persistent sidebar (housing the model selector and session history), a main chat panel, and a live status bar.
• Theme & Identity: Extracted the CSS structure into styles.tcss. I kept the dark background (#0a0a0a) but shifted the accent color from orange to a custom green (#4ade80) to give NIMBL its own identity.

---

Multi-Provider Backend & Failover

The backend is where the core engineering happened. I built a multi-provider API client that speaks OpenAI-compatible endpoints across Hack Club AI, Google AI Studio, Groq, and local Ollama.

• Automatic Failover: If an active provider drops or hits a rate limit, the client automatically rotates to the next available provider without interrupting the session.
• Streaming & Telemetry: Responses stream directly into the chat panel in real-time, with token usage tracked on every API call to keep resource consumption visible.

---

Context Budget Allocator & /compact

To keep context usage strictly governed, I built a context engine driven by a token budget allocator. Instead of letting prompts grow infinitely, the context window is portioned into fixed allocations:

• 15% System Prompts: Reserved for base instructions and active mode constraints.
• 25% Retrieved Context: Allocated for project structure, active files, and RAG retrieval.
• 35% Conversation History: Dedicated to the active chat thread.
• Scratchpad Space: The remaining allocation is preserved for scratch work and generation.

The system automatically warns you when reaching 60% capacity and provides a /compact command to summarize and prune older messages.

---

Modes, Gamification, and CLI

NIMBL features three operational modes, each with its own system prompt and context state:

• Assist Mode: A direct coding partner focused on concise, minimal code suggestions.
• Learn Mode: A Socratic tutor that guides you through concepts using progressive hints rather than giving answers immediately.
• Review Mode: A teaching code reviewer that explains why code is problematic rather than just flagging syntax.

I also integrated a learning tracker that records XP, streaks, and skill mastery as you work through concepts, alongside a prompt cache layer that estimates savings from repeated system prefixes.

Everything is wrapped in Click commands: nimbl run launches the TUI, nimbl ask handles one-shot terminal queries, and nimbl setup walks through API key configuration.

---

Next Steps

• UI Event Integration: Wire TUI message events (MessageSubmitted) directly to the backend agent logic.
• Telemetry Refinement: Connect the status bar directly to real-time token metrics.
• Local File Tooling: Implement tools to let the agent read and write files.