Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

RFC: System 1 decision models in a coding agent

Abierto
  • ¿Algo no está bien?
#124 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
22/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
ai, desktop

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
490
Forks
47
Merge medio
9 h 38 min
PR fusionados (30 d)
75

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de GoDiao/dreamcoder

Todos los issues de GoDiao/dreamcoder

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.