[2026.06 Week 1] Five Trending Repos of the Week
Five GitHub repositories trending this week.
TL;DR
AI agent tooling dominated. Most of the trending repos were coding agents, agent runtimes, sandboxes, memory layers, or the frontends that drive them.
Skill packs spread across domains. Curated bundles of Claude Code and Codex skills showed up for design, marketing, research writing, and security.
Tools competed on token cost. A run of them promised the same results for 40 to 90 percent fewer tokens through compression, indexing, or proxying.
A few free-access proxies trended. Tools like freellmapi and 9router aggregate free-tier API keys or pool paid subscriptions to hand out model access.
This week’s picks:
odysseus (⭐ 62.1k). A self-hosted, local-first AI workspace from PewDiePie that runs chat, agents, and research against your own models.
forkd (⭐ 1.9k). A Rust tool that gives AI-agent microVMs fork() semantics, cloning isolated KVM sandboxes from one warm parent.
open-code-review (⭐ 5.0k). Alibaba’s open-sourced code reviewer that pairs deterministic static-analysis pipelines with an LLM agent.
supervision (⭐ 41.8k). Roboflow’s library of reusable computer-vision parts that turn raw detections into tracking, counting, and annotation.
CopilotKit (⭐ 33.8k). A frontend stack that lets AI agents render real React and Angular components, built on their AG-UI event protocol.
pewdiepie-archdaemon/odysseus
⭐ 62.1k · Python
Odysseus is a self-hosted, local-first AI workspace bundling chat, agents, deep research, and document editing in one app. It runs on your own hardware against local models or your API keys, and scans your machine to recommend a model that fits. Felix Kjellberg (PewDiePie) released it in late May with an anti-big-tech, never-costs-money pitch, and it hit tens of thousands of stars in days. GitHub tags the repo JavaScript, but it is a Python and FastAPI app.
Its Deep Research mode is an agent that runs rounds of search, reading, and synthesis to build a report. The hard part is knowing when to stop. Stopping early gives a thin report. Running too long wastes time and tokens after the question is already answered. Odysseus hands that judgment to the model itself.
async def _should_stop(self, question: str, report: str,
round_num: int) -> bool:
"""Let the LLM decide whether the report is comprehensive enough."""
prompt = STOP_PROMPT.format(
question=question, report=report,
round_num=round_num, max_rounds=self.max_rounds,
)
try:
response = await self._llm(
[{"role": "user", "content": prompt}],
temperature=0.1, max_tokens=128,
)
# Reasoning models prepend a <think>...</think> block — strip it
# before checking for YES/NO, otherwise the answer always looks
# like it starts with "<THINK>" and the engine never stops.
clean = strip_thinking(response).strip()
# Tolerate "**YES**", "Yes.", quotes, etc.
answer = re.sub(r'^[\s*_`"\'>#\-]+', '', clean).upper()
should_stop = answer.startswith("YES")
logger.info(f"Stop decision (round {round_num}): {clean[:120]}")
return should_stop
except Exception as e:
logger.warning(f"Stop decision failed: {e}")
return False # continue on errorThe main loop runs up to max_rounds, eight by default. Each round generates queries, searches, extracts findings, and re-synthesizes the report. Once it has done at least min_rounds (two), it calls _should_stop and asks the model whether the report already answers the question, with the prompt nudging it to keep going if the round count is well below target. The reply is constrained to YES or NO plus a one-sentence reason, at low temperature with a 128-token cap.
Reasoning models emit a <think> block before their answer, so a naive startswith("YES") check would see <THINK> first and never end the loop. Odysseus strips the thinking block, then peels off leading markdown, quotes, and bullets before uppercasing and testing for YES. If the call throws an exception, it returns False and continues instead of stopping early on an error. The result is an agent that sizes its own budget. The two-round floor stops it quitting after one shallow pass, the eight-round ceiling caps a runaway, and in between a cheap judge call decides round by round whether more searching is worth it. It is LLM-as-judge applied to the process that produces the answer rather than to the answer itself.
deeplethe/forkd
⭐ 1.9k · Rust
forkd brings Unix fork() semantics to AI-agent microVMs. It boots one VM with the agent’s environment warmed, snapshots it, then spawns many KVM-isolated children from that parent almost instantly. The headline benchmark is 100 VMs in about 100ms, plus a live mode that branches a still-running VM in around 150ms. The point is fanning an agent out across many tool calls or code paths in parallel, each in its own real sandbox.
Spawning 100 isolated VMs in 100ms sounds like it must involve some exotic memory trick. forkd writes almost none of it. It leans on the Linux kernel instead.
// Phase 2: parallel restore via threads. Each thread issues one
// /snapshot/load PUT to its child's API socket.
let bodies: Vec<String> = children
.iter()
.map(|c| match &c.memfd {
// ... v0.4 memfd path, used only for live BRANCH ...
None => serde_json::json!({
"snapshot_path": &self.vmstate,
"mem_backend": {
"backend_path": &self.memory, // every child: the same memory.bin
"backend_type": "File",
},
"resume_vm": true,
})
.to_string(),
})
.collect();
let mut handles = Vec::with_capacity(n);
for (c, body) in children.iter().zip(bodies) {
let sock = c.sock.clone();
handles.push(thread::spawn(move || -> Result<()> {
api_call(&sock, "PUT", "/snapshot/load", &body)
}));
}
for h in handles {
h.join().expect("restore thread panicked")?;
}Earlier in the same function, forkd spawns N Firecracker processes and waits for each one’s API socket. This block then fires N threads, each telling its VM to load the snapshot. Every load points backend_path at one shared memory.bin, the parent’s memory image. Firecracker mmaps that file with MAP_PRIVATE, so the kernel hands each VM the same physical pages copy-on-write, and no page is duplicated until a child writes to it. Because the restores run in parallel rather than in sequence, 100 loads overlap and the batch lands in about 100ms. The warm environment was built once at snapshot time, and every child inherits it for free.
Live BRANCH, the mode that snapshots a running VM, needs writable shared memory, so it swaps the file backend for a memfd (the Some(region) arm trimmed above). The base fork does not. It is mostly process spawning and one HTTP call per child, with the kernel page cache doing the rest.
alibaba/open-code-review
⭐ 5.0k · Go
open-code-review is a code-review tool that combines deterministic static-analysis pipelines with an LLM agent and posts line-level comments on a diff. It runs against a changeset, either from the CLI or inside a GitHub Action, reviews each changed file against a built-in ruleset plus the model, and it writes inline comments. Alibaba ran it internally for two years before open-sourcing it, and it is bring-your-own-LLM with OpenAI and Anthropic compatibility, so teams use it as a self-hosted alternative to paid review services.
A comment is only useful if it lands on the right line, and LLMs are bad at line numbers. Their guesses drift, especially across a diff. open-code-review sidesteps this by never trusting the model’s line numbers at all. The model returns the offending code as a snippet, and deterministic Go code finds where that snippet actually sits.
func resolveFromHunk(d *model.Diff, cm *model.LlmComment) bool {
hunks := ParseHunks(d.Diff)
if len(hunks) == 0 {
return false
}
targetLines := splitAndNormalize(cm.ExistingCode)
if len(targetLines) == 0 {
return false
}
// New side first: context + added lines, with new-file line numbers.
for i := range hunks {
newSide := extractSideLines(&hunks[i], true)
if start, end, ok := matchConsecutive(newSide, targetLines); ok {
cm.StartLine = start
cm.EndLine = end
return true
}
}
// Then old side: context + deleted lines, with old-file line numbers.
for i := range hunks {
oldSide := extractSideLines(&hunks[i], false)
if start, end, ok := matchConsecutive(oldSide, targetLines); ok {
cm.StartLine = start
cm.EndLine = end
return true
}
}
return false
}The model fills an ExistingCode field with the lines it is commenting on, as plain text. resolveFromHunk parses the diff into hunks, normalizes that snippet, and scans for a consecutive run of matching lines, new side first then old. StartLine and EndLine come from the matched lines’ real positions, not from anything the model claimed. The match survives formatting noise because normalizeLine trims whitespace and strips a leading + or - marker, so + foo() lines up with foo(). If hunk matching fails, resolveFromFileContent scans the whole new file, and only then does a separate LLM relocation step regenerate a cleaner snippet.
The line number is computed from the diff text itself rather than hallucinated by the model. That inversion, treating the model as a source of code to locate rather than coordinates to trust, is why the comments land where they should.
roboflow/supervision
⭐ 41.8k · Python
supervision is Roboflow’s library of reusable computer-vision parts that sit on top of any object detector. It handles the unglamorous work around a model, post-processing detections, drawing annotations, tracking objects across frames, and counting how many cross a line or enter a zone. Given your model’s boxes, a tracker, and a virtual line drawn on the frame, it reports crossings by direction.
Counting line crossings is harder than it sounds. A detector gives you boxes per frame and nothing else, so you have to work out which side of the line each object is on, then notice when an object moves from one side to the other without miscounting on every jittery frame. The side test is a cross product.
all_anchors = np.array(
[
detections.get_anchors_coordinates(anchor)
for anchor in self.triggering_anchors
]
)
cross_products_1 = cross_product(all_anchors, self.limits[0])
cross_products_2 = cross_product(all_anchors, self.limits[1])
# Works because limit vectors are pointing in opposite directions
in_limits = (cross_products_1 > 0) == (cross_products_2 > 0)
in_limits = np.all(in_limits, axis=0)
triggers = cross_product(all_anchors, self.vector) < 0
has_any_left_trigger = np.any(triggers, axis=0)
has_any_right_trigger = np.any(~triggers, axis=0)
return in_limits, has_any_left_trigger, has_any_right_triggerFor each tracked object, supervision picks a reference point on its box, the corners by default, and uses a cross product to tell which side of the line that point is on. Because the line is a finite segment and not endless, in_limits also checks the point sits between the two endpoints rather than off past either end, so an object passing well to the side of a short line is ignored. The same test runs across all detections at once.
Knowing which side an object is on isn’t enough. An object lingering near the line would get counted on every frame, so the trigger method remembers each object’s recent side and counts a crossing only when that side actually flips from left to right or back. It stores that short history per object, keyed on both the tracker id and the class id. Keying on both is a recent fix, so when a tracker reuses an id for a new object the old crossing state no longer carries over. The geometry decides position each frame, and the stored history turns that noisy signal into one clean crossing event.
CopilotKit/CopilotKit
⭐ 33.8k · TypeScript
CopilotKit is a frontend stack for AI agents that render real interface components instead of only emitting text, something it calls generative UI. You register renderers and frontend actions in your React or Angular app, and as the agent streams tool calls they show up as live components, carried over the AG-UI event protocol CopilotKit authored.
The point of generative UI is that an agent can render a chart or a form, not just describe one. A tool call arrives as a name and a stream of JSON arguments, and CopilotKit has to turn that into a React component that fills in as the model types.
use-render-tool-call.tsx:149-177
// Priority order:
// 1. Exact match by name (prefer agent-specific if multiple exist)
// 2. Wildcard (*) renderer
const exactMatches = renderToolCalls.filter(
(rc) => rc.name === toolCall.function.name,
);
const renderConfig =
exactMatches.find((rc) => rc.agentId === agentId) ||
exactMatches.find((rc) => !rc.agentId) ||
exactMatches[0] ||
renderToolCalls.find((rc) => rc.name === "*");
// Fall back to the framework's built-in default tool-call renderer
// when neither a per-tool nor a wildcard renderer has been registered.
const RenderComponent = (renderConfig?.render ??
defaultToolCallRenderAdapter) as ReactToolCallRenderer<unknown>["render"];
const isExecuting = executingToolCallIds.has(toolCall.id);
return (
<ToolCallRenderer
key={toolCall.id}
toolCall={toolCall}
toolMessage={toolMessage}
RenderComponent={RenderComponent}
isExecuting={isExecuting}
/>
);CopilotKit picks the component to draw by tool name, walking a priority chain from most specific to least. An exact match for the current agent wins, then a looser name match, then a catch-all wildcard *. If nothing matches, a built-in default still draws the call, so even a demo with no custom renderers shows something instead of going blank.
The component appears right away, before the call finishes. As the model streams its JSON arguments, CopilotKit parses whatever has arrived so far and re-renders as more tokens land, carrying the same component through in-progress, executing, and complete states. That is how generative UI works. A tool call is a name plus a streaming blob, and CopilotKit turns it into a React element that fills itself in as it goes.