coulomb/rein-openweights
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rein-openweights/INTENT.md
tegwick ac5407a83e Charter rein-openweights 
Agentic tool-use harness for current open-weight models via OpenRouter/
llm-connect, as an alternative to frontier-model-vendor harnesses
(Claude Code, Grok CLI, Codex/GPT CLI). Chartered by glas-harness
ADR-001. Local scaffold only, no Forgejo remote yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-26 12:29:06 +02:00

2.3 KiB
Raw Blame History

INTENT

Why rein-openweights exists, its boundary, and what it must never become. Established by glas-harness docs/adr/ADR-001-rein-harness-family.md.

Why it exists

Every current agent harness in the ecosystem (Claude Code, Grok CLI, Codex/GPT CLI) is a frontier-model-vendor harness: it only drives that vendor's own model. There is no way to run a current open-weight model through an equivalent agentic tool-use loop (plan → tool call → observe → repeat, with a bounded tool policy) without building one from scratch per occasion.

rein-openweights exists to be that harness: one agentic loop, model supplied via OpenRouter (through llm-connect), usable anywhere a rein-aharness-equivalent session is wanted but a frontier-vendor dependency is not — cost-sensitive workloads, offline/degraded-network tolerance, or simply comparing open-weight model capability against frontier baselines on the same task.

Governing principle

It is a rein — a concrete harness backend under glas-harness's router, implementing the same harness contract as rein-aharness (session lifecycle, tool dispatch + policy, sandbox consumption via sand-boxer, State Hub reporting). It does not reimplement any of that framework machinery itself; glas-harness owns the contract, this repo owns the open-weight-model-specific agentic loop and tool execution.

What it must never become

  • Not a model router. Choosing which OpenRouter model to use for a given task, pricing, and fallback stays in llm-connect. This repo consumes llm-connect, it does not reimplement provider routing.
  • Not a second harness framework. Session semantics, tool policy schema, sandbox consumption, and audit reporting are glas-harness's contract (GLAS-WP-0001-T01) — this repo implements it, not forks it.
  • Not a sandbox provisioner. Isolation comes from sand-boxer via glas-harness, the same as every other rein.
  • Not tenant-specific logic. Anything specific to one consumer belongs in that consumer's configuration, not hardcoded here.

Status

Charter + local scaffold only. See workplans/REIN-OW-WP-0001-bootstrap.md for the first concrete milestone (minimal tool-use loop against one OpenRouter open-weight model, same starter tool surface as rein-aharness's green-commit-only profile).