Skip to main content
Glama

Oh My Laya

English | 简体中文

CI License: MIT

Oh My Laya — Reflect. Route. Refine.

One command to bring local Laya decision-making to your coding agents. Native Laya decisions for your AI agents. Integrate Laya-MLX with Codex, Claude Code, DeepSeek Harness (DSH), and pi-agent: keep simple work with the main agent, route useful subtasks within your model limits, and learn from reviewed feedback. Use it for research, analysis, planning, coding, and other agent tasks.

Oh My Laya builds on laya-mlx. It downloads and verifies Hugging Face weights, then registers the laya_tell_me tool for classification, scoring, risk routing, and yes/no decisions. Inference runs entirely on your Mac after the model is downloaded.

  • Reflect. Get structured classifications, scores, and probabilities directly from local inference—not generated text to parse.

  • Route. Pair with Alpha Squad to select necessary roles and model/reasoning combinations. Your main model stays unchanged.

  • Refine. Preserve first scores, inspect uncertain decisions, and review cases before evaluating and activating them for future advice.

Install

Apple Silicon Mac · macOS 14+ · Python 3.11+. Install your agent client first. The default multilingual weights are approximately 678 MB; inference runs locally after download.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/leo1394/oh-my-laya/master/tools/oh-my-laya.sh)"
sh -c "$(wget -qO- https://raw.githubusercontent.com/leo1394/oh-my-laya/master/tools/oh-my-laya.sh)"

# Interactive client selection
./install.sh

# Choose specific clients, or all detected clients
./install.sh --targets codex
./install.sh --targets codex,claude
./install.sh --targets all

all and both select every detected client. The installer downloads and verifies the model and installs a prebuilt workbench without requiring Rust or Node.js.

Choose y when asked Use Alpha Squad + Laya with /goal? to connect the workflow. The installer backs up and updates only the Goal section of your client's global instructions. Choose n to leave it unchanged. For unattended setup, add --goal-workflow yes or --goal-workflow no.

Restart your agent session after installation. In Codex, find Plugins → Personal → Oh My Laya and start a new task. Codex needs a CLI with plugin add support. The advisor and Squad are installed as separate Skills; existing unmanaged or locally modified Skills are preserved.

Related MCP server: local-mcp

Use It

Start with a goal

After enabling Goal integration, enter /goal and describe the result you want:

Add search to this project, cover it with tests, and review the changes.
Use Alpha Squad with Laya's structured orchestration. Check compatibility first;
keep my main model, authorization ceilings, and recording settings unchanged.
  1. Confirm your limits. Choose a recommendation policy, execution model/reasoning ceiling, and reviewer configuration. Submit Confirm and continue; saved choices are revalidated on later tasks.

  2. Decide before dividing. Clear, low-risk local work can stay with the main agent. Useful independent work gets only the necessary roles. Missing information triggers clarification—not more agents.

  3. Execute within bounds. Squad applies accepted assignments through the host, using focused context and bounded repair/upgrade attempts. Required review and execution approvals still apply.

  4. Keep the evidence. With recording authorized, save first scores as they arrive; link later test/reviewer feedback, actual model settings, and available usage without overwriting them. Review uncertain or problematic cases in the workbench.

flowchart TD
    goal["/goal + your task"] --> limits["Confirm policy and model limits"]
    limits --> assess["Local Laya: assess task and constraints"]
    assess --> plan{"Structured plan"}
    plan -->|"direct"| direct["Main agent works; no optional child"]
    plan -->|"needs_context"| clarify["Clarify missing evidence"]
    clarify --> assess
    plan -->|"delegate"| squad["Only necessary roles; authorized model / effort"]
    squad --> work["Focused context; bounded attempts; required review"]
    direct --> verify["Main agent verifies and delivers"]
    work --> verify
    work -.->|"Recording authorized"| feedback["First scores now; outcomes and usage as available"]
    direct -.->|"Recording authorized"| feedback
    feedback --> study["Human review → evaluate → explicitly activate cases"]
    study -.->|"Future advice"| assess

Loading Squad does not mean spawning a squad. direct clears optional spawn parameters. Low complexity alone does not remove a required reviewer or other explicit obligations. These are advisory controls consumed by the host, not a hard interceptor for every native agent call.

