OpenCode Go + CodeGraph: Can Cheap Models Do the Job?

Author: The Gray Cat · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: OpenCode Go + CodeGraph: Can Cheap Models Do the Job? · Channel: The Gray Cat · 09:09 · Watch on YouTube

Topics: AI agents, Task and workflow automation, AI evaluation and benchmarks, AI developer tools, AI models

Summary

The creator tested several cheaper models in OpenCode Go, comparing attempts with and without CodeGraph on a feature for automatically framing and synchronizing a face window in a video-editing app. CodeGraph’s effect varied by model: it nearly doubled Muse Spark’s token use, while DeepSeek and MiniMax used fewer tokens with it. All six completed attempts passed their automated test suites, but separate checks found a bug in every completed version, and the creator judged the results inadequate. The tests were each run only once, so the token differences need more evidence; the creator plans to fix the feature with a more capable model and recommends checking cheaper models’ work.

Key points

The task was to automatically frame the creator’s face in a rounded window, keep it stable, and synchronize it with edited footage.
OpenCode Go cost ten dollars per month for model access, but usage caps interrupted some attempts; Claude Opus 5.5 supervised and reviewed the work separately.
Muse Spark used about 69 million tokens with CodeGraph versus 35.5 million without it, an increase of about 95%.
DeepSeek V4.1 Flash used about 10% fewer tokens with CodeGraph, but its calculated cost was higher: about 51 cents versus 47 cents.
MiniMax M3.1 Flash Free used about 39% fewer tokens with CodeGraph, but its rounded-window mask was positioned incorrectly and the border did not disappear when it should.
Astra recommended the CodeGraph version of DeepSeek as the best starting point, though a simulated file replacement revealed that it still accepted an outdated face crop.
All six completed attempts passed their automated test suites, but separate checks found a bug in every completed version.
The creator ran each comparison only once and says more runs would be needed to trust the size of the token savings.
The creator dropped the rounded corners because they added manual work in Premiere and concluded that the cheaper models disappointed on this feature.

Chapters

Start	Chapter	Summary
00:00	The task and test setup	The creator introduces the CodeGraph comparison and explains the face-framing feature, OpenCode Go budget, and review process.
02:06	Limits and Muse Spark results	Usage caps disrupt several attempts, then Muse Spark’s token use nearly doubles with CodeGraph and its preview still has a visible flaw.
05:20	DeepSeek and MiniMax comparisons	DeepSeek uses fewer tokens but has a higher calculated cost with CodeGraph, while MiniMax saves tokens yet leaves problems in the rounded window.
08:05	Conclusion and lessons	Separate checks reveal bugs despite passing test suites, and the creator concludes that these cheaper models need further checking and fixing.

Quotes

So the model made a big difference in these runs. — 00:00

The logs don’t prove that CodeGraph caused those problems. — 04:49

So a passing test run was no guarantee that the feature was ready. — 08:05

I only ran each comparison once, so I’d want more runs before trusting the size of those savings. — 08:37

Cheaper models might help with simple tasks if the plan is detailed enough. — 09:09

Concepts and entities

OpenCode Go, OpenCode, CodeGraph, The Gray Cut, Claude Opus 5.5, Claude Code, Muse Spark 1.3 Contributor, DeepSeek V4.1 Flash, MiniMax M3.1 Flash Free, Astra, Kimi K3, Premiere, Codex

Full transcript (original language)

00:00 Muse Spark used almost twice the tokens with CodeGraph as it did without it in my OpenCode test. DeepSeek and MiniMax used fewer tokens with CodeGraph than without it. So the model made a big difference in these runs. In my earlier graph comparison, I asked if you’d like a test with cheaper models. You suggested Muse and DeepSeek. CodeGraph was my pick, so I tried it in OpenCode with several cheaper models.

00:30 The new subscription budget was ten dollars. I couldn’t finish every comparison before hitting the limits. I’ll show you which models used fewer tokens, and whether the code was worth keeping. The task was another feature for The Gray Cut, my video editing app. It already picks screencasts to match what I’m saying. I still add the small window showing my face by hand in Premiere.

01:01 I wanted the app to place that window automatically, with a rounded white border. The difficult part was framing the face My position sometimes shifts slightly between recordings, so the app needed to center my face. The app needed to find my face and choose how much to zoom in. Then that framing should stay steady throughout each recording. The small window also needed to follow the edited talking head footage. Speeding up a screencast should leave my face synchronized with my voice.

01:34 I also needed to keep editing the result in Premiere, with as little manual setup as possible. Okay, so OpenCode Go is the ten dollar monthly subscription I used for model access. OpenCode itself runs the coding agents. Go is an optional way to pay for the models they use. The plan was to test each model with CodeGraph and without it. Each attempt started with its own copy of the same code and the same task. Claude Opus 5.5 supervised from Claude Code.

02:06 It checked the plans and reviewed the completed code, then gave each finished attempt one chance to fix problems. The models in OpenCode wrote the code themselves. They didn’t delegate work to other agents. The ten dollars only covered OpenCode Go. Claude wasn’t included in that. But Go has usage limits for five hour periods. There are weekly and monthly caps too. Kimi K3 hit a limit during implementation.

