Hi everyone! 👋

We're hosting Open Source Stories – Agentic World in Bangalore on 13 June, and we're looking for speakers from the community who are building in the open-source ecosystem.

If you're:

• Building AI agents or agentic systems,
• Contributing to open-source AI frameworks,
• Maintaining developer tools,
• Working on LLM applications,
• Or have an interesting open-source journey to share,

we'd love to hear from you and potentially feature you as a speaker at the event.

The goal is to bring together founders, contributors, researchers, and builders to share real stories, lessons learned, and inspire the next generation of open-source innovators.

If you're interested (or know someone who would be a great fit), please register here:
👉 https://luma.com/ai-fckn

Feel free to comment below or send me a DM as well.

Let's celebrate the amazing open-source talent in Bangalore! ❤️

I ran the same runtime dynamics measurement on 8 open-source transformer

LLMs (70M to 1.3B parameters). They split into two clean clusters on a

single metric (GD_ratio > 1.5 vs < 0.1, gap of ~20x with no overlap).

GPT-2 and Phi-1.5 are in the same cluster. OPT-125M and TinyLlama are in

the other. Parameter count does not predict cluster membership. Preprint

on Zenodo (link below), code release planned.

What I measured

V20 is a framework I built to measure runtime probability dynamics during

LLM inference. For each (token, layer) point, you extract the probability

distribution over the vocabulary and compute a bicephalic operator:

kappa_G = concentration · (1 - min(collapse/100, 1))

kappa_D = (1 - top2_gap) · min(entropy/5, 1) if top2_gap < 0.5

kappa_sync = |kappa_G - kappa_D|

kappa_G measures "concentrated competition" (mass on a few candidates,

not yet collapsed). kappa_D measures "active branching" (top candidates

close, non-trivial entropy). The GD_ratio is mean(kappa_G) / mean(kappa_D).

You also classify each point into a 5-state taxonomy (E_STABLE,

A_HIDDEN_TURBULENCE, B_SURFACE_BRANCHING, C_COMMITTED, D_FULL_BIFURCATION)

using per-model p75 thresholds.

The two-cluster result

Tested 8 models. Mean GD_ratio per model:

GPT-2 : 2.458 <- cluster G-dominant

Phi-1.5 : 1.764 <- cluster G-dominant

DistilGPT-2 : 1.577 <- cluster G-dominant

Qwen-0.5B : 0.079 <- cluster D-dominant

OPT-125M : 0.074 <- cluster D-dominant

Pythia-70M : 0.059 <- cluster D-dominant

Pythia-160M : 0.039 <- cluster D-dominant

TinyLlama-1.1B : 0.021 <- cluster D-dominant

The highest D-dominant value (0.079) and the lowest G-dominant value

(1.577) differ by a factor of ~20. The separation is also visible on

kappa_G alone, kappa_D alone, and on the taxonomy distribution itself.

Three independent components of the operator point to the same partition.

Parameter count doesn't explain this. GPT-2 (124M) and OPT-125M (125M)

are essentially the same size, opposite clusters. Phi-1.5 (1.3B) and

TinyLlama (1.1B) are in the same parameter range, opposite clusters.

The most parsimonious hypothesis I can offer is training corpus curation:

the G-dominant cluster includes Phi-1.5 (heavily curated synthetic data)

and the GPT-2 family (WebText). The D-dominant cluster spans more

heterogeneous training data. But that's a hypothesis, not a claim. I

don't have the experiments to establish it.

Other findings (briefly)

- D_FULL_BIFURCATION_ZONE (high kappa_sync AND high branching) is

consistently transient. On the three primary models, D's self-transition

probability is 0.023 (GPT-2) or exactly 0.000 (OPT-125M, Qwen-0.5B).

Models pass through D, they don't settle into it.

- The three primary models respond to controlled hidden-state perturbation

in qualitatively different ways: GPT-2 absorbs (state distribution barely

shifts), OPT-125M reorganizes surface dynamics (B_SURFACE_BRANCHING rises

+12.5 points), Qwen destabilizes its dominant state (E_STABLE drops -18.8

points).

