azurewraith

8 ms·

1.
by azurewraith 1mo 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 (
2.
Autonomous Native Model Switching in Codex and Claude(statewright.ai)
5 points by azurewraith 1mo ago|1 comments
3.
Loop Engineering with native model switching in Codex and Claude(statewright.ai)
1 points by azurewraith 1mo ago|1 comments
4.
by azurewraith 1mo 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 t
5.
by azurewraith 4mo 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 t
6.
by azurewraith 4mo 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 l
7.
by azurewraith 4mo 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 dock
8.
by azurewraith 4mo 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 retr
9.
by azurewraith 4mo 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 add
10.
by azurewraith 4mo ago
shipped ^_^
11.
by azurewraith 4mo ago
Hey it's me again. Some things that didn't fit in the README or the original post -- less about features, more about where this goes. The plan/implement/test workflow is very basic and represents the most common agentic
12.
by azurewraith 4mo ago
> you might want to add an actual exclusion to the patents/licenses for those groups of people Done :) https://github.com/statewright/statewright/blob/main/PATENTS... Thank you for calling my att
13.
by azurewraith 4mo ago
I feel you on the Claude pulsing thing. Running (or trying to) run Opencode with any model I could throw at it to perform useful work like the frontier/proprietary models do (a tall order I know) is where I started. everyone makes th
14.
by azurewraith 4mo ago
the Cargo.toml covers the built Rust crates (engine, agent). the plugins/ directory has it's own LICENSE.md with the FSL terms. split license: the engine is completely open source, plugins FSL with a 3 year clock. I should make
15.
by azurewraith 4mo ago
bingo! and that's where this journey began, it's been fun proving it out ^_^
16.
by azurewraith 4mo ago
the colors are based on the event name.... green for happy path events (READY, DONE, PASS), red for failure events (FAIL, ERROR) and purple for everything else they don't indicate whether the transition is guarded or not... that is sho
17.
by azurewraith 4mo ago
you're not wrong and trimming context is legitimately the first thing that everyone should do. even with context trimming and a tight prompt the model still makes judgement calls about which tools to use and when to stop. that's
18.
by azurewraith 4mo ago
you're hitting the nail on the head... rules in prompts are suggestions the model can rationalize away. "the task is so simple that maybe I don't need worktrees" is the model overriding your intent with its own judgement
19.
by azurewraith 4mo ago
Yes, the engine handles the full workflow schema including guards. There are some aspects of runtime enforcement (env vars/command filtering, etc. exposed via the UI) that currently only live in the plugin layer but the engine parses
20.
by azurewraith 4mo ago
Nice project... the per-agent tool restriction is the same core insight (smaller tool space -> better reasoning) The main difference with Statewright is that tool access changes over time within a single agent. Planning phase gets read-
21.
by azurewraith 4mo ago
Great question... and there are two answers depending on what you were originally referring to: re: Claude Code... we actually don't filter or modify the tool list so all tools stay visible -- disallowed calls get blocked at execution
22.
by azurewraith 4mo ago
The workflow definition is intentionally simple... the enforcement layer handles the mechanics however the model gets more context than just "you're in <xyz> mode now" Each state has an `instructions` field for phase sp
23.
by azurewraith 4mo ago
I also just updated the https://statewright.ai/research page to accurately reflect the intent and mention the patent grant afforded under FSL-1.1-ALv2. Thanks again for calling my attention to this.
24.
by azurewraith 4mo ago
Mr. Claude's Opus says that this is a very feasible thing. It has better support for hooks than Cursor and full MCP support so protocol-layer blocking (like Claude) is possible. Adding to the roadmap...
25.
by azurewraith 4mo ago
You're right, and I have just corrected this. The license in the repo now uses the canonical FSL-1.1-ALv2 based on the template from fsl.software and now includes the patent grant clause. The omission wasn't intentional -- the pa
26.
by azurewraith 4mo ago
Thanks for digging deeper and I'm happy to clarify all three aspects: Re: Reproducing the results: the engine, agent crate and demo TUI are all in the repo. If you have ollama running with a 13B+ model, task run:bugfix reproduces the
27.
by azurewraith 4mo ago
agreed... the tooling layer (desktop and console) is where the leverage is right now. the models are good enough, the harness operating them (even us humans) is what's holding things back. that's the basic gist behind this whole
28.
by azurewraith 4mo ago
the LLM doesn't determine the state... it requests a transition to change the state. the engine evaluates guards (data carried along the way) to decide if the transition is valid. it (the LLM) can't skip from implementation to de
29.
by azurewraith 4mo ago
the state engine is the part that can't hallucinate. even with simple steps/prompting the review model can miss things... it's still an LLM making a judgement call at the end of the day. the state engine doesn't judge,
30.
by azurewraith 4mo ago
I feel you on how sluggish Claude Code can be, you just never know what those pulsing prompts are doing in the background... Given Statewright plugs into Claude Code, there is a little added overhead while managing the state machine logic,

More ›