azurewraith
Joined 6 months ago
Karma
66
Submissions
48
Member since
May 6
Recent submissions
Comment · 2 months ago
Hey all, I'm the creator of Statewright and am pretty excited about the plugin updates we've just released for Codex and Claude.
Native model switching without leaving the terminal UIs you know and love has opened a lot of doors (and saved a lot of tokens)... I'd love to answer any questions anyone has about it here!
Comment · 2 months ago
...or that one time I blew 60% of my Codex x20 weekly usage allotment in under 24 hours...
We've all had the same struggle, torn between wanting to run longer loops and maximize our current subscription quotas but not wanting to hand the keys to the kingdom over to an unrestricted OpenClaw or Hermes agent.
These tools are prominent examples of the recent long-running agent wave... Loop Engineering is not just letting an agent run until it declares itself victorious, but also properly designing an outer loop around said agent. I believe the discipline is better served with a bit more structure.
A better loop in my eyes is a sequence of bounded phases where each phase carries its own model, reasoning level, tool permissions, budget alongside escalation rules and intervention points. The agent should keep moving autonomously until the task is completed or human intervention is required.
The expensive frontier model isn't always the right call. Routine tasks like inspection, data extraction and validation can all run comfortably on less capable models... but you don't want to be around to switch them manually.
With the 0.3.0 release of Statewright (statewright.ai) you can perform Loop Engineering directly within the Claude & Codex TUIs you already love and trust. I didn't want to create another separate tool which forces me to give up my existing skills, agents and other native conveniences like Codex auto-approve, so I opted to make Loop Engineering work better in native TUIs.
At each phase boundary, Statewright can change the active model, reasoning level and token budget which is the big change here. Mixed with it's previous feature set you can assign tool permissions and other necessary guardrails to prevent your agent from running amok. It accomplishes this without requiring that you utilize separate agent shells or be at the helm injecting /model and hoping it lands at the turn boundaries you desire.
The benefits are cut and dry at the onset: leaving a frontier model active is a blunt instrument which is often overkill. In a similar time period and workload I consumed 10% of my weekly quota where the previous day I spent 60%. While testing Claude I was finally comfortable letting the agent run in YOLO mode (--dangerously-skip-permissions) with Statewright’s guardrails.
The end goal with Loop Engineering is not to make agents run forever, it's to make each additional turn intentional with the right model/reasoning, the right guarded tool access, a known token budget and a reason to continue.
Comment · 5 months ago
Three layers working together:
UserPromptSubmit hook: injects state context into every prompt... phase, available tools
Instructions: the model sees transition() and get_state() as MCP tools it can call. PreToolUse hook blocks disallowed tools at execution time and returns an error with what IS available.
PostToolUse hook: detects file changes and fires interrupts.
Things in CLAUDE.md are merely suggestions, hooks are enforcement. The model can rationalize away instructions but it can't rationalize away a blocked tool call.
The Pi plugin takes this further... pi's extension API lets us remove tools from the model's view entirely via setActiveTools() so it never even sees what it can't use. smaller tool space, better reasoning. Better Pi support is a recent enhancement and it's getting better.
Comment · 5 months ago
Here's a week 2 update. a lot shipped since this post...
OSS: The `engine` and `agent` crates are now fully open (Apache 2.0). only the `gateway` and the various plugins are FSL with a 3-year clock. You can run the full state machine locally, self-hosted, no cloud dependency. The end-to-end workflow works out of the box with ollama and any 13B+ model now.
Multi-agent support: I validated and enhanced plugins for Codex CLI, Oh-My-Codex, and Pi alongside the existing Claude Code plugin. Same gateway, same workflows, different agent frontends. the Pi plugin in particular is interesting because pi's extension API supports things Claude Code doesn't yet... programmatic model switching and per-state tool filtering where the model literally never sees disallowed tools.
Interrupts: Reactive file triggers that force state transitions. model edits a migration file? interrupt fires, pulls it into a review state. it uses the History State pattern to return where it was in the state machine after.
Fork/join: Parallel sub-agent execution. planning state dispatches N implementation branches each in their own worktree, join collects results.
Allowed_commands: Per-state bash command restrictions. testing state can run pytest but not rm -rf. enforced in the hook, not the prompt.
Tangentally, the Forge post this week (https://news.ycombinator.com/item?id=48192383) validated the same thesis from a different angle... structural guardrails on small models outperform unconstrained frontier models. three independent projects converging on "the harness is first-class infrastructure" in roughly two weeks.
Next on the agenda: per-state model routing. use a local 12B for grunt work, route to Opus/GPT-5 for the one call that matters. the cost math is trending towards ~80% reduction on a 6-phase workflow
Comment · 5 months ago
update: I released the of the crates (with the exception of the gateway as FSL) as Apache 2.0 today (and uploaded to crates.io) along with a UI piece that's Apache 2.0 as well.
You should be able to run self-hosted end-to-end with docker-compose, let me know with a GitHub issue if something isn't working in that regard
Comment · 5 months ago
Interestingly enough we have found the same net result -- structural guardrails are the unlock for smaller models. Our approach in particular layers three things: a parse rescue for malformed/incorrect tool calls (similar to your retry nudges), content-level intervention (diff size rejection, checkpoint forcing) and state machine enforcement on top (per-phase tool restriction, transition guards). On 13B models we saw completion of a selection of SWE-bench tasks went from ~20% to 100%. With frontier models we saw a reduction in API calls from reduced thrashing.
One of the most surprising findings was when a 9B model self-corrected through 4 tool parse failures within the guard rails. It tried to use a complex tool (patch_file), kept failing and eventually downshifted to a simpler tool (edit_line) that it could actually execute. The guardrails didn't make the model smarter, it just narrowed the execution space until it could find something that worked.
Comment · 5 months ago
yeah... I wanted the smaller models to behave more like their state of the art siblings and was a little shocked that it just didn't work well... so I made small models work better. Having the larger models work better was just an added benefit
Comment · 5 months ago
shipped ^_^
20+ years of full-stack engineering with stints at NVIDIA and AMD. Distinguished Engineer in ML/AI/HPC turned solo founder.
Building Statewright — state machine guardrails for AI agents.