Structured orchestration is opt-in and requires compatible installed tools and the companion Skill. The agent checks support and reports fallback rather than claiming the policy ran. To disable it, ask the agent to stop structured orchestration; recorded feedback is retained. For a local build, see Development.

Execution roles include explorer, researcher, worker, and tester—only when needed. Difficult, high-risk, or uncertain reviews use the main session's model/effort; ordinary reviews use your configured reviewer. Automatic advice stays within the selected model and reasoning ceiling; tier mappings never expand authorization.

Designed to reduce wasted tokens, not promise a percentage. Avoid unnecessary delegation, repeated context, and unproductive retries. Coordination itself costs tokens; a cheaper model is not necessarily a lower-token solution. Actual savings depend on the task and quality of the outcome.

Host capabilities vary: Codex, Claude Code, and DSH need a compatible Goal implementation/profile. Pi uses a /goal prompt template, not a persistent Goal loop. Popups and subagent assignments require host support; missing capabilities are reported.

Ask Laya directly

Ask your agent:

Use Laya to classify this change as low, medium, or high risk.
Show the structured result; do not modify any files.

Tool

Purpose

laya_tell_me

Structured classification, scoring, yes/no probability, and model advice

laya_advisor_preferences

Read or change recommendation preferences

laya_feedback

Save authorized feedback, including original first scores

For session-level advice, ask: “Use $laya-model-advisor for each new task; let me choose a recommendation policy.” Choose always ask, ask for high complexity/risk/uncertainty, or automatic advice within your selected model/effort ceiling. Accepting advice does not switch the main session model or authorize execution.

Laya does not generate code. Keep decision inputs concise: the multilingual checkpoint has a total context budget of 1,024 tokens. Preserve relevant constraints when summarizing.

Try the local Snake demo:

laya --snake

Dependencies and the model path are configured during installation. Use laya --snake --help for options.

See decisions. Improve the next one.

laya dashboard

The workbench runs at http://127.0.0.1:18686. The command starts the service and pairs your browser. Use --port 18687 to choose another port; stop an existing service with laya stop before changing it.

After pairing once, you can visit or refresh that address directly—even after a service restart or upgrade. Browser trust is renewed for 30 days when you open the dashboard. A new browser, cleared cookies, or expired trust requires laya dashboard again; authorization and same-origin checks remain enabled.

Decision workbench overview with illustrative sample data

Actual workbench UI with synthetic demonstration data—not measured product savings or personal usage.

  • Overview: scenario-estimated token savings alongside recorded actual usage, model assignments, review signals, and coverage. Filter today, 7 days, 30 days, or a custom range.

  • Case study: inspect uncertain decisions and original Squad feedback, correct labels, and prepare reviewed learning cases. The Overview time range carries over.

  • Settings: configure low/medium/high model combinations, control recording, and manage backups. English and Chinese are available.

Estimates are not measured savings; incomplete usage stays marked as partial, and negative estimates remain visible. First scores are preserved alongside later corrections. Cases inform future decisions only after evaluation and explicit activation—collection is not automatic weight training.

With recording and replay enabled, completed Codex turns with verifiable Laya receipts are periodically reconciled against native main/subagent token counters. Allow up to about seven minutes after completion; ambiguous or missing evidence is not filled with zero. Inspect laya status → native_usage_sync if usage is delayed.

Update and recover

CLI reference

Use laya version (or laya --version), laya help, and laya help dashboard for command details. man laya provides the local manual. The installer includes Bash, Zsh, and Fish completion; laya completion <shell> can regenerate it.

For a user-local installation, if your shell does not load these automatically:

export MANPATH="$HOME/.local/share/man:${MANPATH:-}"
# Bash
source ~/.local/share/bash-completion/completions/laya
# Zsh: put these before running compinit in your shell configuration
fpath=(~/.local/share/zsh/site-functions $fpath)
autoload -Uz compinit && compinit

Fish loads ~/.local/share/fish/vendor_completions.d automatically when using its default XDG data directory. The installer does not edit shell startup files.

Upgrades

Rerun the installer to update; local customizations are not silently overwritten. The companion Skill comes from the repository's pinned submodule. Default installation: ~/.local/share/oh-my-laya/.

