Try-Works

An index of projects, products, and ideas.

Projects & Products

rlm-workflow
tinytunes DJ
lurkkit
role-model
Pocketmodel

Writing

recursive-mode for coding agents
Why Chinese AI labs went open and will remain open
Coding agents and the growing 1% problem
role-model: the case for a model routing protocol

Contact

Email

My new Twitter

rlm-workflow: Recursive Language Models for coding agents

Installation
npx skills add https://github.com/doubleuuser/rlm-workflow --skill rlm-workflow

skills.sh
https://skills.sh/doubleuuser/rlm-workflow/rlm-workflow

GitHub
https://github.com/doubleuuser/rlm-workflow

Since the Recursive Language Models[0] paper demonstrated a method of increasing effective context length to 10M tokens by using sub-agents to move information from the context window to an information store outside the chat, there's been a number of different takes on how to put this into practice in development workflows. Some even go in the direction of storing entire session contexts in a database for later retrieval to preserve reasoning for changes that were made.

rlm-workflow is yet another take, this time with a slightly different angle:

Important information like requirements, codebase analysis and implementation plans should not be passed in the chat in the first place. Chat is effectively CLI and should be used for invocations and commands, not for passing information.

rlm-workflow is modelled after a regular kanban workflow from requirement to implementation plan to testing and manual QA. The workflow is sequential and phase; each phase outputs one markdown doc and takes the previous phases' docs as input. Each phase is gated on fulfilling criteria defined in the previous phase, and at the end of a phase, its output docs are locked.

The user first creates the 00-requirements.md doc in an RLM folder, then invokes the workflow in chat. It then runs until the manual QA stage, where it waits for user approval before continuing. After finishing an RLM run, the agent updates DECISIONS.md which is a ledger of requirements implemented previously, their whys and whats, and links to respective RLM docs. It also updates STATE.md, an overview of the app's current state.

To be practical, this is what your repo will look like:

rlm/00-my-first-requirements/
- 00-requirements.md (user-created)
- 01-as-is.md
- 02-to-be.md
- 03-implementation-summary.md
- 04-manual-qa.md (test cases are pre-defined; the user enters pass/fail and notes in the doc)
+ /addenda/ if needed

To summarize:
1. Specs are never passed through the chat so they do not suffer from context rot
2. Work is always done based on docs that are locked, so it cannot suffer from degradation
3. The workflow is self-documenting; it is also easily human readable; can also be used to generate information for non-technical stakeholders
4. There is no need to index the codebase a database. The rlm docs provide progressive disclosure and point the model in the right direction. Should significantly reduce token usage.
4. In my simple test, the workflow improves both quality and time to success for complex requirements

Yes, it is essentially a waterfall workflow but the agent iterates within each phase before passing. Iteration with the user happens in the QA phase, where you will normally discover edge cases etc. You can add new requirements as addenda docs or ask the agent to do so, and it will implement according to the workflow.

What about the chat sessions? Forget about them. Instructions don't matter, only outcomes.

rlm-workflow simulates a standard kanban-workflow with distinct phases like requirements, codebase analysis, implementation plan, implementation summary, verification, manual QA of implementation, and then updating of global repo artifacts (STATE.md and DECISIONS.md) to document the codebase.

The benefits of using rlm-workflow for assisted engineering includes improved traceability through workflow and global docs, reduced token usage, reduced context rot, improved accuracy and code quality, and improved speed.

[0]: https://arxiv.org/abs/2512.24601

recursive-mode for coding agents

Installation
npx skills add try-works/recursive-mode --skill '*' --full-depth

skills.sh
https://skills.sh/try-works/recursive-mode/recursive-mode

GitHub
https://github.com/try-works/recursive-mode

recursive-mode.dev
For detailed documentation

recursive-mode is a workflow for agentic engineering that I have been using daily and refining over the past four months. It starts from a simple observation: chat context is a poor medium for engineering state. It solves that problem and opens up a few new possibilities for further coding performance improvements, by using generative recursion during planning, implementation and verification. It is installable and invokable as a skill, but in practice is more like strict inner harness than an open-ended instruction like most skills are.

In a typical agentic coding session, requirements, codebase analysis, implementation plans, execution details, test output, and verification all end up in one expanding conversation. This works for smaller pieces of work but breaks down on larger tasks. As the session grows, it becomes harder to tell whether the agent is still working from the original requirements or just following the most recent context. Over time that causes drifting implementations and severe trust issues, as we can see in this Claude Code user‘s case (see further discussion on HackerNews):

‘Claude has regressed to the point it cannot be trusted to perform complex engineering.

