Chine

Journaux liées à cette note :

J'ai découvert l'offre "Go" de OpenCode et je compte la tester dans un projet en parallèle de Claude Pro #ai-provider, #pricing, #llm, #AI-coding-agents, #JaiDécouvert, #JaiDécidé

Je découvre l'offre "Go" de OpenCode, « Go - Modèles de code à faible coût pour tous », qui semble être sortie le 25 février 2026 : https://xcancel.com/opencode/status/2026553685468135886.

Je n'ai rien trouvé à ce sujet sur Hacker News ni chez Simon Willison.

D'après ce que je comprends, alors que l'offre OpenCode Zen propose un point d'accès et une facturation unifiés du type Pay-As-You-Go, comme OpenRouter, OpenCode Go est une offre d'abonnement à 10 dollars par mois, selon les mêmes principes que les plans d'abonnement comme Anthropic Claude Pro, Max, etc.

L'offre OpenCode Go propose un accès uniquement à 3 LLMs, tous Open Weights et tous chinois : GLM-5, Kimi K2.5 et MiniMax M2.5.

À noter toutefois que OpenCode Go n'utilise aucun AI provider basé en Chine :

Privacy : The plan is designed primarily for international users, with models hosted in the US, EU, and Singapore for stable global access.

source

Contrairement à Anthropic (voir Est-ce qu'un abonnement Claude est réellement plus économique qu'un accès direct via l'API ?), OpenCode semble être transparent sur leur offre :

Usage limits

OpenCode Go includes the following limits:

  • 5 hour limit — $12 of usage
  • Weekly limit — $30 of usage
  • Monthly limit — $60 of usage

Limits are defined in dollar value. This means your actual request count depends on the model you use. Cheaper models like MiniMax M2.5 allow for more requests, while higher-cost models like GLM-5 allow for fewer.

The table below provides an estimated request count based on typical Go usage patterns:

GLM-5 Kimi K2.5 MiniMax M2.5
requests per 5 hour 1,150 1,850 20,000
requests per week 2,880 4,630 50,000
requests per month 5,750 9,250 100,000

Estimates are based on observed average request patterns:

  • GLM-5 — 700 input, 52,000 cached, 150 output tokens per request
  • Kimi K2.5 — 870 input, 55,000 cached, 200 output tokens per request
  • MiniMax M2.5 — 300 input, 55,000 cached, 125 output tokens per request

You can track your current usage in the console.

source

Comparaison des prix au million de tokens des plans Claude Max et OpenCode Go

Si je pars des prix listés sur l'offre OpenCode Zen et les prix de Sonnet 4.6 chez Anthropic, je peux dresser le tableau suivant, prix exprimé en millions de tokens :

Model Input Output Cached Read Cached Write
MiniMax M2.5 $0.30 $1.20 $0.06 $0.375
GLM 5 $1.00 $3.20 $0.20 -
Kimi K2.5 $0.60 $3.00 $0.10 -
Sonnet 4.6 $3.00 $15.00 $0.30 $3.75

Ensuite, j'ajuste ces prix avec les réductions offertes :

  • par le plan Claude Max à $100 / mois, soit une réduction de 92,56 % ((1345 - 100) / 1345 × 100 = 92,56 %)
  • par OpenCode Go, soit une réduction de 83,33 % ((60 - 10) / 60 × 100 = 83,33 %)

Cela donne :

Model Input Output Cached Read Cached Write
MiniMax M2.5 (avec offre Go) $0.05 $0.20 $0.01 $0.06
GLM 5 (avec offre Go) $0.16 $0.53 $0.03 -
Kimi K2.5 (avec offre Go) $0.10 $0.50 $0.01 -
Sonnet 4.6 (avec offre Max) $0.22 $1.11 $0.02 $0.27

Sur la base du leaderboard SWE-bench Verified, je vais partir des hypothèses suivantes :

  • Si je considère arbitrairement que GLM-5 est équivalent à Sonnet 4.6, alors l'offre OpenCode Go est légèrement moins cher que l'offre Claude Max
  • Si je considère arbitrairement que Kimi K2.5 est équivalent à Sonnet 4.6, alors l'offre OpenCode Go est deux fois moins cher que l'offre Claude Max

#JaiDécidé de tester l'offre OpenCode Go sur un projet d'outil d'archivage à froid de conversations Mattermost en Golang que je coderai from scratch. Je compte réaliser deux versions de ce projet en parallèle : une version avec Sonnet 4.6 et l'autre avec les modèles de OpenCode Go.

J'ai découvert le modèle Open Weights GLM-5 #JaiDécouvert, #llm, #artificial-intelligence

#JaiDécouvert le modèle GLM-5 Open Weights de la société chinoise Z.ai : https://glm5.net

Analyse de Sonnet 4.6 des commentaires :

En se basant sur les retours concrets du fil, GLM-5 impressionne pour le coding agentique : cmrdporcupine rapporte un refactoring réussi dans un langage propriétaire pour seulement $1.50, avec une analyse initiale meilleure que GPT 5.3. Plusieurs utilisateurs le positionnent au niveau d'Opus 4.5 voire au-delà pour les tâches bien définies, à une fraction du coût. Le plan coding de Z.ai est cité comme une alternative crédible aux abonnements Anthropic, dont les limites d'usage dégradées poussent beaucoup à chercher ailleurs. Le scepticisme subsiste néanmoins sur le benchmaxxing — les comparaisons publiées portent sur Opus 4.5 et non sur Opus 4.6, la dernière génération.

Sonnet 4.6

Je constate que GLM-5 est mentionné / conseillé dans le README.md de Oh My OpenCode :

Even only with following subscriptions, ultrawork will work well (this project is not affiliated, this is just personal recommendation):

  • ChatGPT Subscription ($20)
  • Kimi Code Subscription ($0.99) (*only this month)
  • GLM Coding Plan ($10)
  • If you are eligible for pay-per-token, using kimi and gemini models won't cost you that much.

source

et

  • Sisyphus (claude-opus-4-6 / kimi-k2.5 / glm-5 ) is your main orchestrator. He plans, delegates to specialists, and drives tasks to completion with aggressive parallel execution. He does not stop halfway.
  • Hephaestus (gpt-5.3-codex) is your autonomous deep worker. Give him a goal, not a recipe. He explores the codebase, researches patterns, and executes end-to-end without hand-holding. The Legitimate Craftsman.
  • Prometheus (claude-opus-4-6 / kimi-k2.5 / glm-5 ) is your strategic planner. Interview mode: it questions, identifies scope, and builds a detailed plan before a single line of code is touched.

source

J'observe que GLM-5 est plutôt bien placé dans les leaderboard SWE-bench :

Je constate que GLM-5 est meilleur que Devstral 2 (Mistral) qui a un score de 61.3%.

Journal du jeudi 01 mai 2025 à 16:22 #Kubernetes, #DevOps, #JaiDécouvert

Je continue mon travail de mise à niveau en Kubernetes.

Je viens de réaliser que Helmfile ne fait pas directement partie du projet Helm. Je trouve cela surprenant. Ces deux projets sont réalisés par deux equipes différentes :

D'après ce que je comprends, si je simplifie, Helmfile est pour Helm l'équivalent de ce qu'est docker-compose.yml pour Docker.

Je m'intéresse aujourd'hui à Helmfile parce que je souhaite effectuer une tâche qui correspond au use-case numéro 2 décrit dans la documentation :

ArgoCD has support for kustomize/manifests/helm chart by itself. Why bother with Helmfile?

The reasons may vary:

  • 1. You do want to manage applications with ArgoCD, while letting Helmfile manage infrastructure-related components like Calico/Cilium/WeaveNet, Linkerd/Istio, and ArgoCD itself.
  • 2. You want to review the exact K8s manifests being applied on pull-request time, before ArgoCD syncs.
  • 3. This is often better than using a kind of HelmRelease custom resources that obfuscates exactly what manifests are being applied, which makes reviewing harder.

source

Suite à cette lecture, voici comment j'ai mis en application une partie du use-case 2.

J'ai ce helmfile.yaml :

environments:
  dev:
    values:
      - version: 6.1.0
  production:
    values:
      - version: 6.1.0
---
repositories:
  - name: open-webui
    url: https://helm.openwebui.com/
---
releases:
  - name: openwebui
    namespace: {{ .Namespace }}
    chart: open-webui/open-webui
    values:
      - ./env.d/{{ .Environment.Name }}/values.yaml
    version: {{ .Values.version }}

Et ensuite, j'ai exécuté :

$ helmfile template -e dev --output-dir-template $(pwd)/gitops/{{.Release.Name}}
Adding repo open-webui https://helm.openwebui.com/
"open-webui" has been added to your repositories

Templating release=openwebui, chart=open-webui/open-webui
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service.yaml
wrote .../gitops/openwebui/open-webui/templates/service.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/deployment.yaml
wrote .../gitops/openwebui/open-webui/templates/workload-manager.yaml
wrote .../gitops/openwebui/open-webui/templates/ingress.yaml

Cela me permet ensuite de pouvoir observer avec précision ce qui va être déployé par ArgoCD.