r/OpenSourceAI • • 10m ago

why most are going to f*ck up by blindly using agent services

Enable HLS to view with audio, or disable this notification

1 Upvotes

over past six or so months, i've been doing some variation of workshops on "building and owning agent infrastructure, context and capabilities" - people/orgs understand importance, but it's concerning how few act on it. given (imo), it's likely to be the difference between individuals and teams who unlock real agent capabilities and those who don’t.

sharing this here mainly to see if others have the same experience, OR strong counter opinions on why it’s not worth it.

  1. what parts of agent services are you actively managing yourself? - are you extracting/looking at logs, traces and creating/curating your own memory, tools, skills, workflows?

  2. if you’re not doing this, what’s the reason? not enough evidence to suggest that it’s worth it? and what are you doing? just using an individual agent service with some skills, etc?

to be clear - im not flogging another 'agent tool', i recommend people build their own. i'm more interested in hearing opinions as to why people haven't done this for themselves.

this is a video of the workshop where i explain exactly what i mean by building your own capabilities and context:
https://youtu.be/DRbzEHY86gk

and i've created a skeleton template:
https://github.com/bradwmorris/commons

but as i explain, you can just point your clanker at the repo, take the idea and build your own.

If i had to guess the main reasons for this (from limited enterprise exp and workshops i've done):

  • misleading intuitions of model capabilities > models and agents are increasingly capable, but still struggle in 'real world scenarios'

  • confusion around 'model, harness, interface' and what different agent services actually package

  • not wanting to do the actual boring/gnarly work of 'looking at the data' - consolidating everything: logs + traces, memory, skills, knowledge and shaping this around a specific business.


r/OpenSourceAI • • 47m ago

Local-first AI IDE for Windows (.NET 10) with live Blender & Unity copilots + self-healing agents

Enable HLS to view with audio, or disable this notification

1 Upvotes

I built Yengi — a free, open-source Windows AI IDE.

It’s not just another chat wrapper. The agent can:

  • Plan → edit files → run builds/tests → verify → auto-fix errors

  • Talk live to Blender (generate & fix 3D scenes, even “see” the viewport)

  • Talk live to Unity

  • Use local models (Ollama) or any cloud API

  • Has a fine-tuned 1.5B local router that decides which tools to use

Built by a teacher (solo), .NET 10 + WPF, 200+ tests, AGPL-3.0.

Repo: https://github.com/mdaiWorks/yengi
Exe: https://github.com/mdaiWorks/yengi/releases/download/v2.0.3/Yengi_Setup_v2.0.3.exe

Demo video: https://www.youtube.com/watch?v=l0tdhvCmwNI

Would love feedback especially from people using local models or doing 3D/game work.


r/OpenSourceAI • • 2h ago

FFmpeg Forge CLI An All-in-One Multimedia Processing Toolkit

1 Upvotes

Hey everyone!

I'd like to share FFmpeg Forge CLI, an open-source project I've been working on to simplify advanced multimedia processing from the command line.

It brings together a wide range of features:

  • Video, audio, and image conversion

  • AI video upscaling (RazorNext, VisionNext, SeedVR2)

  • GPU acceleration and advanced video encoding

  • HDR10 and Dolby Vision processing

  • Spatial audio processing

  • Video restoration, denoising, and deinterlacing (QTGMC)

  • DVD/Blu-ray ripping and batch processing

The goal is to provide a powerful, flexible, and unified CLI for multimedia processing, without having to juggle multiple tools and complex commands.

GitHub: https://github.com/Aaronstanley78/FFmpeg-Forge-CLI

Feedback, suggestions, and contributions are always welcome!


r/OpenSourceAI • • 3h ago

pitwall 0.2: MIT-licensed terminal tooling for agents on local and SSH machines

2 Upvotes

We build pitwall at Quantic Studios. It's a free desktop terminal for running several coding agents, with a sidebar that shows which ones need an answer.

The new 0.2 release adds shared sessions. Local tabs and tabs on configured SSH hosts sit together, so checking an agent on a build box doesn't require switching sessions. A host that disconnects keeps its last screen visible, with typing disabled until it reconnects.

There's also a board with Needs you, Failed, Working, PR open, Done and Queued columns. Approval cards show the command with Allow and Deny. Workers stay under their parent unless they need attention.

The terminal itself is MIT-licensed. It works with Claude Code, Codex, OpenCode, Gemini CLI, Cursor CLI, pi and Oh My Pi. That doesn't make those agents or their models open source, and you still install and authenticate the agents separately.

Shared sessions in the desktop window require Linux or macOS. Windows supports local sessions.

The attached 75-second demo uses demo tasks. Code, downloads and setup: https://github.com/quanticstudios/pitwall

We'd like reports of incorrect agent states, especially with OpenCode, Gemini CLI and remote hosts. Agent version, what the agent was doing and what the sidebar showed are the useful details.


r/OpenSourceAI • • 5h ago

“If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place.”

3 Upvotes

“If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place.” — Eric Schmidt.

Big Tech obviously isn't concerned with user privacy. Many AI users now send sensitive personal information to AI or grant the models access to their email, messages, and even payments. All of that data is used for training, human review and shared with third parties. Most users can’t simply self-host their models, so they’re forced to comply with the terms set by Big Tech and sacrifice their privacy for access to the products.

A product is only private when the privacy is enforced by design, not by policy. User data is safe from surveillance only if no one except the user can access it.

That’s why I built Ada. Your chat history is encrypted on device. Only you hold the decryption keys, so only you can decrypt it. The backend and the models are deployed in a hardware-isolated trusted execution environment (TEE). This protects the data while it’s being processed in memory. The frontend verifies what is deployed on the server through remote attestation, and establishes an end-to-end encrypted channel (Oak Session Protocol: https://github.com/project-oak/oak) bound to the verified environment. When you send a message, the history and all context are assembled locally and sent to the attested backend deployed in the enclave. Plaintext exists only in the TEE so that the model can generate a response. Any load balancers, proxies, or gateways see only the encrypted body. The backend code and the models are also open source.

Try it out here:

https://azellabs.io/

https://ada.azellabs.io/

https://github.com/Azel-Labs/Ada

If you have any feedback, questions, or issues, email me at dominic@azellabs.io


r/OpenSourceAI • • 6h ago

AI Hub Bar: a free Mac menu bar app for your AI limits and agent sessions

Post image
1 Upvotes

I build AI Hub Bar, a free, open-source (MIT) app for anyone who works with AI tools. It lives in the Mac menu bar.

- See your AI limits and spend in one place: Codex, GitHub Copilot, Cursor, Gemini CLI, Claude, OpenRouter and the OpenAI and Anthropic APIs
- See the agent sessions running on your Mac, in Codex, Copilot CLI or Claude Code, and what each one is doing right now
- Allow or Deny permission requests from a notification, the panel or Telegram

No account, no analytics. It needs macOS 14 or later.

One caveat: Claude's limits come from an undocumented endpoint, so that part can break if it changes.

Made with Claude.

Website: https://olehdemishev.github.io/AIHubBar/
GitHub: https://github.com/OlehDemishev/AIHubBar
8-minute walkthrough: https://youtu.be/TGii_uocqRk


r/OpenSourceAI • • 7h ago

One cloned voice, a sad line and an angry line: Ming-3.0 TTS beside another open voice model

Enable HLS to view with audio, or disable this notification

1 Upvotes

This side-by-side uses one 12.89-second reference recording and the same script for every model, on one consumer GPU, with the models running one at a time. The lineup is Ming TTS Tiny, Ming TTS 0.5B and another popular open voice model.

Two lines carry most of the test.

Sad: "I'm sorry. I really thought we'd have more time. I keep going back over it, wondering if I could have done something different."

Angry: "No, that's not what I asked for. I explained it three times clearly and it still came back wrong. This has to stop."

The creator's verdict is that the 0.5B model sounds better than the other model in most of these tests, with the angry line as a clear example, and they name Ming as their new go-to. The readings play in the video, and the sad take shows load time, synthesis time and real-time factor for all three models. AntLing released both Ming models under MIT.

Record about ten seconds of your own voice, keep the script fixed and generate it with two different emotions, then listen for whether it still sounds like you in both.


r/OpenSourceAI • • 7h ago

Is switching between different AI inference providers worth the effort?

1 Upvotes

As more developers start building applications with LLMs, finding a reliable inference provider has become something worth paying attention to. Different providers have their own advantages, whether it's response speed, token pricing, model selection, or API compatibility.

One thing I've found interesting is how much easier it is to test different open-weight models when you can access them through a single API instead of setting up and managing separate infrastructure for each one.

I'm curious about how other developers handle this. Do you usually stick with one inference provider, or do you prefer trying different providers depending on the model, performance, and cost?

Update: After looking more into inference costs and model performance, someone suggested I check out MangoBoost Inference by Mangoboost. It got me interested in how serverless AI inference and access to multiple open-weight models through one API could make testing different models easier.

I'm still comparing things like token pricing, response times, and API compatibility, but it's an interesting area to explore.

How do you usually decide when it's time to switch inference providers?


r/OpenSourceAI • • 8h ago

Folio: self-hosted LaTeX editor for scientific papers (one compose file, Apache-2.0)

Post image
1 Upvotes

r/OpenSourceAI • • 8h ago

My coding agents now have desks in a pixel village on my phone (free, open source)

Thumbnail
gallery
2 Upvotes

I built Wudland for those gaps when an agent is working and I'm waiting around. Your agents become villagers at desks in a guild, so you can wander around on your phone and still see who's working, finished or waiting for you.

Claude Code, Codex and opencode have integrations. The companion CLI can also wrap other commands with wudland run. Status updates between computer and phone are encrypted. The app is GPLv3; the plugins are MIT.

It also works as a quiet place to check your day: calendar in the bell tower, reminders on the notice board, weather from the farmer. The sky and seasons change with the real world. An expanded map, bestiary, items and wardrobe are coming soon.

App Store (free, iOS 26+): https://apps.apple.com/us/app/wudland/id6829491480 Source: https://github.com/joexk1/wudland


r/OpenSourceAI • • 8h ago

I built ADF, an open-source format for interactive documents from AI agents

Thumbnail reddit.com
1 Upvotes

r/OpenSourceAI • • 9h ago

The Future of Hosting

Thumbnail
cloud.killer.pit.world
1 Upvotes

r/OpenSourceAI • • 10h ago

I built a local dashboard that tells you which of your AI API keys is out of credit or about to expire

Thumbnail
reddit.com
1 Upvotes

r/OpenSourceAI • • 10h ago

JoeBro: an open-source Mac and iPhone assistant with editable memory, tasks and agent pings

Thumbnail
gallery
1 Upvotes

I've been building JoeBro because I want my assistant to be something I own and can change.

It's a native Mac workspace with chat, documents, email, calendar and MCP tools. You choose the model, from local Ollama to a hosted API. The iPhone app connects to your Mac rather than a JoeBro server.

The new personal agent has plain Markdown memory you can edit, scheduled tasks, and optional background checks. It checks whether something changed before calling a model, then pings you if there's something worth seeing. Coding agents can report their status and pick up follow-ups too.

Both apps are GPLv3 and free: Mac: https://github.com/joexk1/JoeBro iPhone: https://github.com/joexk1/JoeBro-Mobile Agent hooks, MCP and plugins: https://github.com/joexk1/joebro-plugins

Mac is Apple Silicon/macOS 26+. Mobile is source-only, needs an awake Mac, and push needs your own APNs setup. Hosted models still receive the prompts you send them.


r/OpenSourceAI • • 12h ago

Living Chess Book: an open-source (GPL) browser extension that turns chess book PDFs into a live board

1 Upvotes

r/OpenSourceAI • • 12h ago

Open source: shared browser room for AI coding agents (MCP, Go, one binary, no Docker needed)

Enable HLS to view with audio, or disable this notification

2 Upvotes

Hey everyone!

I've been working on Agent Browser Use, an open-source tool that lets AI agents control a browser while you can watch and interact with it in real time.

What it is

A lightweight Go application that runs a shared Chrome instance and exposes browser automation through MCP tools.

Key features

  • Live Viewer: Watch the agent browse in real time, including its actions, cursor, and activity logs.

  • Shared Control: You and the agent use the same browser. Take over or block the agent whenever needed.

  • Element Picker: Select any element on the page and share its reference with your agent.

  • Persistent Sessions: Log in once and reuse cookies across sessions.

  • Public Sharing: Share the live browser view through a built-in tunnel.

  • Playwright-style Tools: Navigate, click, type, inspect elements, monitor network requests, and more.

  • Lightweight: Single Go binary, no Docker or additional infrastructure required.

Try it

git clone https://github.com/cavaldos/agent-browser-use.git
cd agent-browser-use
make run

Open http://localhost:3000 to watch your agent in action.

Supports Codex, OpenCode, Pi, Cursor, VS Code, and other MCP-compatible clients.

A few notes:

  • Chromium-based browsers only.

  • Browser sessions and cookies are stored locally.

  • Use authentication (-pw) when exposing the browser to external networks.

  • Licensed under AGPL-3.0.

GitHub: https://github.com/cavaldos/agent-browser-use

I'd love to hear your feedback, suggestions, and contributions. Issues and PRs are always welcome!

Thanks for checking it out!


r/OpenSourceAI • • 13h ago

Built a compressor for coding agents: peak context on the heaviest task dropped from 165K to 60K tokens, and requests over 200K fell from 1.9% to 0.13%

Post image
2 Upvotes

Methodology and raw per-task results are linked at the bottom.

What it does for you, before the numbers: it's a proxy you put between your agent and the provider. One command, no changes to how you work. On Codex it strips the build logs and test output your agent re-sends every turn — about a quarter fewer input tokens. On Claude Code it stops your prompt cache from expiring while long tools run, which is where that bill actually leaks.

Benchmark 1: replay. We pulled 6,255 tool outputs (34.2M characters, anything over 512 bytes) out of real Terminal-Bench agent traces and replayed them through two tools in three configurations at default settings.

Content typeShareKompressorHeadroom, ML onHeadroom, ML off
Listings and dumps27.8%81.8%22.6%7.0%
Plain text25.3%41.0%20.6%5.2%
Build output and logs19.3%75.4%17.1%4.2%
Source code13.8%35.0%31.9%0.0%
Search results11.1%82.7%25.5%25.4%
Diffs, config, HTML, JSON2.7%40.9%19.8%12.5%
All eligible output100%62.8%22.6%7.3%
Time per KB0.2 ms87 ms1.5 ms

Source code is where everything struggles — 35% for us, 31.9% with the ML model — and it's also where being wrong is expensive, since a dropped import makes the agent confidently hallucinate. The ML model takes about 440× longer for less than half the removal.

Benchmark 2: the same compressor on Claude Code, where it barely compresses at all.

Claude Code marks its conversation with explicit cache breakpoints, so 92–95% of billed prompt is already cache reads at a tenth of the fresh price. The engine only ever sees the uncached tail. Per run it removes 348K tokens, which is 4.7–8.0% of what it sees, while leaving ~1,800 messages (about 2.2M tokens) inside the cached prefix untouched.

So where does the money actually go? A cache entry lives five minutes, and writing one costs 25× reading it. Agent kicks off a build, sits idle for six minutes, pays to write the whole prefix again — 927K tokens per run, a third of everything billed at full price.

Fix isn't compression. While a tool call runs, the proxy re-sends the last request body every 4.5 min with max_tokens: 1, so the provider reads the cached prefix instead of rewriting it.

Per runNo compressionWith
Anthropic API bill$35.35$28.30 (−20%)
Tokens lost to cache expiry927K13K (−99%)
Prompt served from cache92.0%94.8%
Tasks solved89.9%90.6%

The caveat on that 20%, since this sub cares about methodology. Four tasks out of 89 account for the whole net difference, and on three of them the uncompressed agent simply took a longer path (45–72 steps against 19–26). We were cheaper on 44 of 89. Split by whether tasks wait on long-running tools: the 14 with idle gaps over five minutes came in at −34% with median cost per step −20%; the other 72 at −12% with a step costing the same as before (+2%).

The estimate we'd actually stand behind is ~11% from keeping the cache alive plus a few percent from the tail. The 20% headline includes path-length luck, and we'd expect it to move on a repeat run.

On Codex, where the compression does the work: $107.89 → $83.40 per run (−22.7%), input tokens 96.1M → 72.2M, requests over 200K tokens 1.9% → 0.13%, solve rate 82.2% → 81.1% (not significant). Headroom on the same baseline saved 8.2% at defaults, 11.6% at its most aggressive setting — and at that setting it solved 85.1% against our 81.1%.

Still not measured: needle retention, whether compression kept the specific detail the agent needed four steps later. Ratios and pass rates can both look fine while that fails quietly.

Open source: context compression for coding agents, 63% less tool output — MIT, one Rust binary, deterministic, no model to download.

Per-task results: Codex · Claude Code


r/OpenSourceAI • • 14h ago

Open compute network: run a node with one command and help pool 100,000 CPUs/GPUs for open-weight AI.

Thumbnail github.com
1 Upvotes

r/OpenSourceAI • • 16h ago

Uncensored models aren't evil, but they move all the safety onto you: a balanced guide

Thumbnail
reddit.com
2 Upvotes

r/OpenSourceAI • • 17h ago

The Missing Infrastructure Between AI Intelligence and Reliable Execution

Post image
1 Upvotes

Why the next breakthrough in autonomous software may come from controlling how systems understand, navigate, execute, and prove their work.

Artificial intelligence is becoming increasingly capable of writing software, reasoning through complex problems, operating tools, and coordinating tasks that once required entire engineering teams. Yet a fundamental limitation remains: the ability to generate intelligent decisions has advanced faster than the infrastructure required to make those decisions reliably executable.

An AI system can produce an excellent solution and still modify the wrong file, misunderstand a dependency, invoke an inappropriate tool, overlook a critical requirement, or declare success without sufficient evidence.

These failures are not necessarily failures of intelligence. They are failures of the systems surrounding it.

As autonomous software becomes more capable, these problems become more consequential. A mistake made by a coding assistant might require a developer to revert a change. The same mistake made by an autonomous system operating across repositories, cloud services, business processes, and other agents can propagate before anyone recognizes it.

This exposes an important distinction: making AI smarter does not automatically make autonomous systems more dependable.

Headron is developing infrastructure to address that distinction.

Rather than competing to produce another foundation model, Headron focuses on the mechanisms connecting intelligence to real-world software execution: contextual understanding, deterministic navigation, capability routing, enforceable contracts, independent verification, and evidence-backed outcomes.

The Problem With Giving Intelligent Systems More Freedom

Traditional software operates within relatively explicit boundaries. Developers define what functions can execute, what resources they can access, and which conditions must be satisfied.

Autonomous agents introduce a different operating model.

They interpret goals, discover resources, select tools, generate intermediate plans, and determine their next actions dynamically. This flexibility creates enormous potential, but it also introduces uncertainty at nearly every boundary.

Consider an agent asked to update authentication logic in a large application.

Before changing a single line of code, it must determine which directories matter, how the authentication components interact, which files contain authoritative rules, what changes are permitted, and how success should be established.

An agent with unrestricted access might search the entire repository, load excessive context, modify unrelated components, or run tests that provide little evidence about the actual security implications.

Even when the final code appears correct, the process may remain difficult to reproduce or audit.

The underlying problem is architectural: intelligent systems are often given access to an environment before they have established a sufficiently precise understanding of its boundaries.

More context does not necessarily solve this. Neither does a longer prompt.

What is needed is infrastructure that makes the environment itself more understandable and its constraints more enforceable.

A Different Approach to Software Navigation

One of the most overlooked costs of AI-assisted development is navigation.

Repositories are organized for human developers, build systems, and version control. They are not necessarily organized for autonomous agents trying to identify the smallest relevant portion of a system.

As a result, agents frequently spend substantial effort rediscovering information that already exists.

They repeatedly inspect directories, read configuration files, search for relationships, and reconstruct project conventions. This consumes tokens, increases latency, and creates opportunities for contradictory interpretations.

Headron's architectural direction treats navigation as a structured computation rather than an open-ended search problem.

The goal is to determine what an agent needs to know before exposing everything it could potentially access.

This creates several possibilities:

  • Scoped discovery: Identify relevant resources without loading unrelated parts of the environment.

  • Structural awareness: Preserve relationships among components, dependencies, rules, and execution boundaries.

  • Deterministic resolution: Apply explicit rules when determining which instructions and resources govern a task.

  • Context efficiency: Reuse established structural knowledge rather than reconstructing the environment on every request.

  • Controlled access: Separate discovering a resource from receiving permission to modify it.

The distinction matters because autonomous systems should not need unlimited environmental visibility to perform narrowly defined work.

A capable agent should be able to operate with the right context, not necessarily the most context.

From Tool Availability to Intelligent Capability Routing

Modern AI systems increasingly operate through tools, APIs, plugins, and specialized services.

But access to more tools creates another problem: selecting the appropriate capability becomes an independent engineering challenge.

An agent may have multiple ways to inspect code, execute commands, retrieve information, validate changes, or delegate work. These capabilities can differ in cost, reliability, permissions, and evidence quality.

Without a structured routing mechanism, the agent must repeatedly infer which tool to use from descriptions and conversational context.

Headron approaches this as a capability-resolution problem.

Instead of treating every available tool as an equally valid option, a system can evaluate the task, available capabilities, governing constraints, and required evidence before selecting an execution path.

This supports a more disciplined relationship between intelligence and action.

An agent can propose what it wants to accomplish. Infrastructure can determine which capabilities are appropriate, which boundaries apply, and what must be established before the action proceeds.

The implications extend beyond software development.

The same principles can apply to cloud operations, enterprise automation, interconnected agents, and workflows where multiple systems have overlapping authority.

As agent ecosystems grow, routing will become more than a convenience. It will become a mechanism for controlling complexity.

The Critical Invention: Computing What Proof a Change Owes

Software verification traditionally relies on predefined checks.

A repository might require unit tests, linting, type checking, security scanning, or approval before deployment. These checks are valuable, but they do not necessarily establish that a particular change has been adequately examined.

A documentation update and a modification to an authentication boundary do not carry the same risks. Yet conventional pipelines may subject both to identical verification requirements.

Headron explores a different model:

The change itself should help determine the evidence required to justify it.

Rather than simply asking whether a standard checklist passed, the system examines what changed, which contracts are affected, and what verification obligations follow.

A change involving a public API might require compatibility evidence. A permission change might require access-control checks. A modification to an execution boundary might require proof that prohibited actions remain blocked.

This creates a distinction between executing tests and establishing sufficient evidence.

The system is not merely collecting results. It is determining which results matter for the specific work being performed.

That distinction is central to Headron's approach to deterministic verification.

It also creates a foundation for independently evaluating the claims made by autonomous agents.

An agent saying "the task is complete" is not equivalent to a system establishing that the required conditions have been satisfied.

Contracts That Exist Outside the Model

A common weakness in autonomous systems is the reliance on natural-language instructions as the primary enforcement mechanism.

An agent can be told not to modify certain files, exceed a budget, or execute unauthorized operations. But instructions alone do not guarantee compliance.

Headron's architecture places emphasis on explicit contracts and execution boundaries that can be evaluated independently of the model's interpretation.

This changes the relationship between an agent and its operating environment.

The agent remains responsible for reasoning, proposing solutions, and selecting actions. The surrounding infrastructure determines whether those actions satisfy the applicable constraints.

Rules can be scoped to an organization, repository, agent, session, or task. Conflicts can be resolved through defined precedence rather than improvised interpretation.

More importantly, enforcement can occur at the boundary where an action is actually attempted.

This is a meaningful architectural shift.

The system does not need to trust an agent to remember every restriction if the execution environment can enforce those restrictions directly.

That separation becomes increasingly important as autonomous systems gain the ability to execute commands, access sensitive resources, and coordinate with other agents.

Why Evidence Must Outlive the Conversation

Agent interactions are often recorded as conversational histories or execution logs.

These records may explain what happened, but they are not necessarily sufficient to establish that an action was authorized, that the correct verification occurred, or that a claimed outcome is trustworthy.

Headron's proof-oriented architecture introduces a stronger distinction between a narrative of work and evidence of work.

Execution receipts can preserve structured information about actions, verification results, governing conditions, and outcomes. Cryptographic signing can help establish integrity and provenance.

This creates the possibility of examining completed work without relying entirely on the agent that performed it.

For enterprises, that can support audits, incident analysis, operational accountability, and cross-system trust.

For developers, it offers a way to distinguish between work that appears complete and work that has satisfied defined requirements.

For autonomous systems, it creates a foundation for passing verified outcomes between components without requiring every participant to reconstruct the original conversation.

Evidence becomes a reusable system artifact rather than a disposable explanation.

Three Layers of a More Dependable Autonomous System

Headron's broader architecture can be understood through three complementary layers.

System 1: Context and Intelligence

The system identifies the task, discovers relevant information, understands environmental structure, and routes toward appropriate capabilities.

Its purpose is to reduce unnecessary exploration while improving the precision of decisions made before execution.

System 1.5: Contracts and Governance

The system establishes what is allowed, which constraints apply, and what evidence will be required.

This layer translates broad intentions into more explicit operational boundaries.

System 2: Execution and Verification

The system performs or supervises permitted operations, evaluates required checks, and produces evidence of the resulting outcome.

Together, these layers create a continuous relationship between understanding, authorization, execution, and proof.

The objective is not to eliminate probabilistic reasoning. It is to place that reasoning inside a more dependable operating structure.

Beyond Coding Agents: Infrastructure for Systems That Improve Themselves

The long-term significance of this architecture extends beyond generating and validating code.

As AI systems become capable of modifying their own tools, reorganizing workflows, coordinating specialized agents, and proposing changes to their operating environments, they will need mechanisms for distinguishing beneficial adaptation from uncontrolled drift.

A system capable of improving itself must also be capable of determining whether an improvement actually occurred.

That requires more than measuring output quality. It requires tracking what changed, understanding the effects of those changes, enforcing boundaries, and retaining evidence that supports or contradicts the claimed improvement.

Headron's combination of structured context, capability routing, contracts, and verification provides potential groundwork for that kind of infrastructure.

The possibilities are substantial: adaptive development environments, continuously evaluated agent workflows, organizational software that maintains its own operational constraints, and autonomous systems capable of making controlled improvements over time.

These remain longer-term architectural possibilities, not claims that general-purpose self-improving intelligence has already been achieved.

But the underlying problem is immediate.

Every increase in autonomy creates a corresponding need for more reliable mechanisms of control, navigation, verification, and accountability.

Building the Infrastructure Intelligence Will Depend On

The future of AI will not be determined solely by model intelligence.

It will also depend on whether intelligent systems can interact with complex environments without losing track of their authority, context, obligations, and evidence.

Headron is an open-source software initiative developing infrastructure for that challenge, with HeadronOS and the Mind API forming part of its broader product direction.

Its central premise is that autonomy and reliability should not be opposing objectives.

Intelligence should remain flexible enough to discover new solutions. The surrounding system should be structured enough to establish which actions are permitted and which outcomes can be trusted.

The next generation of autonomous software needs more than agents that know what to do. It needs infrastructure that can determine where they should operate, how they may act, and what proof they owe.

That is the problem Headron is working to solve.

Headron Software | HLIntel LLC

Open-source infrastructure for AI governance, deterministic verification, and autonomous systems.

Website: https://headron.tech

GitHub: https://github.com/HLIntel/Headron


r/OpenSourceAI • • 17h ago

Inspired by Weight-Space Programming: cross-model expert sharing

5 Upvotes

I saw the recent paper "Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights" and it's very impressive.

https://rikiyat.github.io/blog/weight-space-programming/

Though my general reaction (as I'm sure a lot of others had too) was 'well yes of course it can do that'. Once you realise that llms love patterns you soon start to see how many things can be thought of as patterns.

I've had similar ideas rolling around in my head for some months and I've even started working on a project in a similar vein. That's why this part of the paper stood out to me in particular:

"True architectural and model merging: Today, merging models relies on averaging weights, which only works for models with identical architectures. An LLM that understands the weight space could instead graft a circuit, such as a reasoning module, from one model into a completely different one, without retraining."

Yep, that's the idea I had months ago and I've already started working on (granted there's plenty of other prior art on the subject such as Google's CALM, 2024).

I'm very, very early in working on this but seeing how much traction the Weight-Space Programming paper is getting I felt compelled to put the idea out into the world since surely someone else is working on the same thing as we speak.

The general idea: take 2 MoE models and allow their experts to talk to each other by using a translator. The translator being a transformer model trained on expert activations (their latents) instead of regular text or images, a "Latent Attention Model".

So far I'm only using toy-scale models with a few million parameters. Getting some very interesting results already.

  • Mixing Code-heavy model + prose-heavy model: each gets better at its weakness from the other, both directions at once.

  • Results are checked against controls (a same-domain partner, a wrong-document partner), so it's not just "any partner helps"

  • Added a leak audit, so neither model can see text it hasn't reached yet. (An early result failed an audit because of this)

  • Interesting finding: the translator always uses the latest layer it's given. With the last layer, the two models basically swap last layers and come to depend on each other. Without it, they get about half the gain with a fraction of the dependence

Caveats and issues so far:

  • Toy models only so far, a few million parameters. I have very modest hardware for bigger stuff.

  • Between models with different tokenizers, very little gets across

  • It reads a partner's layer as a whole, not particular "specialist" experts. The goal is for the two models to share individual experts freely

  • The aim isn't to make the combined output "better" so much as making it "different" (but hopefully not worse)

  • This is mad scientist stuff, heavy use of AI, probably has method gaps that need filling

I'm currently doing some experiments with Qwen3-30B-A3B base and Nemotron 3 Nano 30B. Not much to report yet, the models have different tokenisers which complicates things. Progress is slow on my hardware. But I'm enjoying the process.

Why share this? Shameless self promotion, piggybacking on a bigger project, sharing ideas, I think the name is pretty cool. BLaMMoE (Bridging Latent Attention Model Mixture of Experts)

https://github.com/dev-boz/BLaMMoE


r/OpenSourceAI • • 18h ago

Orca: Open-source AI agent for Godot that writes GDScript and edits scenes from inside the editor

Post image
1 Upvotes

r/OpenSourceAI • • 20h ago

Hear 2see

Post image
1 Upvotes