
Recently I started working on a new course on how to use coding agents to effectively create Starknet apps and the first question that came to mind was, which tech stack should I use for teaching? For my everyday job I use Claude Code with Opus 4.8 because the Starknet Foundation (SNF) provides a subscription but it always bothered me how far removed Anthropic and other AI labs are from the values we hold dear in crypto: decentralization, transparency and self sovereignty.
With that in mind I’d like to chose an alternative AI tech stack that better aligns with crypto values while still being powerful enough to build Starknet apps.
1. Large Language Model
Open Weight models align with crypto values as you can run them locally which is an important feature of self sovereignty. The problem of course is the cost of the hardware to run those models forcing most of us to still rely on third parties for inference. This is however not too different to how crypto works where most people use RPCs hosted by third parties to interact with the blockchain before deciding to run their own nodes at home.
The question is now, how do we know which open weight model is best for coding?
1.1 Coding Performance
Artificial Analysis’ Coding Index benchmark places GLM 5.2 by Zhipu AI, DeepSeek V4 Pro by DeepSeek and Kimi K2.6 and by Moonshot AI as the leading open weight models for coding with a performance comparable to Claude Sonnet 4.6. It’s worth mentioning that Qwen 3.7 by Alibaba is not an open weight model as Qwen 3.6 was.

The benchmark above has two important omissions: Kimi K2.7 Code and Fable 5. Kimi K2.7 Code is not shown simply because Artificial Analysis hasn’t benchmarked the model yet as it is still very new. Fable 5 on the other hand was removed by me because it’s not publicly available and it’s unclear if it’ll ever be after being subject to export control by the US government.
Another popular benchmark for LLM performance is DeepSWE by Datacurve.ai which shows a much bigger gap between closed and open weight models but also suffers from being outdated not showing results for GLM 5.2 or Kimi K2.7 Code.