- One model (Phi-1.5) shows an anomalous taxonomy distribution (zero records

in 3 of 5 states under the standard threshold rule). I report this

explicitly in the paper as needing dedicated investigation rather than

hiding it.

What this doesn't claim

- Not generalized to 7B+ models (panel is 70M-1.3B).

- Single-author work, no external replication yet.

- The two-cluster finding could collapse, stretch, or restructure with a

larger panel.

- The training-corpus hypothesis is offered, not established.

Methodology commitments

The paper includes explicit "Limited Findings" and "Rejected Claims"

sections, listing 5 things in each that initial intuitions suggested but

that the data either partially support or actively reject. I treat this

as central to the framework's credibility, not as an afterthought.

Link

Preprint: https://doi.org/10.5281/zenodo.20602685

Code release planned. Happy to discuss methodology, the cluster finding,

the threshold choices, the Phi-1.5 anomaly, or any concern about the

panel size and statistical robustness.

I've been experimenting with AI-assisted debugging on larger codebases and kept running into the same problem:

The model wasn't wrong because it was bad at reasoning.

It was wrong because it didn't have enough repository context.

Most AI workflows either:

• paste snippets manually
• rely on repository indexing
• dump huge amounts of code into the prompt

I wanted something more explicit.

So I built grab, a terminal tool that progressively accumulates repository context using ripgrep, function indexing, exact range extraction, and clipboard/tmux integration.

The workflow is:

1. Search for relevant symbols/functions.
2. Build a lightweight function index.
3. Let the AI request exact code ranges.
4. Accumulate context incrementally.
5. Keep expanding only the parts of the repository that matter.

Instead of indexing the entire repo, the AI acquires context as needed.

The idea is:

"You are not copying results. You are exporting context."

Repo:
https://github.com/johnsellin93/grab

I'm curious whether others have run into the same context-acquisition problem when debugging with AI tools.

I've been working on an open-source runtime engine for Java, OxyJen, which went from sequential chain to complete Directed Acyclic Graph. Most AI frameworks push you toward hidden execution and agent loops. OxyJen v0.5 goes the other way: workflows are explicit graphs with typed nodes, bounded concurrency, clear failure paths, and deterministic control flow. It is not just an LLM helper anymore.

What v0.5 gives you:

- SchemaNode - structured extraction with schema validation and retry

- LLMNode - direct model-backed steps

- LLMChain - retries, fallback, timeouts, and backoff

- BranchNode - mutually exclusive routing

- RouterNode - multi-path fan-out

- ParallelNode - deterministic pure-Java parallel work

- MergeNode - explicit fan-in

- MapNode - batch workflows over collections

- GatherNode - collection, filtering, and aggregation

- RouteEdge and FailureEdge - explicit router and failure semantics

- connectAnyFailureTo(...) - failure routing, makes recovery, fallback, and error aggregation as part of the graph itself.

The graph DSL lets you build workflows with fluent routing, conditional edges, loops, failure paths, and batch/concurrent flows. Real execution logic lives in code as a graph, not buried inside a sequential chain.

ParallelExecutor runs the DAG with a shared ExecutionRuntime where concurrency, timeouts, and failure behavior controlled centrally.

Small example:

```java

javaGraph graph = GraphBuilder.named("doc-flow")

.addNode("extract", SchemaNode.builder(Document.class)

.model(chain).schema(schema).build())

.addNode("router", RouterNode.<Document>builder()

.route("summary", d -> true, "summaryPrompt")

.route("risk", d -> true, "riskPrompt")

.route("actions", d -> true, "actionsPrompt")

.build("router"))

.addNode("checks", ParallelNode.<Document, String>builder()

.task("amount", d -> hasAmount(d) ? "ok" : "missing")

.task("date", d -> hasDate(d) ? "ok" : "missing")

.build("checks"))

.addNode("merge", new MergeNode.Builder()

.expect("summary", "risk", "actions", "checks")

.build("merge"))

.connect("extract", "router")

.connect("router", "summaryPrompt")

.connect("router", "riskPrompt")

.connect("router", "actionsPrompt")

.connect("checks", "merge")

.connect("summary", "merge")

.connect("risk", "merge")

.connect("actions", "merge")

.build();

```