Ignores instructions
Claims "simplest fixes" that are incorrect
Does the opposite of requested activities
Claims completion against instructions’

Thankfully, we can fix these issues by using better workflows. recursive-mode addresses them by moving the important state into repository docs and advancing work through explicit recursive phases during planning, implementation, and verification.

At a high level, recursive-mode formalizes the workflow most of us already try to follow, whether manually or through skills: define requirements, analyze the codebase, create an implementation plan, implement the plan, etc., and also adds recursion at every step.

recursive-mode is sequential and phased. Each phase takes accepted docs from earlier phases as input and produces one locked markdown doc as output. Each phase is gated on criteria defined earlier in the run. Once a phase is accepted, its output is locked. Later phases can extend or correct earlier work through addenda, but they do not silently rewrite prior state.

That constraint changes the workflow in a useful ways. It makes the run resumable. It makes the reasoning legible. It prevents later work from quietly changing the original intent. It gives verification phases something stable to verify against.

How it works
The user starts by creating a 00-requirements.md document inside a run folder, then invokes the recursive-mode skill in chat. Note that chat should be treated as a control surface for invocations and commands, never, ever as store for plans and tasks. The run then proceeds through its phases until manual QA, where it waits for user approval before continuing.

After the run is complete, the agent updates DECISIONS.md, which acts as a ledger of previously implemented requirements, including why they were made, what changed, and links to the relevant run docs. It also updates STATE.md, which provides a current overview of the application.

In practice, a repo using recursive-mode will generate this documentation per run:

.recursive/
├── /memory/ # Structured memory bank
├── RECURSIVE.md # Canonical workflow spec
├── STATE.md # Current repository state
├── DECISIONS.md # Decisions ledger
└── run/00-my-first-requirements/
├── 00-requirements.md # User-created requirement
├── 01-as-is.md # Analysis of codebase current state
├── 02-to-be.md # Implementation plan
├── 03-implementation-summary.md # What was done in practice
├── 04-test-summary.md # Automated test summary
├── 05-manual-qa.md # Test cases
└── addenda/ # Addenda docs added as needed

The specific file names are not what matters. What matters is that requirements, codebase analysis, plans, implementation summaries, verification output, and manual QA exist as durable repo artifacts instead of being left inside a volatile chat session. The worktree diffs also combine with this documentation for an even stronger trace of codebase evolution and its reasons.

This gives us a number of concrete benefits:

Specs do not suffer context rot.
The workflow documents itself. It is readable by both humans and models, and it also produces material that can be reused for summaries and stakeholder communication.
There is less no to compensate for a weak workflow by indexing large amounts of chat context into an external database. The recursive docs provide progressive disclosure and direct the model toward the right context at the right time. In practice, this should also reduce token usage compared with less structured workflows.
In my testing of the very first version of this workflow, then called rlm-workflow, both speed and code quality was significantly increased when building a new project from scratch based on a 700-line requirement. The quality improvements compound and makes you faster over time.

Factory.ai’s Missions is similar to recursive-mode in that both approaches treat long-running agentic work as something that should be broken into bounded units and driven by externalized state rather than one growing chat session. The difference is that recursive-mode is repo-native and document-first. It is open source, and it fits directly into a normal repository workflow. It installs and runs as a skill and works for pretty much any agent, IDE or CLI.

Using recursive-mode also opens up new possibilities:

Create a harness specific to your codebase by using AutoAgent or similar
https://github.com/kevinrgu/autoagent

Finetune or post-train an open model on your codebase using Embarrassingly Simple Self-Distillation https://arxiv.org/abs/2604.01193

This is enabled because by using recursive-mode you create a comprehensive data set of documentation for each change: run docs are created before, during and after planning, implementation and verification, and worktrees hold the actual code diffs.

If you found this interesting, follow me on my new Twitter :)

Coding agents and the growing 1% problem

2026-04-19

The mainstreaming of AI workflows will cause a massive hiring boom because the more AI-assisted work you do, the more work you create for yourself.

The “1% problem” with AI is that you can spend a couple of minutes, 30 minutes, or an hour and get something interesting and passable. But in order for you to really share it with other people in your organization and for you to be able to guarantee the quality of the experience, the accuracy of the data and so on, you have to put in orders of magnitude more work, 10x or 100x, than it took to get the first draft out.

To make something out of this that you could publish in your application and share with real end-users you would have to spend 100x more time and effort on it.

When you can do more with less effort you easily end up doing more and getting exhausted.