02:37 GLM 5.3 couldn’t start coding, and Argon later hit a weekly cap. Leaving Argon overnight mostly meant waiting for resets. I eventually stopped it with the feature unfinished. Some attempts also ran at the same time. So the elapsed times wouldn’t give a fair speed comparison. The privacy terms depend on the model option. Muse and Argon Contributor allow training on your prompts and responses. I also tried the free options available during this test.

03:08 DeepSeek and MiniMax both finished attempts with and without CodeGraph. GLM Flash didn’t finish both. Next, I’ll compare the models that finished both attempts. Hitting a subscription limit doesn’t tell me whether a model can build the feature. Meta’s Muse Spark 1.3 Contributor had the biggest increase. Without CodeGraph, it used about thirty-five and a half million tokens. With CodeGraph, it used about sixty-nine million. That’s about ninety-five percent more

03:41 Most of those tokens were text the model had already seen. It could read that text again from a cache at a lower price. I counted that reused text each time, just as in my earlier comparisons. The cost calculations use the cheaper cache price. CodeGraph helps a model find related code. For example, it can show which functions call the function being changed. Muse used CodeGraph fourteen times, all while working on its plan. And that planning actually used slightly fewer tokens than planning without CodeGraph.

04:16 The extra usage came almost entirely while writing the code The reporting script counted the model responses during that phase. Without CodeGraph, there were a hundred. With CodeGraph, there were twenty-four. Each response also had more text to process on average. So there were more responses, with larger inputs. The logs show Muse repeatedly trying to fix the picture preview. It adjusted the crop and investigated why the speaker wasn’t visible.

04:49 Most of the extra usage came during implementation, including these fixes. The logs don’t prove that CodeGraph caused those problems. And the separate preview check still showed an upside down picture. The window was at the top right, although it belonged at the bottom right. Muse’s own orientation tests passed anyway. So even after all that work, its tests missed a visible problem. If these comparisons help you choose what to try, subscribe for the next one.

05:20 Join my Discord if you want to suggest another model or discuss the results. The link is in the description. DeepSeek V4.1 Flash had a different result. With CodeGraph, it used about twenty-four million tokens. Without it, almost twenty-seven million. That’s about ten percent less Planning used more tokens with CodeGraph. Most of the overall saving came when DeepSeek fixed problems after the review. That repair stage took thirty-eight recorded model responses with CodeGraph, against seventy-six without it.

05:57 CodeGraph didn’t reduce usage at every stage. Fewer tokens also didn’t mean a lower calculated cost. Using the Go rates recorded for this test, the CodeGraph attempt comes to about fifty-one cents. The attempt without it comes to about forty-seven cents. The CodeGraph attempt used more input that wasn’t cached. That costs more than reading cached text. DeepSeek was free in these runs. Those amounts show what the recorded usage would cost at those rates; they weren’t extra subscription charges.

06:30 Astra recommended the CodeGraph version as the best starting point based on the code review and separate checks. It had controls to prepare the face framing and retry when preparation failed. It also framed the sample recordings correctly during those checks. The face detection runs locally on the computer. Choosing the crop doesn’t require sending a request to an AI provider. A simulated file replacement exposed another bug. The app still accepted the old face crop.

07:02 MiniMax M3.1 Flash Free had the biggest token saving among the models that finished both attempts. With CodeGraph, MiniMax used thirty-nine percent fewer tokens That’s about sixty-four million, compared with a hundred and five million without it. Most of that saving came while writing the code. The CodeGraph attempt needed fewer model responses and processed less text per response. But a separate check found a problem with the rounded window.

07:33 The app uses a shape called a mask to hide the picture outside the rounded edges. MiniMax placed that shape completely outside the picture, so it couldn’t clip the picture correctly. The border also stayed visible when the speaker window should have disappeared. So the better token count still left problems with the feature. Both MiniMax versions ask an AI provider to choose the face framing. The separate checks didn’t test that part with a live provider.

08:05 All six completed attempts passed their automated test suites. Separate checks still found a bug in every completed version. So a passing test run was no guarantee that the feature was ready. Here’s the final comparison. Pause here if you’d like to look at the numbers. I tried the DeepSeek version with footage from my Codex Framework Arena video. The results aren’t acceptable I’ll work on it with a smarter model and make sure everything works correctly before merging it in.

08:37 For the final version, I decided to drop the rounded corners. They added too many manual steps in Premiere, and I wanted to move fast. For CodeGraph, adding the same tool gave different results with different models. It saved tokens in some attempts and nearly doubled them in Muse’s. I only ran each comparison once, so I’d want more runs before trusting the size of those savings. But for this feature, the cheaper models disappointed me. Even the version Astra recommended still needs fixing.

09:09 After a year using frontier models in Claude Code and Codex, this feels like a step backwards. I tested Kimi K3 back when it came out. The results were decent, but it was very, very slow. This time, the quota stopped it before it could finish. Cheaper models might help with simple tasks if the plan is detailed enough. I’d still check their work. For my earlier Graphify and CodeGraph comparison, watch this video