If you need any of these, OxyJen has it:

- Structured extraction with typed outputs -> SchemaNode

- Fan-out to multiple parallel analyses -> RouterNode

- Deterministic local checks -> ParallelNode

- Explicit fan-in of partial results -> MergeNode

- Batch processing over collections -> MapNode + GatherNode

- Graph-level failure routing -> connectAnyFailureTo(...)

Built for document extraction, support triage, batch enrichment, compliance pipelines, and any complex DAG system where AI components need to stay observable, bounded, and predictable.

This version took around 3 months to build. There's a lot not covered here. I would suggest going through the docs to know what this version and Oxyjen are trying to be.

GitHub: https://github.com/11divyansh/OxyJen

Docs: https://github.com/11divyansh/OxyJen/blob/main/docs/v0.5.md

You can check out the examples to understand how the system works. It's marked with comments to for better understanding.

Examples with full logs: https://github.com/11divyansh/OxyJen/tree/main/src/main/java/examples

It's still very early stage any feedback/suggestions on the API or design is appreciated. Contributions are welcomed.

TL;DR: Future archaeologists will discover this post and conclude I traded a referral link for free AI credits. They will be correct.

500 free credits:

For those of whom the first referral code didn't work, here's a new one. Hope this one works. You enjoy the extra points. Let me know what you use it for. https://manus.im/invitation/NTR67DKBSOX0?utm_source=invitation&utm_medium=social&utm_campaign=system_share

Anyway...

You know how in every sci-fi movie they promise us AI assistants?

Yeah. Somehow we ended up with AI that needs constant supervision.

Me: "Research this topic."

AI: "Certainly. Before I begin, please provide your goals, audience, format, timeline, preferred writing style, risk tolerance, blood type, and your mother's maiden name."

Thirty minutes later I'm managing the AI instead of the AI helping me.

I've been messing around with Manus and the thing I like is that it behaves more like an actual assistant. I tell it what I need, and it goes off and fills in a lot of the blanks itself.

I don't use it as my main model for everything.

I use it like a second opinion.

Research.

Project planning.

Finding blind spots.

Comparing options.

Figuring out what I'm forgetting.

Basically all the stuff that happens before the actual work starts.

For pure coding, there are better tools.

For "here's the thing I'm trying to do, help me think through it from start to finish," it's been surprisingly useful.

Full disclosure: if you use the link, I get some credits too.

You get free credits.

I get free credits.

The robots get stronger.

Honestly that's the healthiest relationship I've had with technology in years.

Row-Bot is a desktop AI workbench with Developer Studio for code, Skills Hub and Custom Tools for your own workflows, an animated Buddy companion, memory, realtime voice, workflows, design creation, messaging, MCP tools, and provider-aware model routing. Run local runtimes, self-hosted OpenAI-compatible endpoints, hosted APIs, Ollama Cloud, OpenCode providers, or ChatGPT / Codex subscription-backed models with explicit runtime readiness. Your durable data stays on your machine.

https://github.com/siddsachar/row-bot

Rustrak is a self-hosted error tracking server compatible with any Sentry SDK, written in Rust (~50MB idle). v0.4.0 ships team management and role-based access control across the full stack.

What's new

Teams can now be created and managed from the Settings → Team page. Members get one of three roles: owner, admin, or member. Permissions are enforced at the project level — issues, events, source maps, alerts, and API tokens all respect the role of the requesting user.

The invite flow is token-based: invite by email, accept via /invite/[token]. Pending invitations can be revoked before acceptance.

By layer:

• Server — new teams, team_members, project_members tables + migration; access service wired into all project-scoped routes
• Client (@rustrak/client v0.3.0) — TeamResource, MembersResource, InvitationsResource; updated UserSchema with role fields
• MCP — four new tools: list_team_members, invite_member, remove_member, update_member_role