The other aspect of the 1% problem is that every feature you launch increases the complexity of your codebase, your product, and even your organization as someone will at some point be able to answer customer questions about it, market it and sell it and so on. You’ll also have to maintain it and further develop it as your codebase evolves. It’s a factor of at least 10x the effort it took to launch the first version.

If everyone builds their own agentic workspaces and workflows, adds a chatbot or AG-UI to their applications, then someone will need to maintain this. And this means new hires and why AI will result in a massive hiring boom, at least across software and likely across almost every industry though not at exactly the same time.

This also means that we need to go back to thinking before we build something because otherwise we will either end up with massive debt and increasing hiring needs, or churned users.

role-model: the case for a model routing protocol

2026-06-26

Github: https://github.com/try-works/role-model
Docs: https://role-model.dev/

Is the future of AI local, that we'll all be running models on our laptops and smartphones, or cloud, with large expert models run centrally dominating our usage? It's neither, or both, because the future is hybrid. Every day, we'll be running thousands of background processes that access an inference service at some point, totally out of sight and out of mind. These will be core processes of any application, and the number of use cases for inference processes is unbounded.

At times, workloads will be simple and latency or cost a priority, other times accuracy will be prized. In the first case, developers will be able to access a small, local model running on the users' devices that they can basically requisition for free (see Google WebLLM for which they now package a 4gb model with Chrome, and of course Apple's Foundation Models and routing in macOS 27). In the second case, a large generalist cloud model might be the best choice, but it could also be a small-ish specialist model that is preferred. These different workloads will exist within the same application, running on the same device, and the choice of models has to be blindingly fast, accurate and unobtrusive to the user. That means routing between models based on a set of factors.

My first attempt at building the foundation of this future is role-model: a model routing protocol, a router runtime, and a package for Pi that allows the agent to classify requests for more accurate routing, pi-role-model.

Routing is all about making decisions, and making decisions requires information. role-model allows for assigning models and endpoints to roles, which have a defined set of related tasks and capabilities, and then routing based on a mixed set of factors: built-in benchmark data for the model and endpoint (the same model does not perform the same across providers), declared capabilities, observed capabilities and performance, preferences for either sides of the triangle of constraints, quality-cost-speed, and of course by role and task.

Some of this data can be collected and built up over time, but in many cases some vital decision-making data is missing. Consumer applications do not classify their inference requests, for example by task or role, and inference providers do not accept requests with such classifications.

That's where the role-model router runtime comes in, and the pi-role-model package. With pi-role-model, Pi can classify the requests it send to role-model by required capabilities, role (such as researcher or coder or planner) and task (coder.review). This way, routing decisions can be made more accurate than before, provided that roles and capabilities are accurately configured.

What you'll probably realize here is that getting the role right is pretty hard, because what we're really doing right now is choosing between a group of generalist models, whether its GPT or DeepSeek or Kimi. None of them are really designed to excel at any certain thing. So as an aside, the ability to make informed and accurate routing decisions opens the door for more specialized models, and can help turn training specialized models into a real viable business. But for now, let's get back to the headline and make the case for model routing from a diverse set of perspectives.

For software developers
As a developer I would appreciate being able to call a model for simple things like semantic matching or classification, but I don't really feel like running the calculations on the ROI of this basic capability or pay for it. I'd prefer I could just use an on-device model on the devices of my users, making the feature effectively free.

I'd also prefer not to have to benchmark every potential model in existence for every possible task in my app, and also to not choose the most capable, expensive model just to defensively ensure that hallucinations don't leak back out to the user.

If I could call a router endpoint (or cloud gateway) that defines task, capabilities and modalities, and have my request routed to a suitable model based on benchmark data, observed endoint data and such, and simply consumer the return in my application, that would make my life a lot easier, and applications much more powerful.

Today, most applications that leverage inference already have some form of crude routing built in, but it is often rough and imprecise, all built on different logic and far from achieving the full benefits of intelligent model routing.

For users
Applications like Figma and Paper are adding powerful new AI-backed features but they consume a lot of tokens that are charged at a very high price. As a user, I would prefer to not just BYOK but to connect applications to my own router so that I not just provide my own inference, but a pool of models to be routed through for improved cost/performance.

I could run a Qwen 35BA3B as a local model for tool calling, instruction following and such, GPT 5.5 for really hard tasks and DeepSeek V4 for the vast quantity of middle-ground requests. This would let me cut application inference costs by probably 90%.

For inference providers
The lifespan of GPUs for serving frontier models is supposedly around three years after which they are not competitive and Nvidia will actually buy back the racks of now outdated chips from their customer datacenters.

With precise model routing we for the first time get a truly differentiated inference market across the triangle of constraints: speed, cost, and quality.