Database upgrades create a private backup. Find new migration snapshots in Settings → Backup & export. Restoring recovers that snapshot, honors privacy deletions, and saves the replaced state; it does not merge newer records or downgrade the program. Stop the service and use a compatible backup before a binary rollback.

Development

To install a local source build, build the frontend and workbench, then pass the binary to the installer. Requires Node.js and Rust locally:

(cd web && npm ci && npm run build)
cargo build --locked --release -p laya
./install.sh --targets codex --workbench-binary "$PWD/target/release/laya"

# Tests
PYTHONPATH=src python3 -m unittest discover -s tests -v
cargo test --locked -p laya
(cd web && npm test)

Licensed under the MIT License.

Available Tools

2 tools
laya_advisor_preferencesA

Read preferences, or save ONLY after the user's Confirm and continue.

always: ask on every assessment; conditional: ask only for high complexity, high risk or uncertainty; auto: accept within the user-approved ceiling. For auto, provide ceiling={model, reasoning_effort} and the host-verified, locally filtered models catalog. Auto uses only that model and at most that effort. Missing ceilings require setup; no automatic acceptance is allowed. These authorize recommendations, not actual switching or any other action. Omit policy to read. Unknown/unconfigured preferences default to asking. Optional squad={enabled: bool, reviewer: {model, reasoning_effort} or null} enables Alpha Squad's bounded spawn recommendations after explicit setup. Null reviewer uses the orchestrator; difficult reviews always use it. Omitted squad preserves its prior setting. This never authorizes task actions.

NameRequiredDescriptionDefault
squadNo
modelsNo
policyNo
ceilingNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and largely meets it: it states that these settings 'authorize recommendations, not actual switching or any other action', that missing ceilings require setup with no automatic acceptance, that omitted squad preserves prior state, and that unconfigured values default to asking. It stops short of describing permission/auth requirements or write side effects on the host.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is front-loaded, which is good, but the remainder is a dense run of telegrams ('always: ask on every assessment; conditional: ...') without structural separation, making the policy modes and ceiling rules harder to scan than they need to be. Every sentence carries information, so little is wasted, but the packaging is weak.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation. Given zero annotations, the description supplies the behavioral context needed: defaults, the recommendations-only scope, and setup prerequisites. It is close to complete, with only auth/permission framing missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and every parameter is an untyped anyOf with no field descriptions, so the description must compensate fully. It defines policy's three values (always/conditional/auto), the ceiling shape {model, reasoning_effort}, the squad shape {enabled, reviewer:{model, reasoning_effort} or null} including null-reviewer fallback, and the models catalog's role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a clear verb+resource split: read preferences, or save only after the user's Confirm and continue. That is specific enough to distinguish read vs. write behavior. It does not, however, differentiate itself from the sibling laya_tell_me, leaving that boundary implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit operational guidance is present: 'Omit policy to read', auto requires ceiling plus a verified models catalog, and unknown/unconfigured preferences default to asking. It explains within-tool conditions well but never names an alternative tool or when to reach for laya_tell_me instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

laya_tell_meA

Run a local typed decision with Laya-MLX.

Use for bounded classification, ordered scoring, and yes/no probability. Question types are choice, score, and noul. Treat results as advisory; never use them as authorization for destructive or consequential actions.

Unless advisor is provided, questions is required: an object keyed by question id. Each question requires type and instructions (use a string). choice requires criteria: a nonempty list of unique string labels or an object mapping labels to descriptions. score requires a nonempty criteria list ordered from lowest to highest. noul optionally accepts a criteria object with false/true descriptions. Use criteria, not options. Example: {"risk": {"type": "choice", "instructions": "Classify risk", "criteria": {"low": "Reversible documentation edit", "high": "Data loss"}}}.

For model advice, omit questions and pass advisor with models and current_model. Each host-verified model has id, reasoning_efforts (least to most), and an optional user-approved tier: fast, balanced, strong. No model is switched. For Alpha Squad, also pass role and verified current_reasoning_effort. Non-auto execution roles also require the confirmed session execution_choice pair; omit it for auto and reviewer routing. Returned delegation parameters are recommendations for the host's spawn call, never execution authorization. The current session is not changed.

