Made entirely with Opus 5.5 + $3.21 of OpenRouter API usageClaude Code Workflow

https://www.reddit.com/r/ClaudeAI/comments/1wogab3/

Jaw literally dropped. I ran the prompt from the "Made entirely with Opus 5.5" post on my own project. Here's what Claude Code made on its own for about $4.Claude Code Workflow

https://www.reddit.com/r/ClaudeAI/comments/1wovwao/

1/ https://antigravity.google/product/antigravity-cli

Their analogy is that a VLM responds to text, like their interface model responds to clicks. There is no UI (just images), and based on your clicks the model infers your intent and adapts the "UI" in response. So, instead of inferring intent from an information-dense input (text), they do it w/ just mouse-based gestures? I would love to see how this holds up in practice.

A fun little anecdote @ 54s in the video: "It becomes whatever you ask of it. And no two interactions are ever the same."

https://github.com/microsoft/AutoSaddler

Look at the Intelligence features in the Enterprise plan:

* Per-prompt model optimization

* Caching

* A model you own, trained on your traffic

However, you'll have to gauge for yourself how closely their tasks resemble your tasks.

1/ https://cognition.com/blog/frontier-code

2/ https://cognition.com/frontiercode

So you can have a very narrow task prompt that's easy to verify (but likely too simple of a challenge). Or a more realistic task prompt that's much harder to verify. And likely harder to both build the robust verifier and run it cheaply.

https://antigravity.google/product/antigravity-cli

Here's the description of the world model prompt for the web domain: "A precise GUI state simulator — given the current screen (as HTML) and a user action, predicts the exact next screen as a complete, self-contained HTML document." (You can click the world model prompt box to expand it and see the full prompt.)

So the world model generates the current state (an html document), an agent tells it what action it wants to perform, the world model generates the next state (another html document).

The other domains are similar, but w/ domain-specific nuance.

https://code.claude.com/docs/en/goal#how-evaluation-works

> /goal is a wrapper around a session-scoped prompt-based Stop hook. Each time Claude finishes a turn, the condition and the conversation so far are sent to your configured small fast model, which defaults to Haiku. The model returns a yes-or-no decision and a short reason. A “no” tells Claude to keep working and includes the reason as guidance for the next turn. A “yes” clears the goal and records an achieved entry in the transcript.

> The evaluator runs on whichever provider your session is configured for. It does not call tools, so it can only judge what Claude has already surfaced in the conversation.

Apparently, it uses Haiku (by default) to evaluate every turn to determine if the goal has been achieved. However, it only relies on the transcript itself (including the reasoning of the main model). It can't independently verify if the goal has been achieved. So, if the main model thinks the goal is or isn't done, how often does Haiku disagree (in a productive way)? That's not clear to me.