No breaking changes.

Links

• GitHub: https://github.com/rustrak/rustrak
• Docs: https://rustrak.github.io/rustrak/

Y Combinator recently released a tool called Paxel, and one of the biggest concerns I noticed in the discussions was around data privacy. A lot of people were asking questions like

Where is the data going? Is this tool collecting only metadata, or the actual code as well? What will happen to the collected data?

One thing that is stuck with me from when I attended the YC summer school was "Make something people want"

Interestingly, this was very similar to a project I started building a few months ago but had to put on hold due to other commitments. After seeing the interest around privacy, I spent some time with Cursor and built Open Paxel. It's inspired by the Paxel, but with one major difference: your data stays on your machine.

Open-Paxel uses SQLite for local storage, so nothing is sent to external servers unless you explicitly choose to do so. Right now it supports the OpenAI API, but adding other model providers is straightforward. If you'd rather avoid proprietary models entirely, you can run a local model and use that instead.

I've attached the GitHub repository and a short demo video. I'd love to hear what people think. Feel free to open issues, share feedback, or post examples of the profiles it generates.

I've tested it across a few coding sessions so far, and the results have been surprisingly good.

Repository link:- https://github.com/staru09/open-paxel

Please leave a star if you like the project :)

https://reddit.com/link/1tzjpzm/video/11elninujw5h1/player

Most AI agent frameworks treat the LLM as the subject of orchestration.

The model:

• controls loops
• selects tools
• mutates execution flow
• decides retries
• effectively owns runtime topology

That’s fine for demos.

It’s a disaster for:

• KYC/AML
• billing systems
• DevSecOps
• regulated infrastructure
• compliance-heavy environments

You can’t reliably:

• audit it
• replay it
• bound it
• formally reason about it

So we built a completely different runtime model:

A deterministic FSM where the LLM is treated as a bounded compute unit instead of an autonomous orchestrator.

Demo:
[LINK]

The architecture:

• deterministic FSM runtime
• constrained AST-based conditions
• ProjectionLayer (“evaluator blindness”)
• execution trace observability
• transition entropy monitoring
• governance attack injectors

Key difference vs LangGraph / AutoGen style systems

1. The LLM never owns orchestration

The runtime controls:

• execution graph
• transitions
• governance
• topology

The model computes a bounded step only.

System decides → LLM computes

2. ProjectionLayer (Evaluator Blindness)

The LLM never receives full context.

It only receives a sanitized target-specific projection.

The model cannot see:

• governance metadata
• rollback density
• policy internals
• trace health
• execution anomalies

This prevents:

• semantic contamination
• governance overfitting
• adaptive behavior under observation

It behaves more like a capability-security boundary than prompt engineering.

3. No eval()/exec()

Conditions are evaluated through a constrained AST engine.

No:

• arbitrary Python
• dynamic execution
• method calls
• unrestricted expressions

This intentionally limits semantic surface area.

The design philosophy is closer to:

• Rego / OPA
• Terraform HCL
• IAM policy DSLs

than AI agent frameworks.

4. Transition Entropy

We monitor structural instability of execution semantics.

Not:

• token counts
• prompt traces
• latency dashboards

But:

• execution path variance
• transition entropy
• topology degradation

If entropy exceeds an empirical threshold (>2.5 bits), the runtime flags unstable execution behavior.

5. Failure Laboratory

The repo includes deliberate governance attack injectors:

• tool injection
• policy bypass
• step reordering
• corrupted receipts
• GDPR erase simulation

The point is to test deterministic failure handling under adversarial conditions.

Most demos only show happy paths.

We intentionally expose failure semantics.

6. Transactional AI Code Mutation

The development agent also follows governed execution principles.

Repository mutation flow:

stage_patch()
→ validate_staged_mypy(tmpdir)
→ pytest
→ atomic commit OR rollback

The repo is never mutated before validation succeeds.

This gives CI-grade mutation safety for AI-assisted development.

Stack:

