GLM Plans, Fable Validates, and API Keys Are Not for Development
In my last post I compared Codex, Claude, and GLM 5.2 and landed on two $20 monthly plans as the setup that gets the work done. Two weeks in, I changed that setup: Claude moved to the $200 annual plan, which is essentially the $20 monthly plan at a discount, and Ollama moved to the $20 Pro plan. Same shape, better price. This post is a follow-up on two other fronts. First, the workflow itself has firmed up: GLM 5.2 does the assessment and planning on less critical projects, Fable 5 does the assessment on complex or mission-critical projects and validates GLM 5.2's findings, and Sonnet 5 handles general-purpose coding once Fable 5 has set the plan. Second, I ran the experiment I suspected would go badly and paid for AI by the token, once through an OpenAI API key with the GPT-5.6 Terra model and once through Ollama top-up credits. The numbers are worth sharing because the gap is not small. It is the difference between 3-4 days of work and 30 minutes.
The Workflow: Who Assesses, Who Validates, Who Implements
The pattern I described last time has settled into a repeatable loop, and it now splits by how critical the project is.
For less critical projects, I hand the assessment to GLM 5.2. It goes through the codebase and surfaces the issues, the technical debt, and the gaps it thinks need fixing. I keep it off the more critical work because of the false positive rate described below.
For complex or mission-critical work, Fable 5 does the assessment instead. It reads the codebase and produces the same kind of plan GLM 5.2 would, but the findings are more trustworthy going in, which matters more when the project cannot absorb a wrong fix. Once Fable 5 has written the plan, Sonnet 5 does the general-purpose coding to implement it. Fable 5 sets the direction, Sonnet 5 does the day-to-day typing.
Either way, the findings get captured as GitHub issues, or when the work is more of a campaign than a bug list, documented in a markdown plan checked into the repo. When GLM 5.2 produced the assessment, Fable 5 goes over the issues before anything gets implemented and validates that each one is accurate and actually worth doing.
The validation step is not optional, and I covered why in the last post: when I ran GLM 5.2 findings through Claude, roughly 40% turned out not to be real problems. That false positive rate has not gone away. GLM 5.2 is still the best tool I have for surfacing candidates on lower-stakes work, and it is still a tool whose output you cannot take at face value. Fable 5 is the filter. It commits to a clear verdict on each issue, real or not real, and the issues that survive are the ones that get implemented.
What I like about routing this through GitHub issues or a markdown plan is that the models never talk to each other directly. There is a durable, reviewable artifact in the middle. I can read the issue list myself, Fable's notes attach to something concrete, and when I come back to the project a week later the plan is still there instead of buried in a chat session.
OpenAI API Key with GPT-5.6 Terra: Wrong Tool for the Job
I tried running the GPT-5.6 Terra model through an OpenAI API key as part of the development flow, and the short version is that it is too expensive for that. Development work with an agent is token-hungry in a way that casual use is not. The model reads files, re-reads them, runs commands, loops on test output, and every one of those steps is metered. On a monthly plan that churn is absorbed by the subscription. On an API key you watch the balance drain in real time.
My takeaway is that the API key is best used for general purpose work, not typical programming. One-off questions, summarization, a script that calls the model a few times a day: that is where pay-per-token pricing makes sense, because usage is low and comes in short bursts. For a development workflow where the agent runs for hours, the typical monthly plan is simply more cost efficient than the API. The providers have effectively priced it that way, and fighting that pricing with an API key is a losing move.
The Ollama Numbers: $20 Plan vs $5 Top-Up
I saw the same thing with Ollama, and there I have concrete numbers because I ran both options back to back.
The $20 monthly plan comes with a weekly limit. On that plan, moderate to heavy use gets me 3-4 days of work before the weekly quota runs out. That is the constraint I complained about in the last post, and it is still annoying, but it is a workable rhythm: push hard for most of the week, then let the other window carry the load until the quota resets.
Then I added a $5 credit top-up to see how far pay-as-you-go credits stretch. The answer: about 30 minutes of low to medium effort. Not heavy agent work, not a big refactor, just ordinary back-and-forth, and the credits were gone in half an hour.
Do the math on that. If 30 minutes of light use costs $5, a week of moderate to heavy use at credit prices would run into the hundreds of dollars. The $20 plan delivers 3-4 days of that same heavy use for the price of two top-ups. The subscription is not a little cheaper for a development workflow; it is an order of magnitude cheaper.
Side Project: GLM 5.2 Building My Own MyFitnessPal
Separate from the cost math, I want to mention what I have been building with GLM 5.2 on a lower-stakes personal project, because it is a good example of where the false positive rate stops mattering. I am building a personal assistant app for myself, and one of my long-standing pet peeves is diet tracking. I already had basic macro and calorie counting working in the app.
After hearing my friends talk about how well image recognition works for food logging, I decided to add it. I described the feature to GLM 5.2 in a single prompt, and after a few minor adjustments I had a more or less functional image recognition flow: take a photo of a meal, get back a calorie and macro estimate. The results are surprisingly accurate for what is, under the hood, a single model call.
The image recognition itself runs on Gemini 3.5 Flash, called through my own Gemini API key. This is exactly the kind of usage I described above as the right fit for an API key instead of a monthly plan: a single call per meal logged, not an agent looping over a codebase for hours. The cost has been trivial, and the accuracy is good enough that I have genuinely stopped reaching for MyFitnessPal. I am only half joking when I call it a poor man's MyFitnessPal replacement. It does not have the food database or the social features, but for the one thing I actually wanted, a fast and accurate photo- to-macros estimate, it does the job for pennies a month.
One thing that impressed me specifically: the model was extremely accurate at recognizing authentic Russian foods without a lot of prompting. That is not a cuisine most food-logging apps or general-purpose image models handle well, since it is a narrower training case than pizza or a burger. I did not have to coach it with extra context or dish names. I pointed the camera at a plate and it identified the dish correctly.
This is also a good example of GLM 5.2 in its element. The project is not mission-critical, a wrong calorie estimate is not going to break anything, and the false positive rate that makes me route serious work through Fable 5 for validation is a non-issue here. GLM 5.2 got a working feature out in one prompt and a couple of tweaks, which is exactly the kind of fast, low-stakes iteration where its speed matters more than its accuracy.
Where That Leaves Me
The conclusion from the last post holds, and now I have the receipts for it. Two subscriptions, the Ollama $20 Pro plan and the Claude $200 annual plan, cover the development work. API keys and top-up credits are for the other stuff: automation scripts, occasional general purpose calls, anything where the usage is a trickle instead of a firehose.
If you are trying to decide how to pay for these tools, the question to ask is not which model you want but what shape your usage has. Agent-driven development is a firehose. Buy the subscription and let the provider absorb the churn. Save the API key for the work that only sips.
Comments