In this benchmark, Kimi K2.6 is the leading open weight model but with a performance closer GPT 5.4 mini. This benchmark is also surprising because it places Sonnet 4.6 much higher than Opus 4.6 when the latter is supposed to be the better model on paper.
1.2 Context Window
The context window measures how much information the model can hold in its short term memory. This is specially important for long running tasks or when working on larger codebases.
I’m adding proprietary models to the list for reference. The best point of comparison is probably Sonnet 4.6 as the leading open weight models seems to be have similar capabilities.
| Model | Open Weight | Context Window |
|---|---|---|
| Fable 5 | No | 1M tokens |
| GPT 5.5 | No | 1M tokens |
| Opus 4.8 | No | 1M tokens |
| Sonnet 4.6 | No | 1M tokens |
| DeepSeek V4 Pro | Yes | 1M tokens |
| MiMo-V2.5-Pro | Yes | 1M tokens |
| MiniMax M3 | Yes | 1M tokens |
| GLM 5.2 | Yes | 1M tokens |
| Qwen 3.7 Max | No | 1M tokens |
| Kimi K2.7 Code | Yes | 260K tokens |
| Kimi K2.6 | Yes | 260K tokens |
| GLM 5.1 | Yes | 200K tokens |
I have high confidence that the cost we see for open weight models reflects a fair price as there’s little incentive for independent infrastructure providers to subsidize the cost. I’m also using the median value instead of the average to remove outliers like the labs who created them who might have an incentive to subsidize their usage.
For proprietary models there’s no way of knowing if the current prices are “fair”, if they are heavily subsidized of if they are money making machines. This matter for long term usage as you don’t want to get stuck with a model that one day might become drastically more expensive when the subsidy ends (if they’re being subsidize).
Something worth mentioning is that even the most expensive open weight model, GLM 5.2, is less than a third of the cost of Sonnet 4.6, the cheapest of the proprietary “thinking” models, while offering similar performance according to the benchmarks.
1.4 Inference Speed
A common problem of coding with AI is that a good amount of human time is wasted waiting for the model to finish a task. If the wait is too long you might be tempted to start working on a separate feature at the cost of context switching. Ideally, your AI model should be fast enough that you wouldn’t feel the need to start working on something unrelated while you wait.
The speed of an AI model is measured by the number of tokens the LLM is able to generate per second (TPS). Another related measure is E2E latency which measures how much time elapses on average from the moment you send a request to the moment the first token appears on screen.
The table below shows stats from OpenRouter.
| Model | Open Weight | Median TPS | Best TPS | E2E Latency (seconds) |
|---|---|---|---|---|
| Opus 4.8 | No | 58 | 58 | 8.87 |
| Qwen 3.7 Max | No | 48 | 48 | 8.20 |
| GPT 5.5 | No | 41 | 41 | 14.28 |
| Sonnet 4.6 | No | 38 | 38 | 5.99 |
| DeepSeek V4 Pro | Yes | 37 | 55 | 3.98 |
| Kimi K2.7 Code | Yes | 35 | 92 | 7.97 |
| MiMo-V2.5-Pro | Yes | 29 | 42 | 14.58 |
| MiniMax M3 | Yes | 27 | 41 | 8.44 |
| GLM 5.2 | Yes | 23 | 29 | 6.02 |
The table is order by median TPS in ascending order only because it’s a better reflection of what an end user would experience using OpenRouter and this puts proprietary models up top. However, looking at the best TPS of each model we can see that some providers of open weight models have really fine tuned machines that are able to surpass the speed of Anthropic and OpenAI datacenters.
There’s also a big variance in E2E latency across models which could be due to how much a model thinks before starting to reply. GPT 5.5 and Mimo-V2.5-Pro are outliers with almost 15 seconds latency before the first token is shown on screen while DeepSeek V4 Pro is the fastest with only 4 seconds E2E latency.
2. Coding Harness
An LLM by itself can only operate as a chat box but not as a coding agent. For an LLM to be used as a coding agent it needs to be able to perform operations in your computer like creating a new file, adding code to it, compile the project, run tests, etc. A coding harness is what turns an LLM into a coding agent by providing initial instructions on how to use different tools for specific coding purposes.
The three most commonly use harnesses are Claude Code by Anthropic, Codex CLI by OpenAI and OpenCode by Anomaly. We can discard Claude Code from the get go as it’s a closed source tool which makes it incompatible with crypto’s ethos “don’t trust, verify”. On the other hand, Codex CLI and OpenCode are both open source. I suspect Codex CLI is optimized for OpenAI’s models at the expense of other models while OpenCode might be more neutral.
According to Artificial Analysis’ harness benchmark OpenCode shows better results when steering Opus 4.7 to complete a coding task than even Claude Code. This is surprising considering that Claude Code is purpose built for Anthropic’s models.

3. Inference Provider
OpenAI and Anthropic both offer great value from the their subscription but they also come with strings attached like Anthropic forbidding you from using it with any other tool that is not Claude Code like OpenClaw and OpenCode. Let’s not forget that paying $200 per month is out of reach for a lot of people around the world.
A much cheaper subscription that doesn’t come with strings attached is OpenCode Go. This subscription costs only $10 per month and gives you a decent amount of tokens per month for a variety of open weight models like GLM 5.2, Kimi K2.7 Code and DeepSeek V4 Pro.
For any additional usage beyond what the subscription offers you can use OpenCode Zen where you pay as you go using an API key. OpenCode Zen gives you access even to proprietary models like Opus 4.8 and GPT 5.5 to mix and match models based on the task at hand. OpenCode allows for a seamless integration of both subscriptions where the harness will use all the token allocation from OpenCode Go before automatically switching to OpenCode Zen for additional usage or for using proprietary models not available in Go.
But perhaps the most crypto aligned solution for inference is Venice.ai. Venice works very similar to OpenCode Zen where you get an API key that would give you access to a large catalog of AI models, open weight or proprietary, with the added benefit that you can pay with crypto and they offer models running inside TEEs for stronger privacy.
4. Conclusion
It’s clear to me that OpenCode is the superior coding harness and it’s open source. For inference provider I’m choosing Venice.ai because their strong commitment to privacy and the fact that it can be paid with crypto making it more accessible.
For LLM I’m leaning towards GLM 5.2 because benchmarks are showing it to be the most capable open weight model so far, it has a context window of 1 million tokens and it’s much cheaper than proprietary models. The only downside is its speed at only 23 to 29 tokens per second which means that a developer might end up waisting a lot of time waiting for the model to finish implementing a complex task. This could be managed by having multiple agents building different features in parallel using git worktrees.