Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

RFC: System 1 decision models in a coding agent

オープン
  • 何か問題がありますか？
#124 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
22/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
ai, desktop

調査の方向性

This is an RFC covering decision models across the CLI and app, with yoloClassifier.ts named as the existing permission-classifier entry point and #125 as the first experiment. Read #125 and the classifier, then evaluate whether a local model can safely approve tool calls using the maintainer's sessions. Done means the measured result determines whether the later runtime, distribution, and product phases proceed.

索引モデルが issue の本文から書いたものです。

説明

enhancement rfc

Summary

System 1 decision models are small models that pick an answer from a fixed set instead of generating text. Examples: Cua-S1-Nano (~855K params), Julia-1 (144M), Laya (421M), and the hosted Jev. Each returns a probability for every option, runs locally on a CPU in milliseconds, and costs nothing per call.

A coding agent makes many small decisions of exactly this shape. Today each one is either a fixed rule or a full chat-model request. This RFC explores which of those decisions a local decision model can take, with the chat model kept as the fallback.

Why this fits DreamCoder

  • It works the same with every provider. It runs locally and does not depend on the user's provider or model. Features that are tuned to Claude today, such as the auto-mode classifier, would behave the same on DeepSeek or a local Ollama model.
  • It is fast and costs nothing per call. A decision takes milliseconds and adds no provider request, so it can run on every tool call.
  • It saves context. Picking the relevant skills or tool output keeps context small. This matters more for third-party models, which usually have smaller windows than Claude.

The pattern

Every use follows the same shape:

  1. Hard rules decide what they can.
  2. The decision model scores the options. If the top option is above a threshold, it is taken.
  3. Below the threshold, the chat model decides, or the user does.

Where a wrong decision has real cost, the decision model only takes the safe option on its own and never blocks or skips the user.

Candidate uses

Use Decision Notes
Permission guardrail Can this tool call run without asking? Phase 0. It is the highest-stakes use and the one with the clearest payoff. The CLI already has a two-stage chat-model classifier (yoloClassifier.ts, flag off) that this would sit in front of.
Skill selection Which installed skills are relevant to this turn? Related to the CLI's skill search, which today is a stub behind a flag.
Model routing Fast model or main model for this request? Builds on the per-provider fast model in #120.
Context filtering Should this tool output go into context whole, summarized, or trimmed? Large MCP and tool outputs hurt small-context models most.
Compaction timing Compact now or keep going? Today compaction triggers on a token threshold.
Computer Use actions Which UI element should be acted on next? Cua-S1 is built for this. Related to #74.

Shared concerns

  • Accuracy and calibration. Reported results are mostly from the model makers. One independent review found Laya near chance zero-shot. Every use must be measured before it ships, and fine-tuning may be needed.
  • Distribution. Model files plus a runtime are tens to hundreds of MB. They should be an optional download, not part of the installer.
  • Runtime. The models need to run inside the app, probably through ONNX in the sidecar. That choice can be made once and shared by every use.
  • Privacy. Everything runs locally. Hosted models such as Jev are out of scope by default, because sending tool calls to them would send users' commands to a third party.
  • Maturity. This class of model is about a month old, so model choices should be easy to swap.

Phases

  • Phase 0: guardrail experiment (#125). Measure whether a local decision model can safely auto-approve tool calls, using the maintainer's own sessions. No product changes. The result decides whether the rest of this RFC goes ahead.
  • Phase 1: runtime and distribution. Choose the in-app runtime and the optional model download. Shipped together with the first use that passes its evaluation.
  • Phase 2: permission guardrail in the product. Hard rules, then the decision model, then the chat-model classifier or the user, with a visible "auto-approved" marker and an off switch.
  • Phase 3 and later: other uses, one issue each, each with its own evaluation first, in whatever order the earlier phases suggest.

Open questions

  • Is one model shared across uses enough, or does each use need its own fine-tuned head?
  • Should a user be able to point at their own decision-model endpoint, in Jev's request format?

References

主要言語
TypeScript
スター
490
フォーク
47
平均マージ
9時間 38分
マージ済み PR（30日）
75

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

GoDiao/dreamcoder のほかの issue

GoDiao/dreamcoder の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。