@mattshumer_ Not true they are very useful just not very useful out of the box give it web search and a couple of tools and they are very useful you are just not doing it right.
I’ve been working on authenticated remote tool execution for Echo / Adapt.
This demo shows the full flow:
• Local web search is disabled.
• Adapt discovers an allowed remote web_search tool.
• Adapt authenticates to the remote tool server.
• The server executes the search using credentials kept server-side.
• Results are returned to the local model.
• At the end, I deliberately use an invalid credential and the server rejects the connection with a 401.
The goal is to let a local AI system access useful external capabilities without giving the model direct access to the underlying API credentials.
Still building, still testing.
https://t.co/jqiKRpVQ5g
Echo Adapt is a local-first Rust runtime that lets an LLM use real tools: shell commands, persistent terminal sessions, memory, JSON functions, and now optional remote services.
The model can run under a dedicated restricted Linux user and optional Bubblewrap sandbox, so the security boundary is enforced by the OS rather than just the prompt.
I just added a standalone authenticated tool server for controlled access to things like databases, APIs, and SaaS services.
The server is optional and does not execute arbitrary tools automatically. Developers define the tools they need, the expected arguments, the downstream auth, and the translation logic.
Architecture:
LLM sends Adapt authenticated request to the
Tool Server which authenticates to Database / API / Service
Next up is per-token authorization so each client can be limited to specific tools.
https://t.co/jqiKRpVQ5g
#AI #Rust #LocalAI #LLM #OpenSource
@ronisarkar_exe I do rust I know all the rules of rust I have studied it I struggle with putting it all together from scratch so I use AI to do it then improve from there. Is that vibe coding?
I’ve been testing my 14B local model Echo inside Adapt and this is one of the more interesting sessions I’ve had with it.
I opened with nothing more than “Hello.”
From there it independently started checking who it was running as, inspecting its environment, checking workspace state, creating missing directories, reading its configuration, checking memory, and planning what it thought needed to be initialized.
I didn’t give it a workflow.
Later I told it we weren’t doing pentesting and that I wanted it to learn more office-style workflows. It immediately started planning document generation, data analysis, email management, and task automation, then began creating a workspace for that work.
I’m not claiming this proves anything philosophical about AI. What I find interesting is how proactive a 14B local model can become when the model is trained around the execution protocol and given a runtime where it can actually act on what it decides to do.
Echo is the model.
Adapt is the runtime.
Repo:
https://t.co/jqiKRpVQ5g
One design choice I made with Echo Adapt was passing tool output back to the model using the tool role instead of stuffing it into a user or assistant message.
I also added the tool role to the tokenizer/chat-template configuration of the model I trained for Adapt.
The reason is pretty simple: tool output isn't something the user said, and it isn't something the assistant said. It's information returned by the environment after the model takes an action.
I wanted the model to learn that distinction directly.
The interaction becomes user - assistant - tool - assistant.
The assistant decides to take an action, Adapt executes it, the result comes back as tool output, and the model reasons over that result on its next turn.
By including that structure during training and supporting the tool role in the model's tokenizer configuration, the model learns what tool output actually represents instead of relying on extra prompt text to explain it every time.
It's a small design decision, but I've found that keeping the roles semantically consistent makes long tool-driven workflows much cleaner.
That's one of the design choices behind Echo Adapt v5.
https://t.co/jqiKRpVQ5g
If Adapt is running as your normal user, it inherits that user's permissions. Sudo still requires normal human terminal authentication; Adapt never receives the password.
The design goal is autonomous execution with OS-level containment rather than requiring a human approval.
Giving an AI model access to your terminal is sketchy. Doing it inside a bloated Python wrapper with fake prompt sandboxing is worse.I built Echo Adapt v5—a local-first Rust runtime that gives LLMs real Linux permissions, persistent tmux sessions, semantic memory, and direct OS execution. Just pushed major updates:Native tmux session persistence (Python REPLs, debuggers, etc.) Dedicated restricted Linux user permissions (real OS defense-in-depth) Optional small-model tool output summarizer OpenAI-compatible endpoint support (llama.cpp, vLLM, Ollama) Raw Rust. Zero bloat. Link: [https://t.co/jqiKRpVQ5g](https://t.co/jqiKRpVQ5g)
For higher isolation, restricted mode runs the model as a dedicated Linux user, so the kernel/normal Linux permissions become the hard authorization boundary. d passwordless sudo is limited to commands explicitly configured by the administrator.
Adapt doesn't currently use human-in-the-loop approval boundaries for individual OS actions. The model proposes an action, Adapt applies its Rust-side safety policy, and if allowed, the action executes with the permissions of the OS user running Adapt.
@elder_plinius This world is broken when convincing AI to do things they shouldn't be doing is a goal that people actively spend time trying to do. Get a real life dude create something other than gooner videos or something or whatever it is you jailbreak these AI to do. Nobody cares.
Excited to share Echo-Instroder-v2.2, a fine-tuned model built specifically to drive local AI agent workflows and tool execution!
Trained from the ground up to pair directly with the Echo Adapt v5 framework.
📦 HF: https://t.co/dKbughWk0e⚙️ GitHub: https://t.co/jqiKRpVQ5g
Why train a dedicated model for the harness?
Zero-Monologue Execution: Synthesized from deep reasoning traces with the <think> blocks stripped. No 500-token internal deliberation—just immediate, decisive action on token 1.
Native XML Schema: Built for clean, predictable tool-calling without JSON routing overhead.
Adapt v5 provides the lightweight local agent harness/runtime, handling the session state and tool loops, while Instroder v2.2 acts as the high-throughput executive engine under the hood.
If you're running local agentic workflows and want zero-fluff tool execution, check out the weights on Hugging Face and the framework repo on GitHub! Feedback and PRs welcome.
Most local AI agent frameworks are held together by Python tape, massive system prompts, and fragile IPC pipes.I built Echo Adapt v5 in pure Rust to fix that. Here’s what makes it different:🦀 100% Rust Engine: Light static execution, sub-millisecond overhead, zero Python virtualenv bloat.📟 Persistent tmux Orchestration: Long-running CLI tools, parallel terminals, and background tasks survive agent turns.🛠️ Native Tool-Role Support: Works cleanly with local models and OpenAI-compatible APIs without hacky JSON system prompt injections.🧠 Two-Tier Summarization: Manages massive context windows without blowing up VRAM or dropping state mid-session. If you run local models, test security tools, or want a agent framework that actually handles bare-metal system tasks:🔗 https://t.co/M3Xi7nnHsD welcome. Open source and ready to test.
Well I am glad that the Grok 4.5 update is landing well for the coding community but it has serious regression in the knowledge department. Good job on the benchmarks and coding improvements. Hope it gets better moving forward. @SpaceXAI@elonmusk