# OnlyTerp/opengrok injects a model picker into the Grok Bot app bundle

> OnlyTerp/opengrok is a config sidecar for an existing Grok Bot desktop install: it writes per-provider wire maps, injects a model picker into the app bundle, and ships a doctor that reports what a silent vendor update moved. Its most interesting content is not the picker but the rule that a field returning 200 and doing nothing is worse than a 400.

**OnlyTerp/opengrok** — Run any model in Grok Bot — one-command setup, model picker UI, evidence-based provider wire maps, and an update-proof doctor. Not farming you, arming you.

- Repository: https://github.com/OnlyTerp/opengrok
- Website: https://github.com/OnlyTerp/opengrok#-quick-start
- Stars: 474 · Forks: 55
- Language: JavaScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/onlyterp-opengrok

## The repository name does not describe what the code configures

The repository is called opengrok, and none of what it does has anything to do with code search. The README is explicit about scope: this is a config sidecar for an existing Grok Bot install that writes model bindings, wire maps and a health doctor next to that install. It states that it does not host or emulate Grok Bot, does not control your machine, and does not ship auth shims. One term needs unpacking before anything else makes sense, because the word hop is used throughout: a hop here is simply any OpenAI-compatible base URL, the same value you would paste into another tool.

Prerequisites are a working Grok Bot desktop app, Python 3.9 or newer, Node 18 or newer for the picker and the maps, and API keys for whichever provider you bind. The header also carries two claims worth holding loosely, that keys never leave your machine and that every wire claim in the repository is probe-verified rather than guessed, alongside a line about not farming you and not arming you. Nothing in the tree contradicts the scope statement, but the name will mislead anyone who arrives from a search for a code search engine.

## setup.py runs five phases, probes two ports, and asks three questions

Installation is a clone and one command:

```bash
git clone https://github.com/OnlyTerp/opengrok
cd opengrok
python setup.py
```

The script's own docstring lists the phases: detect the Grok Bot install, platform, existing config and running services; plan and print exactly what it will do with nothing hidden; wire a bindings skeleton, a services file, a doctor baseline and a picker seed; verify by running the doctor so every check is either green or explained; and open the picker. The interactive surface is deliberately small. The question helper asks once, treats an empty answer as the default, and re-asks with the valid options when choices are supplied. Detection is done with cheap probes: a TCP connect check with a one second timeout, and an HTTP probe that reads at most two thousand bytes and optionally asserts that a marker string appears in the body.

One detail in that file is worth a second look. The probe catches urllib.error.HTTPError, while the import line at the top names only urllib.request. The error class still resolves, because the request module pulls the error module in behind it, so the code works through a transitive import rather than the one it asks for.

Two more entry points exist for later:

```bash
python tools/doctor.py        # anytime: is everything still healthy?
python tools/glass-inject.py --check   # is the LiquidGlass HUD in the app?
python tools/qa.py            # repo self-check: leaks, refs, tests
```

## The panel is injected into the app bundle rather than installed beside it

There is no install into the target application. The README describes the picker as injected into the app bundle by this project, riding silent updates, under the MIT license. That single design choice explains almost every other decision in the repository. Because the code lives inside a bundle the vendor rewrites, the injection is anchored on stable names, the entry document and the content security policy directive, and never on the hashed bundle file. A layout change is treated as a hard failure rather than a silent no-op, there is a watch mode with an auto-relaunch that self-heals while the app is closed, and a quiet mode that stays silent when nothing has drifted so it can run from cron.

What the panel does once it is inside is mostly visible state. A model can be swapped mid-chat, so the next reply rides the new provider without a restart. Each switch is confirmed end to end through the hop proxy before it counts, with a copy-proof action that hands back the receipt. Per-bot telemetry covers throughput, time to first token, token flow and prompt-cache hit rate, a context bar watches the 256k window so a long session does not clip mid-run, and a single deck addresses 28 bots with commands to walk the fleet, open diagnostics and logs, and reset a stuck thread.

## Six provider families fail in six different ways

The most useful page in the repository is the per-family table of what goes wrong when a foreign model is dropped into this harness without adjustment. The stated cause is harness mismatch: a model was trained on its own harness's wire shape and then handed a generic prompt shape with the wrong reasoning knobs. Each row names a distinct defect and the remedy.

Grok has an effort knob named xhigh rather than max, and its fast option is not a field at all, so the project maps tokens literally and documents always-on reasoning. GLM thinks by default, which the README calls expensive silence, so it ships a verified token table and a real off switch through a disabled thinking value. Claude owns thinking in its auth shim and returns a 400 if the request body touches it, so the shim keeps ownership and the effort value passes through clean. Gemini's fast option was decorative because the knob is the model slug rather than a field, so fast lanes are rerouted, with a claimed measurement of first token time falling from 1.5 seconds to 0.9. DeepSeek keeps thinking in the slug rather than the body. Local models get a dedicated route that fails closed at context and recovery edges. Every row is backed by a capture kept in a wire-captures directory.

## A field that returns 200 and does nothing is treated as a bug

The repository states its rules as a short list, and each one is attributed to a real failure. The first is that evidence or it does not ship: no map lands without a wire capture. The second is the sharpest: a field that returns 200 and does nothing is worse than one that returns 400, because a 400 at least tells you the request was wrong while a 200 teaches you a control exists when it does not, so every knob has to be behaviour-proven rather than accepted. The third says silence is not cheap, since several providers think by default and a bare request spends reasoning tokens whether or not you asked.