NameRequiredDescriptionDefault
stateYes
advisorNo
questionsNo
orchestrationNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses meaningful behavior: results are advisory, no model is switched, the current session is not changed, and returned delegation parameters are only recommendations, not authorization. It omits operational traits like latency, rate limits, or error behavior, but the side-effect profile is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and question-type usage before diving into field rules and the example. It is dense and uses sentence fragments, but nearly every sentence conveys a rule the agent needs, and the example is high-value for a schema-less parameter set.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (dual-mode: questions vs advisor, 4 params at 0% schema coverage), and an output schema exists so return values need not be explained. The description covers the two primary modes well but silently omits the required 'state' param and the 'orchestration' param, so an agent cannot fully reconstruct a valid call from the documentation alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does richly for two params: it defines question types (choice/score/noul), required fields (type, instructions), criteria formats, the 'use criteria not options' rule, and an example, plus advisor fields (models, current_model, reasoning_efforts, tier, role, execution_choice). However, the required 'state' param and the 'orchestration' param are never explained at all, leaving major gaps at zero coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run a local typed decision with Laya-MLX') and enumerates the use cases (bounded classification, ordered scoring, yes/no probability). It is clear what the tool does, but it never names or contrasts the sibling laya_advisor_preferences, which handles the closely related preferences concern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use cases and a strong when-not-to-use caveat ('never use them as authorization for destructive or consequential actions'). It does not, however, route the agent to the sibling tool for preference-related needs, so the alternative-selection guidance is incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv2.0.2
    • Addedlaya_advisor_preferences
    • Changedlaya_tell_me7 fields changed
      • addedInput schema / properties / advisor
        Added value: +{
        +  "anyOf": [
        +    {
        +      "additionalProperties": true,
        +      "type": "object"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Advisor"
        +}
      • addedInput schema / properties / orchestration
        Added value: +{
        +  "anyOf": [
        +    {
        +      "additionalProperties": true,
        +      "type": "object"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Orchestration"
        +}
      • removedInput schema / properties / questions / additionalProperties
        Removed value: -{
        -  "additionalProperties": true,
        -  "type": "object"
        -}
      • addedInput schema / properties / questions / anyOf
        Added value: +[
        +  {
        +    "additionalProperties": {
        +      "additionalProperties": true,
        +      "type": "object"
        +    },
        +    "type": "object"
        +  },
        +  {
        +    "type": "null"
        +  }
        +]
      • addedInput schema / properties / questions / default
        Added value: +null
      • removedInput schema / properties / questions / type
        Removed value: -"object"
      • changedInput schema / required
        Previous value: -[
        -  "state",
        -  "questions"
        -]New value: +[
        +  "state"
        +]
  2. 1 tool updatev0.1.0
    • First observedlaya_tell_me

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation4/5

laya_tell_me runs a typed decision while laya_advisor_preferences reads/saves configuration policy, so their core purposes are distinct. The shared 'advisor' vocabulary and overlapping policy/recommendation language create minor potential confusion, but an agent can tell them apart.

Naming Consistency3/5

Both names use a consistent laya_ snake_case prefix, which is good. However the second element is inconsistent in style: laya_tell_me is an imperative verb phrase while laya_advisor_preferences is a noun phrase, breaking a predictable pattern.

Tool Count3/5

Two tools is thin for a server that apparently covers decision execution, model catalog advice, policy configuration, and squad setup. Much functionality appears overloaded into these two, which is borderline rather than comfortably scoped.

Completeness3/5

The domain (advisory decisions plus preference management) seems approximated by running decisions and configuring policy. There is no separate operation to inspect models, ceilings, or squad state independently, so several capabilities are only reachable indirectly.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables running MCP tools against local MLX models on your Mac, with hardware-aware configuration, CLI streaming, and a dashboard for routing and monitoring.
    6,484 npm
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Laya-MLX as an MCP server (and plain-HTTP API). It answers typed decisions — choose an option / score a rubric / is this true? — on your own machine (Apple Silicon / MLX), with no cloud and ~10ms after warm-up. Not a chatbot. No token-by-token text, no JSON that can break. One forward pass returns a structured answer you can branch on. Ideal for routing, triage, classification, lead scoring, and g
    MIT