YoMo
A deployable framework for low-latency AI agents that invoke serverless functions.
- Source repo
- yomorun/yomo
- Stars
- ★ 1.9k
- Last updated
- 1d ago
- Primary language
- Rust
- FA score
- 39/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changes
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer adding function-backed tasks such as weather lookup to a chat application.
- Not a fit if
- Users wanting a ready-made agent without writing TypeScript tool code
- Teams needing documented production deployment and auth workflows
- Source review
- 39/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
YoMo is an open-source LLM function-calling framework for building scalable, fast AI agents. It provides a yomo serve server, yomo init project initialization, and yomo run for running tools. The server exposes POST /v1/chat/completions and the example uses Ollama with the ornith model. A running tool can also be invoked directly through POST /tool/get-weather with JSON input. The project presents TLS v1.3, serverless tool management, and geo-distributed deployment as product features.
The documented example first downloads a model with ollama pull ornith, then starts the server with yomo serve. yomo init initializes a tool project whose example instructs users to edit ./app/src/app.ts; yomo run -n get-weather ./app then runs the get-weather tool. A client sends a JSON body containing messages to http://127.0.0.1:9001/v1/chat/completions, or directly posts an escaped JSON string in args to http://127.0.0.1:9001/tool/get-weather.
- A developer adding function-backed tasks such as weather lookup to a chat application.
- An engineering team validating a tool-calling flow locally with an Ollama model.
- A backend developer whose internal HTTP client needs to send conversation requests to
/v1/chat/completions. - A team exposing a serverless
get-weatherfunction directly at/tool/get-weather. - An architect evaluating an approach that positions inference and tools nearer to end users geographically.
How do you install or deploy this agent?
Install the CLI with curl -fsSL https://get.yomo.run | sh, then verify it using yomo --version. Pull the example model with ollama pull ornith. For a source build, run cargo build --release and then ./target/release/yomo --help; this path requires Rust/Cargo. No API credential is required by the documented steps.
How do you use this agent?
Start the service with yomo serve; --config can specify a custom YAML configuration file. Run yomo init, edit ./app/src/app.ts, and start the tool with yomo run -n get-weather ./app. A first request can be made with: curl http://127.0.0.1:9001/v1/chat/completions -H "Content-Type: application/json" -d '{"messages":[{"role":"user","content":"How is the weather in London?"}]}'.
What are this agent's strengths and limitations?
- It documents both a chat endpoint,
/v1/chat/completions, and a direct tool endpoint,/tool/get-weather, enabling separate testing of agent flow and individual tools. - The CLI covers server startup, tool initialization, and tool execution, with a local Ollama-based example.
- The project explicitly identifies TLS v1.3 and geo-distributed architecture as core features.
- The supplied material demonstrates only Ollama and
ornith; configuration for other models or providers is not shown. - The complete TypeScript dependency setup, build process, and production deployment workflow for a tool project are not documented here.
- The custom YAML schema, server authentication and authorization, and error-handling behavior are not described in the supplied material.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| YoMo This agent | 39 · Major gaps | CLIFree + model costs | ★ 1.9k | 1d ago | Rust | — |
| SGR Agent Core | 50 · Major gaps | Self-hosted serviceFree + model costs | ★ 1.1k | 1mo ago | Python | OpenAI API |
| fx Coding Agent | 65 · Some gaps | CLIFree + model costs | ★ 3.8k | today | Zig | ChatGPT · Codex · OpenAI API |
| Osaurus | 76 · Good | Desktop appFree + model costs | ★ 8.1k | 1d ago | Swift | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The code binds the tool runtime to 127.0.0.1 and exposes TLS- and authentication-related modules, supporting limited conclusions about least privilege and transport protection. The packet does not explain tool permissions, user confirmation, input data flows, sensitive-data handling, external effects, or rollback. README security and performance claims lack concrete configuration or supporting evidence, and the dependency list shows no audit or mitigation process, so those criteria score low. Repository names and links provide some attribution clues, but publisher identity and maintainer responsibility remain unclear.
The README, Rust module descriptions, and TypeScript/Go bridges jointly indicate an LLM tool-routing and serverless runtime framework, but the README's sample answer contains contradictory seasonal and weather statements, weakening self-consistency. Cargo.toml lists dependencies and version constraints, but the packet does not show lockfile or availability safeguards. The bridges return some explicit errors, while Go startup and reflection errors exit silently, so failure reporting is partial.
The README addresses developers building AI agents and gives local Ollama, tool initialization, execution, and HTTP request scenarios. Modules and tool interfaces indicate support for multiple model providers, tool languages, and a distributed deployment direction; capability boundaries, limitations, and trigger conditions are not clearly stated, limiting the scores. CLI and local-service examples help establish the environment, though operating-system and deployment differences receive little guidance.
The README organizes features, setup, documentation, and development instructions; Cargo metadata and CI/release workflows add dependency, version, and publishing information. The structure is clear, though there are typos and sparse configuration guidance. Installation is a single curl command without script verification, alternatives, or troubleshooting. Examples cover the basic flow but there is no FAQ, and no known limitations are documented. Both README and Cargo metadata specify Apache-2.0, justifying full marks for license. A version number and tag-to-Cargo version check show some version discipline, but the packet has no changelog. The contribution-guidelines link offers a partial maintenance path, while specific ownership and update commitments remain unclear.
The framework provides tool initialization, execution, chat, and direct-tool-call examples, enough to show developers the basic output and how to begin. Serverless tool routing and the stated geo-distributed deployment direction offer visible value. Claims about reduced operational overhead and lower latency are not quantified or supported with evidence about costs, deployment complexity, or realized gains, so cost-benefit scores low.
CLI commands, code interfaces, dependency metadata, and CI/release configuration support some claims, but the promotional claims about TLS, major speed gains, and reliability are not fully supported by the supplied files. Multiple files corroborate the tool runtime and release workflow, but do not verify end-to-end security or example results. The README mixes assertions with examples, and the weather example itself confuses facts and inferences, so fact/inference separation scores zero.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- The README weather example contains contradictory claims about seasons, conditions, and mosquitoes; do not treat it as evidence of answer accuracy.
- The README recommends executing a remote installation script, but the packet does not describe how to verify the script or installed binary.
- The supplied material does not show tool permission controls, user confirmation, sensitive-data handling, rollback, or dependency security audits.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/yomo)<a href="https://followagents.com/en/agents/yomo"><img src="https://followagents.com/badge/yomo.svg" alt="FARS review"></a>Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
What's Changed * test(model-api): cover invalid UTF-8 frame passthrough in stream wrapper by @fanweixiao in https://github.com/yomorun/yomo/pull/1296 * feat(openai): add Responses API support with automatic routing by @woorui in https://github.com/yomorun/yomo/pull/1297 * fix(vertexai): return Gemini reasoning and clamp output tokens by @woorui in https://github.com/yomorun/yomo/pull/1298 Full Changelog: https://github.com/yomorun/yomo/compare/v2.1.6...v2.1.7View on GitHub ↗
FAQ
Do I need an API key for the example?
ornith model.Can a tool be invoked without the chat endpoint?
/tool/get-weather using an args JSON string.What is the documented default server address?
http://127.0.0.1:9001.Are other model providers supported?
Thanks — we use this to improve the page.