You can easily imagine, for example, next-gen models that are not bigger and better, but smaller, faster and about as capable as previous-gen models, running on older inference systems and selling for significant disounts per token vs a frontier model.

You can also have model and inference plans that clearly differentiate on quality as well, and even specialist models per domain.

For labs
Once you have a model router up and running you realize two things:1) It's hard to make routing decisions between two or more generalist models, and 2) The more differentiated the pool of models is, the easier routing decisions become, and so does the performance increase

Model routing therefore creates a market for differentiated, specialist models: one for prose, another for code, a third for research, a fourth for math and a fifth for biotech.

Specialist models will outperform generalist models on their own category of tasks, can potentially be cheaper and/or faster thanks to being smaller.

For device makers
Packaging models with laptops and smartphones will let application access near free, low latency inference and potentially offer users a better experience with the option of preserving data on-device. This is viable under the condition that tasks that do require larger expert models that run in the cloud can be routed to external models.

A side-effect of local models and what will let Apple cut upgrade cycles from ~4 years (?) down to 12-18 months is specialized hardware to run them. For almost a decade, smartphones have been trying to compete on better cameras. This coming decade will see them selling better GPUs, NPUs, ASICs and whatever other things they'll be calling the inference chips, to drive re-purchase. Every six months will see a better model on new hardware, which will enable better performance in certain applications.

How role-model makes decisions
In the ideal case, we want the consumer application that sends the requests to define the request type: what is the domain (code, prose, research, etc), what capabilities and modalities are needed, and what level of complexity is the request estimated to be at.With this information together with model and endpoint metadata that exists within the role-model router runtime we can match the request to a model based on a large range of factors like: roles assigned to models and their corresponding tasks, cost per token, observed latency, benchmark performance for different difficulty levels and so on.In an upcoming release, role-model will also use evals for previously seen requests to enrich model profiles and decision making.

Start routing with role-model
I released the role-model router runtime in an alpha version just a couple of days ago! The router is a middleware between your inference providers and your inference consumer applications and allows you to set up routing strategies based on your preferences. You can for example set up a model pool of GPT 5.5 and DeepSeek V4 Pro and connect Pi or OpenCode to the role-model endpoint (127.0.0.1:3456), set the model id to difficulty.remote-only and you're good to go. That should make your Codex quota last a lot longer.

Simply hand the Github URL or the image below to your agent and it will set it up for you.

You can also take a look at Github and implement the role-model routing protocol in your application to enable role-model to make more accurate routing decisions.

First principles of model routing

2026-07-03

Here are a few principles for model routing that I've developed while building role-model, a model router, a routing protocol and a Pi extension. These principles will be useful for anyone that uses a model router, or builds their own.

1. Keep models distinct
I sometimes see people using the latest GPT model with the latest Opus model, each assigned different roles in a coding workflow. This is not wrong per se, but it also isn't optimal from a routing perspective.

While people have different experiences of and preferences for the GPT and Opus model, they are both generalist models with a bent for coding, in the same performance and cost tiers.

This means that routing between them is difficult, because it is hard enough to determine the difficulty of a request in order to match it with a model, but after this is done it is even harder to make the decision which model it should go to when they are neck and neck in every area.

Instead of routing between two frontier models it is better to route between one frontier model and another model that excels in at least one of the sides of the triangle of constraints: speed, quality and cost.

For example, use a router together with GPT 5.5 to extend the quota of your subscription by routing medium and easy requests to DeepSeek V4 Pro. It is significantly cheaper and also significantly less capable on very difficult tasks so routing decisions are easier to make here.

2. Keep the model pool small
This point follows from the previous point. You might think that increasing the pool size with more models to route between is a good thing.

As an example, I could configure role-model to use GPT 5.5, Kimi 2.7, DeepSeek V4 Pro and DeepSeek V4 Flash, and even a couple of smaller GPT models.

But if each model does not have distinct characteristics, adding more models just makes routing decision making harder. In reality, this pool is likely to just end up routing between GPT 5.5 due to performance, and one of the other models that is selected and then kept for smaller tasks due to cache being warm.

So unless you have models with distinct differences, do not add more to the pool. Limit the pool size to 2 by default and only add more models when you can clearly define the roles of each of them. Does adding one increase speed, quality or cost? If not, don't add it.

3. Use relative, real-world benchmarks
I sometimes see some routers that simply route based on model metadata like cost, and other routers that add external benchmarks from sources like Artifical Analysis to the metadata. This is better than nothing but not ideal because the benchmarks may not provide a granular enough performance profile, may not reflect your real workloads, may not be strictly relative and may lack data for certain models.