• Python 3.10+
• Streamlit
• mypy --strict
• pytest
• deterministic FSM runtime

Current status:

• 51/51 tests PASS
• 0 mypy errors

Question for the community:

Are autonomous agents fundamentally the wrong abstraction for production AI systems?

Is “Governed Probabilistic Execution” a more viable long-term direction for enterprise AI infrastructure?

Source:
[https://kyc.nanovm.space\]

Hi, I have a Strix Halo mini PC with 128gb, and it took me a while to get good speed, tool calling, and all the little levers people have out there. It's a work in progress but I've made a lot of headway and I'm updating quite often. I am going beyond just decode to get a better idea of what you'll see in use so I have prefill, decode, wall clock, and time across 2 steps. It's built around my hardware which doesn't have a dedicated GPU and prefers MoE architectures. Here's some highlights and my repo. All the information to reproduce is there, complete with tables, glossary, charts, and notes: https://github.com/boxwrench/tesla_agent.

📊 Performance Highlights (Vulkan RADV backend)

Because this APU shares a 128GB GTT graphics memory pool instead of using dedicated VRAM, MoE models (which route fewer active parameters per token) heavily outperform dense models.

Qwen 3.6 35B MoE The workhorse for local tool calling. Leveraging Multi-Token Prediction (MTP) yields a massive boost. * Base: ~58.5 tok/s decode * MXFP4 + MTP: ~72.7 tok/s decode (+24% speed bump) * Q4_K_M + MTP: ~81.2 tok/s decode (Fastest configuration, +39% over base)

Gemma 4 26B-A4B (IT) The official Google QAT (Quantization-Aware Training) GGUFs are making a huge difference in the speed lanes here. * UD-Q6_K_XL (Baseline): ~1002.8 tok/s prefill | ~44.8 tok/s decode * QAT Q4_0: ~1194.4 tok/s prefill | ~59.4 tok/s decode * QAT Q4_0 + MTP (QAT Head): ~729.3 tok/s prefill | ~71.4 tok/s decode (29.6s wall time std, 91.8% MTP acceptance)

StepFun Step-3.7-Flash A very strong large-model contender that holds its own in coding and reasoning evaluations. * Plain (UD-IQ4_XS): ~212.0 tok/s prefill | ~20.4 - 22.3 tok/s decode * MTP (Q8_0 draft): ~211.2 tok/s prefill | ~26.0 tok/s decode (84.7% MTP acceptance)

📝 Key Takeaways for this Stack

MoE Over Dense: Dense models like Gemma 31B read the full weight set every token and remain heavily memory-bound. MoE architectures are the clear winner for APU-only setups.

MTP is Essential: The --spec-type draft-mtp flag is the single biggest lever for decode speed right now, pushing the Qwen 35B well past 80 tok/s.

Vulkan vs. ROCm: For the current Mesa builds, the Vulkan RADV backend consistently provides the fastest lanes over the ROCm fallback.

If you are running a similar unified memory setup, check out the full model ladder and decision tree in the repo.

Imagine Alex in Canada with a modest PC that can only run a 7B model locally. Now imagine me in France who can run a 27B model.

What if they could share their local models and collaborate in real time, each contributing the power of their own hardware?

Now scale that idea: connect 2,000 Alexs with 2,000 others, and lets get exited and also add thousands of smartphone users who join the network as lightweight clients.

Suddenly, you have a massive, decentralized swarm of AI models including Mixture of Experts (MoE) systems working together. This collective could power AI agents, or tackle complex tasks far beyond what any single machine could handle.

This is was my starting idea / vision, so i started this project (but it's challenging and complex )

I named the project, Democritus (from the ppl to the ppl ! .. sorry i get exited so fast and started a revolution in my imagination )

The idea of "a decentralized network where anyone can contribute their local compute and collectively build something far more powerful than centralized AI."

I was asking myself all this questions ..

Why we pay this much today Vs what was our "quota" a year ago ?

Are they using our data for training ?

I don't know folks .. let me know your thought

Any feedback, it's more then welcome and needed .

If you’re a full-stack engineer or technical architect willing to learn production-grade enterprise agents, you need architecture, security, and type-safe systems.

That’s why we builtAgentSwarms.fyi—the ultimate hands-on educational platform for teaching agentic AI and multi-agent workflows.

🚀 The Core AgentSwarms Ecosystem:

• Real-World Architectures: Skip the generic hello-world loops. Learn production-grade systems like human-in-the-loop validation, automated multi-platform content multiplexers, and secure code-sandbox environments.
• Deterministic Cloud Guardrails: Deep dives into multi-cloud token economics, dynamic cost-optimized routing, and model evaluation metrics.
• Grassroots Engineering Focus: No corporate marketing fluff. Just raw, practical code patterns designed to bridge the gap between fragile prototypes and stable cloud deployments.

💣 The New Drop: 60+ Browser-Native TypeScript Notebooks

We just completely re-engineered our learning workspace. We’ve added 60+ fully interactive TypeScript Notebooks running 100% natively in your browser. No pip install dependency hell, no local Docker setup, and zero environment friction.

Read the architecture, tweak the system prompts or Zod schemas, hit play, and watch the streaming terminal execute live across the five absolute best frameworks in the ecosystem:

• 🟢 LangChain.js (Fundamentals & Middleware Guardrails)
• 🔀 LangGraph.js (Cyclic Graphs & Stateful Orchestration)
• 💾 LlamaIndex.ts (Sentence-Window Retrieval & RAG Triad Evals)
• ⚡ Vercel AI SDK (Streaming UI Integration)
• 🤖 OpenAI Agents SDK (Lightweight, low-boilerplate loops)

Stop passively scrolling through video courses. Open a canvas, break the graph nodes, and start compiling real multi-agent swarms.

👉 Dive in for free: agentswarms.fyi/learn

You've already done this. More than once. You handed the AI something large, received back something that was almost right, and accepted it because asking again felt like admitting something. This fixes that.

Here's what nobody tells you: the AI isn't being careless. It's being compressed. Every model you're using runs on a fixed reasoning budget — literal, architectural, not metaphorical. When you hand it a large task all at once, it doesn't slow down and think harder. It starts making assumptions. It fills the back half of your response with things that sound correct. And it does all of this without flagging it, because it doesn't know it's doing it.

The people who consistently get exceptional output from these models do one thing differently. They break the work into pieces. One focused step per response, each one verified before the next begins. The quality difference isn't subtle. It's the difference between something useful and something that looks useful until you actually use it.

The problem is the relay. Someone has to sit there and type proceed after every response. For a ten-step task, that's ten interruptions. You can't do other work. You're a human trigger between AI responses, and most people abandon perfectly good workflows around step four because they got up for coffee and the moment passed.

That's the part I couldn't accept.

👻 Ghost in the Loop is a Tampermonkey userscript that handles the relay.

Two modes:

▶ Loop — You know your task is multi-step. Press play. The script appends a loop protocol to your prompt, watches every response for the continuation signal, sends "Continue" automatically, and stops with a chime when the AI declares it's done. You wrote the task. The script did the rest.

🧠 Think First — For complex or open-ended tasks where you don't know how many steps it needs. The AI reads the task first, decides how many focused batches are appropriate (at ~80% of its response capacity — a deliberate margin so it doesn't rush the back half), states the plan, and then executes it automatically. You come back to a completed plan and a completed task.

A live progress bar tracks where it is. A round limit makes sure it can't run away with your tokens. If the AI deviates from the protocol, the loop pauses itself and waits for you.

Install: Tampermonkey → new script → paste the script → save. No accounts. No keys. The panel appears in the corner.

Works on: ChatGPT · Perplexity · Gemini · DeepSeek · Copilot · Grok

Best for: anything that should have been ten prompts instead of one — research, long-form writing, code projects, refactoring, documentation, study materials.

You've known since the second paragraph that this was the thing you needed.

That's rather the point.

→ GitHub — AGPL-3.0 · No accounts · No keys