Disclaimer: This post reflects one developer’s evaluation of available tools at the time of writing. Model performance, pricing, and availability change quickly, so builders should verify current data before choosing a stack.
AI coding agents are becoming part of the developer workflow. For Starknet builders, the question is not only which model performs best.
It is which stack is powerful enough to build real applications, affordable enough to use often, and open enough to align with the values that brought many of us into crypto in the first place.
Recently, I started working on a new course on how to use coding agents to create Starknet apps. The first question was simple:
Which AI stack should we teach with?
In my day-to-day work, I use Claude Code with Opus 4.8 because the Starknet Foundation provides a subscription. It is a strong setup. But it has always bothered me how far removed many AI labs are from the values crypto builders usually care about: decentralization, transparency, privacy, and self-sovereignty.
So for this course, I wanted to evaluate an alternative stack that better fits those values while still being good enough for serious Starknet development.
This post is a snapshot of that evaluation.
Benchmarks, pricing, and model availability move quickly, so treat this as a point-in-time view of the trade-offs rather than permanent guidance.
Current recommendation
For now, the stack I am leaning toward is:
- Model: GLM 5.2
- Harness: OpenCode
- Inference provider: Venice.ai
The reasoning is straightforward.
GLM 5.2 currently looks like one of the strongest open weight coding models available. It has a large context window, performs well in coding benchmarks, and is significantly cheaper than leading proprietary thinking models.
OpenCode looks like the strongest fit for the coding harness because it is open source, model-neutral, and performs well in harness benchmarks.
Venice.ai is the most crypto-aligned inference provider in this set because it supports crypto payments and has a strong privacy focus, including support for models running inside TEEs.
That does not mean this is the only good stack. It means this is the stack that currently best balances performance, cost, openness, and crypto alignment.
1. Large Language Model
The first decision is the model.
Open weight models align well with crypto values because they can be run locally, inspected, replaced, and self-hosted over time. That matters for self-sovereignty.
The trade-off is hardware cost. Most developers are not running large coding models locally today, so they still rely on third-party inference providers. That is not too different from how most people use crypto: many users interact with blockchains through hosted RPC providers before deciding whether to run their own node.
So the practical question is: Which open weight model is good enough for coding Starknet apps?
1.1 Coding performance
Artificial Analysis’ Coding Index benchmark currently places GLM 5.2 by Zhipu AI, DeepSeek V4 Pro by DeepSeek, and Kimi K2.6 by Moonshot AI among the leading open weight models for coding, with performance that appears broadly comparable to Claude Sonnet 4.6.
There are two important caveats.
First, Kimi K2.7 Code is not included in that benchmark yet because it is still very new.
Second, Fable 5 was removed from my comparison because it is not publicly available, and its future availability is unclear.
Another popular benchmark is DeepSWE by Datacurve.ai. This benchmark shows a larger gap between closed and open weight models, but it is also missing newer models such as GLM 5.2 and Kimi K2.7 Code.
On DeepSWE, Kimi K2.6 is the leading open weight model, but its performance is closer to GPT 5.4 mini. The benchmark also places Sonnet 4.6 much higher than Opus 4.6, which is surprising given that Opus is generally positioned as the more capable model.
The takeaway is not that one benchmark should be treated as final.
The takeaway is that the strongest open weight models are now close enough to proprietary models that they are worth evaluating seriously for real developer workflows.
1.2 Context window
Context window measures how much information a model can hold in short-term memory. This matters for coding agents because long-running tasks and larger codebases require the model to read, remember, and reason across more files.
For reference, I included both open weight and proprietary models.
| 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 |
A 1 million token context window now appears to be becoming standard for newer frontier models. Kimi K2.7 Code is the main exception in this comparison, with a smaller 260K token window.
For Starknet app development, this matters. A coding agent needs to understand smart contracts, frontend code, tests, documentation, package files, and previous decisions. A larger context window gives the model more room to work before it starts losing important details.
1.3 Inference cost
Cost matters because coding agents are not something you use once. They become part of the workflow.
The table below shows the cost per million tokens for input and output, based on OpenRouter pricing at the time of writing. Input tokens are prompts, reads, searches, and other information sent to the model. Output tokens are generated code, explanations, and replies.
The table is ordered by output cost.
| Model | Open Weight | Input Cost ($/1M tokens) | Output Cost ($/1M tokens) | Providers |
|---|---|---|---|---|
| MiMo-V2.5-Pro | Yes | $0.52 | $1.04 | 3 |
| MiniMax M3 | Yes | $0.30 | $1.20 | 4 |
| DeepSeek V4 Pro | Yes | $1.64 | $3.21 | 14 |
| Kimi K2.7 Code | Yes | $0.95 | $4.00 | 10 |
| GLM 5.2 | Yes | $1.40 | $4.40 | 7 |
| Qwen 3.7 Max | No | $2.50 | $7.50 | 1 |
| Sonnet 4.6 | No | $3.00 | $15.00 | 1 |
| Opus 4.8 | No | $5.00 | $25.00 | 1 |
| GPT 5.5 | No | $10.00 | $45.00 | 1 |
This is where open weight models look especially compelling.
Even GLM 5.2, the most expensive open weight model in this table, is less than a third of the output cost of Sonnet 4.6, the cheapest proprietary thinking model listed here.
I have higher confidence that the cost of open weight model inference reflects a more competitive price. Independent infrastructure providers have less incentive to subsidize usage heavily. For proprietary models, it is harder to know whether current prices are fair, subsidized, or part of a longer-term strategy to capture market share before prices change.
That matters for developers.
You do not want to build your entire workflow around a model that becomes drastically more expensive once subsidies end or usage policies change.
1.4 Inference speed
Cost is not the only practical factor. Speed also matters.
A common problem with AI coding is the amount of human time wasted waiting for the model to complete a task. If the wait is too long, you may be tempted to start working on something else, which creates context switching and breaks flow.
Model speed is usually measured in tokens per second, or TPS. Another useful measure is end-to-end latency, which tracks how much time passes between sending a request and seeing the first token.
The table below uses OpenRouter stats.
| Model | Open Weight | Median TPS | Best TPS | E2E Latency |
|---|---|---|---|---|
| Opus 4.8 | No | 58 | 58 | 8.87s |
| Qwen 3.7 Max | No | 48 | 48 | 8.20s |
| GPT 5.5 | No | 41 | 41 | 14.28s |
| Sonnet 4.6 | No | 38 | 38 | 5.99s |
| DeepSeek V4 Pro | Yes | 37 | 55 | 3.98s |
| Kimi K2.7 Code | Yes | 35 | 92 | 7.97s |
| MiMo-V2.5-Pro | Yes | 29 | 42 | 14.58s |
| MiniMax M3 | Yes | 27 | 41 | 8.44s |
| GLM 5.2 | Yes | 23 | 29 | 6.02s |
Proprietary models look strong on median TPS. But the best TPS numbers show that some open weight model providers are already running highly optimized inference infrastructure that can compete with or exceed major proprietary providers in specific cases.
Latency also varies a lot. GPT 5.5 and MiMo-V2.5-Pro are outliers at almost 15 seconds before the first token appears. DeepSeek V4 Pro is the fastest in this table, with around 4 seconds of end-to-end latency.
The main downside of GLM 5.2 is speed. It looks strong on capability, context, and cost, but 23 to 29 tokens per second means a developer may spend more time waiting during complex implementation tasks.
That can be managed by running multiple agents in parallel using git worktrees, where each agent works on a separate feature or task. But it is still a trade-off to consider.
2. Coding harness
An LLM by itself is only a chat box.
To become a coding agent, it needs a harness: a tool that lets it interact with your computer, create and edit files, run tests, inspect errors, compile projects, and iterate on code.
The three most common coding harnesses I looked at are:
- Claude Code by Anthropic
- Codex CLI by OpenAI
- OpenCode by Anomaly
Claude Code is strong, but it is closed source. For a course trying to align with crypto values, that is a major drawback.
Codex CLI and OpenCode are both open source. My assumption is that Codex CLI is likely optimized for OpenAI models, while OpenCode appears more model-neutral.
Artificial Analysis’ harness benchmark suggests OpenCode performs very well, even outperforming Claude Code when steering Opus 4.7 through a coding task. That is notable because Claude Code is purpose-built for Anthropic models.
For this reason, OpenCode currently looks like the best fit for a Starknet AI coding course.
- It is open source.
- It is not tied to one lab.
- It works across different models.
- It fits the ethos of builders being able to inspect and replace their tools.
3. Inference provider
The final piece is inference.
OpenAI and Anthropic both offer strong value through subscriptions, but they come with trade-offs. They are closed platforms, usage is governed by their policies, and subscriptions such as $200 per month can be out of reach for many developers around the world.
A cheaper and more flexible option is OpenCode Go. It costs $10 per month and provides a token allocation across several open weight models, including GLM 5.2, Kimi K2.7 Code, and DeepSeek V4 Pro.
For additional usage, OpenCode Zen lets users pay as they go with an API key. It also provides access to proprietary models such as Opus 4.8 and GPT 5.5, which makes it possible to mix and match models depending on the task.
OpenCode can integrate both: use the token allocation from OpenCode Go first, then switch to OpenCode Zen for extra usage or for models that are not available in Go.
The more crypto-aligned option, however, is Venice.ai.
Venice works similarly to OpenCode Zen: you get an API key and access to a broad catalog of AI models. The difference is that Venice supports crypto payments and has a stronger privacy posture, including models running inside TEEs.
For a Starknet course, that matters.
It means the AI stack can reflect more of the values we want developers to think about: privacy, accessibility, optionality, and crypto-native payment rails.
4. Decision guide
There is no single perfect stack. The right choice depends on what you care about most.
| Need | Strong fit |
|---|---|
| Strong open weight coding model | GLM 5.2, DeepSeek V4 Pro, Kimi K2.7 Code |
| Lowest inference cost | MiMo-V2.5-Pro, MiniMax M3 |
| Fastest practical response | DeepSeek V4 Pro |
| Large context window | GLM 5.2, DeepSeek V4 Pro, MiMo-V2.5-Pro, MiniMax M3 |
| Open source coding harness | OpenCode |
| Crypto-aligned inference | Venice.ai |
| Maximum proprietary model capability | Opus 4.8, GPT 5.5, Sonnet 4.6 |
For the course, I care about four things:
- Performance good enough for serious Starknet development
- Low enough cost for frequent use
- Open tooling where possible
- A stack that aligns with crypto values
That points toward: GLM 5.2 + OpenCode + Venice.ai
5. Conclusion
Closed AI tools are powerful, and there is nothing wrong with using them. For many developers, they are still the easiest way to get started.
But crypto builders should care about the shape of their tooling.
If we care about self-sovereignty, transparency, privacy, and open systems, then we should at least evaluate AI stacks that move in that direction.
Open weight coding models are now strong enough to be taken seriously. Open source harnesses like OpenCode make it possible to use those models as real coding agents. Crypto-aligned inference providers like Venice.ai make the stack feel less dependent on closed subscription platforms.
For building Starknet apps with AI agents, my current recommendation is:
Use OpenCode as the harness.Use Venice.ai as the inference provider.Start with GLM 5.2 as the default model.
GLM 5.2 is not perfect. It is slower than some alternatives, and that may become annoying during larger tasks. But its combination of coding performance, context window, open weight availability, and lower cost makes it a strong default.
The broader point is more important than the specific model.
AI-assisted development is moving fast. Starknet builders should not only ask which model is most powerful today. They should ask which stack gives them capability, affordability, and control over time.