Additionally, models perform differently on different remote endpoints, may change over time, and perform different on different local systems.

To get clear data for for the profiles of models in the pool it is best to run benchmarks in your router that runs benchmark with individual test tagged with capabilities (tool use, vision, etc), tasks or roles, then scores the model performance side by side relative to each other to build out a richer routing profile.

4. Evaluate past historic decisions to enrich routing decision data
The benchmark should only be seen as a starting point. When we route requests we aim to in a way predict the future: which model will perform optimally on this request given various parameters including cost and speed.

These decisions should be revisited by creating user-specific evaluations based on past requests and to run them as a benchmark across the model pool. This is the best signal you get on how models perform and how to route them.

Additionally, telemetry data tell us about an endpoint's stability, turn around time for a request, and other things that are not captured in catalog metadata.

If you made it all the way here, you can give model routing with your own choice of model a go with role-model. Check out the repo link in the comment below.

If you’ve made it this far, you may want to check out role-model and set up your own pool of models for routing:

https://github.com/try-works/role-model

Why Chinese AI labs went open and will remain open

2026-04-17

All across the internet there's speculation and confusion about why Chinese labs open source their models, and that they're going closed. Chinese labs will remain open, because the reason they went open to begin with is still valid.

In late September of last year, Alibaba hosted their big AI conference, ApSara. I took a look at the main video on YouTube the day after. How many views did it have? I think it didn't break 50 views in 24 hours. The same video from OpenAI or Anthropic would have had at least 100k views and probably much more.

Internet comments say that open sourcing is a national strategy, a loss maker subsidized by the government. On the contrary, it is a commercial strategy and the best strategy available in this industry.

When it comes to building global businesses, China has two unicorns: DJI and Insta360. No, not Xiaomi, not Lenovo, not Tencent. ByteDance acquired TikTok (musical.ly, with 200M users) and their attempts at building TikTok Shop have been disasters so they don't make it into this list either.

DJI and Insta360 are unicorns because they don't just make the best products in their respective industries, by far, but are also the clear category leader in the minds of consumers and are the clear go to brands for anyone considering a drone or action camera. They are trusted to have the best products on the market, and the same cannot be said for the other brands I listed.

DJI and Insta360 are successful in part because of clear technical and product vision, and in part because of focuses, professional marketing. That marketing in large part is video content on YouTube, on their owned channels and through influencers. YouTube is such an important marketing channel for any business, and especially Chinese businesses with no presence and few PR contacts abroad, because it gets them into the conversation. It is the beginning of trust-building because known personalities approve of the product.

This is how important YouTube is for Chinese brands:

Above I've talked about hardware products. What about language models? Being part of the conversation is just as important regardless of industry. When OpenAI's launch videos can get 100k+ views by default and Alibaba's get just a handful, it's clear that even a company like Alibaba has no pull outside of China. For MiniMax, Kimi, Z.ai, it is of course even harder.

So what can they do to be part of the conversation? If Qwen could only be accessed through Alibaba Cloud APIs, why would anyone bother trying it out other than for novelty when they're already satisfied with their GPTs and Claudes?

Open sourcing models the answer. That's how these labs drive thousands of conversations across YouTube, reddit, X, and eventually get in the tech media and even mainstream media, despite having had no international marketing teams whatsoever back in 2023-2024.

As a display of this importance there's even an account on Xiaohongshu tracking metrics like GLM's mentions on r/LocalLlama:

Open sourcing models is not a commercial risk because barely anyone can run them locally, few companies have the ability to manage and post-train their own models, and models lose relevance quickly. The real risk that exists is inference providers competing with the labs themselves, but that is being fixed with non-commercial licenses for models in 2026.

There are additional benefits to open source. Even Google is open sourcing their smaller models, Gemma. The benefit is building affinity between end-users and on-device models, because the future of inference isn't local or cloud, it's hybrid local and cloud. Google would love to be the preference in both cases.

We are also going to see proprietary open source models released in 2026, in the sense of models with their own memory systems and perhaps recursive capabilities. These have no standard, and every lab would prefer to be the one to define the new standards, like OpenAI and Anthropic have done with inference APIs.

Additionally, we'll also see fine-tuned and post-trained open models, sold by independent labs to both individual and corporate end users in 2026. These help set standards, too.

So in conclusion, there are many commercial benefits to open source, and as long as Chinese labs do not have strong international marketing and sales capabilities within their organizations they will keep open sourcing their models, because there is no other choice. Their business depends on giving models away for free, because open source is like PR, but real.