The remaining two are infrastructure rules with the same instinct. Shared connection pools break under load, and a fresh connection per call triggers throttling, so the guidance is thread-local keep-alive or nothing. And the rule is fail-closed over fake success: if a control cannot be expressed on the wire, the no-op gets documented rather than papered over. That posture is why a probe tool exists at all, and why adding a provider means producing a capture before opening a pull request.

## Cloud hosts ignore model-bindings.json until a consumer is installed on them

The local path and the cloud path are not symmetric, and the README says so plainly. Stock cloud hosts do not read the bindings file, so a binding you saved locally is ignored until a binding consumer is installed into the host. Two scripts cover that gap: one applies the box patch, described as anchored, idempotent and backing up before it writes, and the other is the box-side file relay the picker pushes bindings to. A separate document holds the flow, named in five stages as local, push, patch, bounce and verify.

This is the part of the project with the most external exposure, and it is worth being plain about that. Patching a vendor's host to read a file it does not read is a modification of software you do not own, and the vendor can remove it in the next release without warning. The same applies in a milder form to the local bundle injection, where the project's answer is to re-inject and fail loudly rather than to ask. The documentation offers no licence argument for either, and nothing in the tree states what the target application's own terms permit.

## The accuracy numbers are trailing comments, not recorded results

The testing section prints its own score inside the command:

```bash
node tools/test-provider-maps.cjs
node tools/test-provider-maps-hop.cjs
```

In the README those two commands carry the counts 23 of 23 for the first contract and 6 of 6 for the second, written as trailing comments on the command line itself, followed by the QA script described as a leak scan, a reference integrity check and the suites. Continuous integration runs all three on every push and pull request. The two contract files are named in the architecture section: one holds direct body maps for client-side lanes, and the other exports a function for applying harness controls on hop lanes, which is the one that ships on the box.

The QA script is the part with an unusual design choice, because it is negative-control tested: plant a fake key or break a file and the check is supposed to fail loudly. The stated reason is worth repeating, that a green which cannot fail is decoration. The counts themselves are weaker evidence than they look, since they are comments the author wrote next to a command rather than output captured from a run, so the only real check is running them.

## JavaScript leads the repository and Python is the front door

The repository is filed as a JavaScript project while its entry point is a Python script, and both runtimes are genuinely needed: Python 3.9 or newer for setup, and Node 18 or newer for the picker and the maps. The top level holds a .contracts directory, a GitHub workflow directory, CONTRIBUTING.md, LICENSE, README.md, an assets directory, a box directory, docs, examples, setup.py, tools, voice and the wire-captures directory. The examples directory contains two JSON files, one named as a health snapshot sample and one as a bindings sample, which are the shapes a host integration is expected to produce.

The repository has no GitHub releases, so there is no tagged artifact to pin, and the last push to the default branch main is 2026-09-22. The README's own final heading sits unfinished: it begins with the word Coding and stops there, after the section on adding a provider. Adding a provider is otherwise fully specified, with the probe command taking a base URL, a model name and the name of the environment variable holding the key, and a contribution rule stated as no capture, no merge.

## Conclusion

Use it if you already run the Grok Bot desktop app, you hold your own provider keys, and you want to see why a foreign model feels slow rather than guessing. Do not expect it to be portable: the picker lives inside a vendor app bundle, and the cloud path needs a consumer installed on the host, which is the part most likely to fall foul of a vendor's terms and to break on the next update. Before you run it, read what it claims and what it proves apart. The header says keys never leave your machine and every wire claim is probe-verified, yet the accuracy numbers in the README are trailing comments in commands, not recorded results, and the two contract test suites are counted in comments rather than checked in CI output. Check that your provider appears in the wire table, that you accept re-injection after every update, and that a doctor baseline is something you want on the machine.

## FAQ

### What does OnlyTerp/opengrok actually do?

It is a config sidecar for an existing Grok Bot desktop install: it writes model bindings, per-provider wire maps and a health doctor next to that install, and it does not host or emulate Grok Bot or ship auth shims. In its terms a hop is simply any OpenAI-compatible base URL.

### What does OnlyTerp/opengrok need before it will run?

A working Grok Bot desktop install, Python 3.9 or newer, Node 18 or newer for the picker and the maps, and API keys for any provider you bind. Installation is a clone followed by python setup.py, which detects the install and live services, wires the configuration, runs the doctor and opens the picker.

### How does OnlyTerp/opengrok decide a reasoning switch really works?

By capturing the wire. No map lands without a capture taken with the wire probe tool, and the project's stated rule is that a field returning 200 while doing nothing is worse than one returning 400. The GLM row documents a bare request that thinks by default and a disabled value that genuinely switches it off.

### Does OnlyTerp/opengrok survive Grok Bot updates?

It is built to. The doctor baselines the machine on setup and then reports exactly what moved after an update, and the inject tool re-injects the panel anchored on stable names such as the entry document and the content security policy directive rather than the hashed bundle, failing loudly on layout drift.

### Does OnlyTerp/opengrok work with cloud Grok Bot hosts?

Not without one further step, because stock cloud hosts do not read the bindings file, so a saved binding is ignored until a binding consumer is installed on the host. The box patch tool does that and backs up first, and a separate file relay script is the box-side path the picker pushes bindings through.

## Sources

- [Issues](https://github.com/OnlyTerp/opengrok/issues)
- [License: MIT](https://github.com/OnlyTerp/opengrok/blob/main/LICENSE)
- [OnlyTerp/opengrok on GitHub](https://github.com/OnlyTerp/opengrok)
- [Project website](https://github.com/OnlyTerp/opengrok#-quick-start)
- [README](https://github.com/OnlyTerp/opengrok/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/onlyterp-opengrok