Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

RFC: System 1 decision models in a coding agent

Aperta
  • Qualcosa non va?
#124 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
22/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
ai, desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
TypeScript
Stelle
490
Fork
47
Merge medio
9h 38m
PR unite (30g)
75

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di GoDiao/dreamcoder

Tutte le issue di GoDiao/dreamcoder

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.