It was the last night of the month. I had just asked Rork for three small fixes on the settings screen of my wallpaper app, and then I opened the balance page. The fixes were light ones: a rewording, a bit of spacing, and a toggle that would not save its value. The credits that had left my balance did not match the lightness of the work.
A few days earlier the model menu had changed under me. On September 28 Claude Sonnet 5.5 took the seat Sonnet 5 used to hold, and on the 29th GPT-6.1 Sol replaced GPT-6 Sol. Together with Claude Opus 5.5, which arrived on the 22nd, that made three freshly named models in a row.
I had been choosing between them mostly by mood. Heavy-looking fix, Opus. In a hurry, Sonnet. Otherwise, GPT. Picking without a name for the picking, while only the balance kept moving, felt like worrying about the weight of my wallet without ever keeping a household ledger. So for one week I wrote down two things for every request: what kind of fix it was, and where the credits went.
Start with only what the changelog actually says
When I compare models, I try to begin with the words in the official changelog and nothing else. Benchmarks and reputations are useful, but until I have checked them against my own project they stay in the "reference" column.
| Model | Added | Effort levels | What the changelog says | Plans |
|---|---|---|---|---|
| Claude Opus 5.5 | Sep 22 | 5 (Low to Max) | 40% lower running cost than Opus 5, output more than 30% faster | Pro / Max |
| Claude Sonnet 5.5 | Sep 28 | 5 (Low to Max) | Replaces Sonnet 5. Output more than 30% faster than Sonnet 5, 1M-token context, described as strong at UI design | Pro / Max |
| GPT-6.1 Sol | Sep 29 | 3 (Low / Medium / High) | Replaces GPT-6 Sol. Capability close to GPT-6 Astra at the same price as GPT-6 Sol, 1M-token context | Pro / Max |
Laid out this way, one thing stands out. Every entry says "faster, cheaper, longer context than the model before it," and not one line says which kind of work each model is good for. That part is left to the person typing the request, and I may be missing something, but I think it has to be.
One note for readers on the free plan. All three are Pro and Max models, so if you open the menu on a free project you will see the name of the unlocking plan next to each model instead of being able to select it. That is not a glitch; it is how the menu is meant to behave.
Give the fixes three names
Reading back a week of entries, nearly everything I had asked for fell into three buckets.
The first is the rewording fix: button labels, spacing, colors, ordering. The spec is already finished in my head, and one sentence carries it across.
The second is the add-a-spec fix: a notification time window on the settings screen, a sort option on a list. I know what I want built, but I have not decided where every piece goes on the screen.
The third is the bug I cannot explain: a toggle that does not persist, a back button that restores the old value. I can describe the symptom, but I cannot yet point at where it lives.
For the first two days I did not separate these at all. Everything went to Opus 5.5 at Max effort, on the theory that a heavy tool fixes anything. It did not go well. A label change at Max came back looking exactly like the same change at Low, and all I had bought was a longer wait and a bigger deduction.
That is where I drew a line. Before I pick a model, I name the kind of fix. A fix without a name is a fix I am not ready to send.
The assignment I landed on after one week
Here is where my own ledger settled. Your project may land somewhere else, so please take this as a starting point rather than a verdict.
| Kind of fix | Model | Effort | Why |
|---|---|---|---|
| Rewording | Claude Sonnet 5.5 | Low or Medium | Fast at UI nudges and usually right the first time. Raising the effort did not change the screen |
| Add a spec | GPT-6.1 Sol | Medium | Three levels means I never stall choosing. Its layout suggestions stay modest and it rarely adds features I did not write |
| Unexplained bug | Claude Opus 5.5 | High | Given a fully written symptom, it explained where the cause lived. In my project I could not feel a difference between High and Max |
The third row has a condition attached. Before handing a mystery bug to Opus, I now write the symptom in three lines: what I tapped, what happened, what should have happened. Twice in that one week, writing those three lines showed me the cause myself, and the "bug" was demoted to a rewording fix before I spent anything on it.
Whether to keep fixing in the same thread or restore a checkpoint and rephrase is a separate decision from which model to use. I wrote about that boundary in Keep Fixing in the Same Thread, or Restore and Rephrase? What I Learned Fixing One Rork Bug Both Ways.
A ledger for where the credits go, and a tiny script to total it
Deciding the assignment in words is not enough. Without a record, a month from now I will be choosing by mood again. So I keep a ledger that costs me one line per request.
The problem I want it to solve is not "credits per request." It is how much it cost in total until the fix actually landed, broken down by kind of fix and model. A fix that took three attempts should be counted as one fix that cost three attempts.
The ledger is a CSV with seven columns.
date,model,effort,fix_type,credits,solved,note
2026-09-29,sonnet-5.5,low,rephrase,1,y,settings screen heading copy
2026-09-29,opus-5.5,max,rephrase,2,y,spacing tweak (Max was unnecessary)
2026-09-30,gpt-6.1-sol,medium,add-spec,3,y,added notification time window
2026-10-01,opus-5.5,high,bug,2,n,toggle not persisting (attempt 1)
2026-10-01,opus-5.5,high,bug,2,y,toggle not persisting (attempt 2, cause was the default value)For credits I simply read the number that dropped on the balance page after each request and copy it in. Rork keeps two balances, Build and Cloud, and I sort out which one moved using the steps in Two Balances, Not One: Reading Rork's Build Credits and Cloud Credits Apart.
Totaling is done by a short Python script that needs nothing outside the standard library.
# ledger.py - credits per solved fix, grouped by kind of fix x model
import csv
from collections import defaultdict
totals = defaultdict(lambda: {"credits": 0, "solved": 0, "asks": 0})
with open("rork_ledger.csv", newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
key = (row["fix_type"], row["model"])
totals[key]["credits"] += int(row["credits"])
totals[key]["asks"] += 1
if row["solved"].strip().lower() == "y":
totals[key]["solved"] += 1
print(f'{"fix_type":<10} {"model":<14} {"asks":>4} {"credits":>7} {"per_solved":>10}')
for (fix_type, model), t in sorted(totals.items()):
# never divide for a pair that has not solved anything; show it as-is instead
per_solved = f'{t["credits"] / t["solved"]:.1f}' if t["solved"] else "unsolved"
print(f'{fix_type:<10} {model:<14} {t["asks"]:>4} {t["credits"]:>7} {per_solved:>10}')A word on why it divides by solved fixes rather than by requests. If you look only at cost per request, three Low attempts that eventually worked look cheaper than one High attempt that worked immediately. Dividing by what actually got solved removes that illusion. The unsolved label for pairs with no successes is not only there to dodge a division by zero; I want the line to stay visible as a mark that says "stop sending this kind of fix to this model."
One more line in Rork's own FAQ helped while I kept this ledger: it states that credits are not charged for AI-side errors. When a row shows a deduction but nothing came back, that sentence is what reminds me to separate "my request was bad" from "something failed on their side."
Next week's five requests come from the ledger
Sonnet 5.5 and GPT-6.1 Sol have been in the menu for barely a week, so the assignment above is provisional. The seats changed three times in a single month. The next time they change, I would rather not rebuild a comparison table; I want to add a row with the new model's name and run the same script.
The earlier record of building the same gallery grid with Opus 5.5 and GPT-6 Sol lives in Building the Same Gallery Grid with Opus 5.5 and GPT-6 Sol in Rork — Choosing a Model by Its Effort Steps. That one is about the first screen; this one is about every fix that comes after it, which, as an indie developer maintaining a few shipped apps, is where most of my credits go.
Pick just one fix you are about to send to Rork, and before you send it, write rephrase, add-spec, or bug in the fix_type column. I have found that single word is enough to stop my hand from hovering over the model menu.