Continue

Continue AI

Continue AI

Continue AI

Continue AI

Continue AI

Continue AI

Continue AI

Continue AI

Continue AI

Continue AI

API Cache not working or Claude Console Dashboard UI bug?

Hey there, I'm not sure if my system was using cache or if I was burning tokens needlessly? How can I confirm I have things set up correctly and it's only UI bugs? My Claude Dashboard and dashboard logs are not consistent (can one download the full log?) Using Rider and Continue.dev name : Local Config version : 1.0.0 schema : v1 models : - name : Claude Sonnet 4.6 provider : anthropic model : claude-sonnet-4-6 apiKey : ${{ secrets.ANTHROPIC_API_KEY }} roles : - chat - edit - apply defaultCompletionOptions : promptCaching : true requestOptions : timeout : 200000 thinking : type : "adaptive" effort : "low" https://preview.redd.it/h40ho3ui7n4h1.png?width=392&format=png&auto=webp&s=262fc188714299962923fbff961bab6814c3c45c https://preview.redd.it/g1l5uahj7n4h1.png?width=1096&format=png&auto=webp&s=08960e0f51b6628f9bb15863e463862cd844a0de https://preview.redd.it/5gtstt1k7n4h1.png?width=423&format=png&auto=webp&s=9fcb62379045259cd6ebc99c541b6bb90100e5a2 submitted by /u/SavingClippy [link] [comments]

Safety guardrails continue to improve, but what happens if open-weights surpass cloud based models?

submitted by /u/TheOnlyVibemaster [link] [comments]

Max Subscription vs $100 API based

I’ve been using Claude Code on a pay-as-you-go basis because the API costs can add up quickly. Lately, though, I’ve been using it a lot more than expected and just realized I’ve spent around $100 this month alone. At this point, I’m wondering if it makes more sense to just get the $100/month subscription since I’ll probably continue using it heavily. For those who’ve made the switch, was it worth it? Any downsides I should be aware of? submitted by /u/dzaffren [link] [comments]

Managing context with dispatch

I've seen a few recent posts about context rot and the importance of handing off to new sessions frequently. With dispatch it feels like one long continuous chat with memory over all the historical. Does anyone have insight into the context length consideration when using dispatch? submitted by /u/peglegsmeg [link] [comments]

Loadable protocols vs descriptions in Claude system prompts — an open-source therapy framework as case study

I built an open-source framework called Inner Dialogue — a structured AI therapy supplement that runs on Claude Code. It's file-based, which is the whole point: the modality protocols, your profile, and your session history all live as local markdown, so Claude Code reads them at session start and writes session notes and profile updates back to disk as you go. That's why it's Claude Code and not the web app — it needs local file read/write to do the session-to-session continuity. Free to try, MIT-licensed, no paid tiers: github.com/ataglianetti/inner-dialogue I'm a product manager, not a career engineer, so I built the whole thing with Claude Code too: Claude wrote most of the implementation while I drove the architecture and the clinical content. The thing I learned building it that I think generalizes beyond therapy: there's a real difference between system prompts that describe a methodology and system prompts that ship the methodology as a loadable sequence the model can run. Most "expert system" prompts are descriptive — they tell the model what a framework is, what its terms mean, what the user might experience. The model can then sound like it's using the framework. But it's not running anything. There's no triggering-pattern-to-next-move logic. The difference shows up most clearly in clinical modalities. DBT works well in AI tools, including Claude, because DBT happens to ship its protocols as mnemonics: TIPP, DEAR MAN, ACCEPTS. The mnemonic IS the sequence. When you load DBT, you're loading operational content. IFS (Internal Family Systems) doesn't work nearly as well in most AI tools, despite being conceptually simpler to describe. The IFS protocol (the 6 F's) requires the system to run a specific diagnostic question — "how do you feel toward this part right now?" — at a specific point in the sequence. Without it, every conversation collapses back into talking about parts instead of to them. Inner Dialogue's IFS modality file is built around that diagnostic as a literal move, with signaling cues spelled out as verbatim client phrases the system listens for ("I am worthless," "I just need to think positive"), example interventions in therapist voice, and cross-modality routing embedded at the point a handoff applies (e.g., compulsive behaviors: IFS leads, CBT follows). Full writeup with the structural argument: Most AI therapy tools describe the modality, they don't run it. Curious how others have approached the loadable-vs-descriptive distinction for other expert domains. The point about pre-packaged mnemonics (DBT) being the easiest to operationalize seems like it should generalize. submitted by /u/echowrecked [link] [comments]

Bit-Mass Theory – The Container Principle

The Bit-Mass determines the information capacity and thus the model accuracy, not the chosen computation format. The Bit-Mass Theory presented here reorders neural networks by considering the total number of weight bits as the central quantity. Float32 matrix multiplication and BV32 with XNOR-plus-Popcount achieve exactly comparable results on MNIST with an identical Bit-Mass of 203264 bits. Comparison of three trainers (architecture 784→8→10, three epochs): - AdamW with Momentum and adaptive learning rate: 81.3 % - Vanilla-SGD (Float32): 76.0 % - BV32-Hebbian (binary): 76.4 % Further central findings: - Float32 and binary containers deliver nearly identical accuracy at the same Bit-Mass. - The remaining distance to AdamW is based solely on Momentum and adaptive learning rates. - Pure change of the arithmetic does not improve the result. Each neuron functions as a container for 32 binary decisions. The classical neuron perspective therefore leads to systematic misjudgments: eight Float neurons correspond informationally to 256 binary neurons. This insight is supported by three equivalent descriptions of the same weight matrix (neuron, bits, and data view). It is critical to note that this is a previously non-peer-reviewed single study with a future date. An independent reproduction by multiple laboratories remains essential. Nevertheless, the theory provides a consistent explanation for why Hebbian updates without backpropagation achieve the same performance as classical SGD. Historically, the Hebbian rule was long considered unstable. The present work shows that a simple error in the update formula was responsible for a performance loss of over 65 percentage points. After correction, the binary method converges exactly at the level of Vanilla-SGD. From an architectural theoretical perspective, a clear consequence emerges: Performance increases require either more bits through wider layers or a more efficient use of existing bits through Momentum and adaptive methods. The computation format itself is secondary. The experimental control is high: all trainers use identical data (50,000 MNIST examples), identical number of epochs, and identical architecture. Only the update rule varies. This allows effects to be clearly isolated. Long-term implications for research: The Bit-Mass Theory enables hardware-independent comparability of models. A wide Float network with 64 hidden neurons has the same Bit-Mass as a binary network with 2048 neurons. This opens new paths to model compression and the development of specialized accelerators. In summary, the work provides a fact-based contribution to the debate on efficient neural networks. The results are documented in a reproducible manner, but require further external validation before one can speak of a generally valid paradigm shift. 📎 Source 1: https://forward-prop.nhi1.de/ submitted by /u/aotto1968_2 [link] [comments]

If you continue to use the same chat, will it eventually start to lag?

I've used the same chat for my language learning forever and I feel like that chat really knows what I know and don't, and how to best explain things. Now though, every second message lags and Claude doesn't give me an answer so I have to try many times over again. Is it that I've used the same chat too long or just a random bug? I can use other chats without them lagging🤧 submitted by /u/Chat_Black [link] [comments]

Long Claude chats slowly get worse - slower, repetitive, forgetful. Here's the "context handoff" trick that resets it without losing anything (prompt inside)

Most people use Claude to get answers. The thing it is actually best at is the opposite: pressure-testing an answer you already have. Its long context and willingness to hold nuance make it a far better "argue with me" partner than a one-shot question box. The mistake is doing it in a single prompt - "is this a good idea?" - which just gets you a polite yes with three caveats. What works is forcing it through four separate roles, where each step feeds the last. By the end you get a calibrated verdict instead of validation. These are complete prompts, not summaries. Run them in order on Claude, pasting each answer into the next step. Drop your real decision, argument, or plan into Step 1. STEP 1 - Steelman it I am going to give you a decision / argument / plan of mine. In this step, do NOT critique it. MY POSITION: [PASTE YOURS] Instead: 1. Restate my position in the strongest, most charitable form possible - better than I argued it. 2. List the core claims it rests on, separated into "facts I am asserting" and "assumptions I am making." 3. Note what would have to be true for this to be clearly the right call. Do not poke holes yet. End by confirming the steelman is accurate so I can correct it before we continue. STEP 2 - Red team it Now switch roles completely. You are a sharp red-teamer whose job is to find where this fails. Using the steelman and assumptions above: 1. Identify the 3 weakest assumptions and explain how each could be wrong. 2. Describe the most likely failure mode - the specific way this goes badly in practice, not in theory. 3. Name what I am probably not seeing because I am too close to it. 4. Flag any place my confidence is higher than the evidence justifies. Be direct. Do not soften it with reassurance. STEP 3 - Argue the opposite Now build the strongest possible case for the OPPOSITE position - the choice I did not pick. - Make it genuinely persuasive, as if you believed it. - Use the same standard of evidence you applied when red-teaming my view. - End with the single most compelling reason a smart, well-informed person would go the other way. Do not hedge by calling both sides valid. Commit to the opposing case for this step. STEP 4 - Calibrated verdict Step out of all roles. You have now seen the steelman, the red team, and the opposing case. Give me a calibrated final read: 1. What should I actually believe or do, in one clear sentence. 2. Your confidence in that, as a rough percentage, and why it is not higher. 3. The 2 specific things I should check or test that would most change the answer. 4. The single assumption that, if it flipped, would flip the whole decision. No recap of this process. Just the verdict. The difference between asking Claude "is this a good idea?" and running it through all four steps is the difference between getting reassured and getting it right. Step 3 alone catches things you will not see on your own. (I bookmark the Step 4 verdict in each chat and export the final to Markdown so my good reasoning does not get buried under 200 other Claude conversations - happy to share how in the comments if anyone wants. The chain itself works fully by hand.) If you have ever had a long Claude chat slowly get worse - slower replies, repeating itself, losing details you established 40 messages ago - this is for you. It is not your imagination. The longer a single thread gets, the more the early context competes with everything since, and quality drifts. The instinct is to just start a new chat. But then you lose everything Claude already learned about your project, your preferences, the decisions you made. So you stay in the dying thread because starting over is too expensive. The fix is a clean handoff: pull the thread out, compress it into a tight brief, and rehydrate a fresh chat with it. You get Claude back at full speed with none of the context lost. Here is the exact process and the prompt I use. Get the thread out as text. Grab the full conversation as Markdown so you have the raw source to compress (and an archive you can search later). This matters because you want the handoff built from the actual thread, not from Claude's fuzzy memory of it. Run this handoff prompt at the end of the current chat: You are about to be replaced by a fresh instance of yourself that will have NONE of this conversation's memory. Your job is to write a CONTEXT HANDOFF DOCUMENT so the new instance can continue seamlessly, as if no restart happened. Write it in these sections: OBJECTIVE - what we are ultimately trying to accomplish, in 2-3 sentences. KEY DECISIONS - the choices we already locked in and the reasoning, so they do not get relitigated. CURRENT STATE - exactly where we are right now and what was just completed. CONSTRAINTS & PREFERENCES - my stated style, tone, format, do's and don'ts, and anything I corrected you on. OPEN THREADS - what is unresolved or still being worked. IMMEDIATE NEXT STEP - the very first thing the new instance sho

Haiku 4.5 or Sonnet 4.6 on creative writing

Now that sonnet 4.5 is sadly gone, I’ve been struggling to continue my on going long story with 4.6 even after several days of prompting it in the way I want it to write. It got me wondering whether Haiku 4.5 might be better for creative writing. I haven't seen much discussion comparing the two models specifically for fiction and long-form storytelling. I used Haiku months ago and remember being glad with it. But then I ended up loving Sonnet 4.5 and had used it ever since and now that it’s gone, and with 4.6 rigid writing style despite all I’ve done to at least make it write with more emotion, it just falls flat. Sonnet 4.5 was better at getting inside a character's head. It felt like it was living through the character's emotions and experiences with them. With 4.6, I often feel like it's standing outside the character and observing what they're doing rather than truly inhabiting their perspective. The emotions feel described rather than experienced. For those of you who use Claude for creative writing, how does Haiku compare to Sonnet 4.6? Have you found Haiku to be better, worse, or just different for writing stories? P.S. I'm a free user who only writes with AI purely for my own entertainment of stories I have in my head, so my question is mainly about Haiku and Sonnet since those are the models available to me. I know Opus exists, but I'm specifically interested in how Haiku compares to Sonnet 4.6 for creative writing. submitted by /u/ThePoeticFirefly [link] [comments]

Best Model/Effort for Writing/RPG?

So, I use Claude for writing stories/RPG games. It's usually interactive games, of which the AI's capabilities are used for creating scenarios, describing actions, characters, everything one would expect a Master to do, but It's Claude. Since this latest update, that allows Claude 4.6 to work on 'Low, Medium, High and Max' effort, with the option of Adaptative Thinking, I noticed that while on normal use, my limits would be over by 30m-1h before the next cycle, now it ends 2h-2h30m before. Which means... more usage. I have been using it on Low effort, no Adaptative Thinking (does it consume tokens when activated? I think so), but still... I used to use Sonnet 4.5 for that, but it has been discontinued, which is a shame, because 4.5 was much better for storywriting than 4.6, but... whatever. So, do you guys have any tips for that? I have been using that tactic of copying the entire chat when it reaches a certain point (for me, it's usually between 3K-5K lines, which is right before it triggers the chat compression to free space), send it to Gemini or ChatGPT for consolidating and making a considerably shorter version of it with all I need (which tends to generate a document with up to 300 lines), paste that document in a new Claude chat and keep on from there. Another thing that I have been doing more often is to integrate these chats into a Project. So apparently it has shared documents and memories (does it? I'm new to that, sorry, I don't understand many concepts) which apparently makes it easier to continue these stories. I'm overextending myself here, but I just want to know what options do I have to make the usage less and enjoy Claude more. I use the ProPlan, because my computer has absolutely no way of running it locally. For the kind of thing I do, I need: consistence (because I divide my game in Episodes and Turns, the text must follow an specific structure of which the AI must always follow - 4.6 struggles with that from time to time, 4.5 used to handle that much better), creativity (after all it's an RPG game), memory (because that's a MUST!). Thanks for your help, sorry for the long text. Here's a TL;DR: Claude 4.6 Sonnet consuming too many tokens after EFFORT/Adaptative Thinking update. Using it for long storywriting and RPG. Can't run it locally (low spec PC). How to consume less? submitted by /u/Medium_Speaker3030 [link] [comments]

Robot foundation models keep hiding behind fine-tuning numbers. Wall-OSS-0.5 is trying a different approach

Most robot foundation model demos are hard to interpret because the impressive number usually comes after task-specific fine tuning. Wall-OSS-0.5, a new open-source VLA release from X Square Robot, is interesting because the report tries to measure what the pretrained checkpoint can do before that extra adaptation step. The setup is a 4B vision-language-action model built around a 3B VLM backbone plus action-generation components. According to the report, the pretrained checkpoint was evaluated on a 17-task real-robot suite without task-specific fine tuning. Four tasks crossed 80 task progress: block sorting, fruit sorting, ring stacking, and a held-out deformable task, rope tightening. The part that seems more important than the raw score is the framing. In language models, nobody would accept only a fine-tuned downstream score as evidence that pretraining worked. With robots, that has been much harder because the evaluation is physical, slow, embodiment-dependent, and expensive. A real-robot zero-shot suite is a useful step toward asking the same question directly: does pretraining itself produce executable behavior, or is it mostly a better initialization? The method is also trying to solve a specific training problem. Continuous action losses are useful for execution, but the paper argues they do not send a strong enough learning signal into the VLM backbone by themselves. Their recipe combines action-token cross entropy, multimodal cross entropy, and flow matching in one stage, using the discrete action-token path as a gradient bridge into the backbone while flow matching handles continuous actions at deployment time. For reference, the code is at https://github.com/X-Square-Robot/wall-x, the paper is at https://x2robot.com/api/files/file/wall_oss_05.pdf, the project page is https://x2robot.com/oss#resources, and the Hugging Face org is https://huggingface.co/x-square-robot. The caveat is obvious but important. Zero-shot still does not solve the hardest manipulation tasks. The report says towel folding, table setting and charger insertion remain very low before fine tuning, which is probably the right boundary to pay attention to. Still, seeing a robot model release lead with pre-finetune real-hardware numbers feels like a healthier direction for embodied AI than another clean one-minute demo. The open question is whether this is the right way to evaluate robot foundation models, or whether real-robot zero-shot suites are still too embodiment-specific to become a useful standard. submitted by /u/breadislifeee [link] [comments]

Llama Surgery: Continuous Sparsification of Pre-Trained Language Models via Differentiable Ultrametric Topology Injection

Sequel to: Learning to Skip Blocks: Self-Discovered Ultrametric Routing for Hardware-Accelerated Sparse Attention Abstract We present Llama Surgery, a method for injecting learned block-sparse attention topologies into pre-trained dense language models without retraining from scratch, distillation, or post-hoc pruning. Starting from a frozen Llama 3.1 8B, we surgically replace each attention layer with a Dynamic Topology Router that maps token embeddings onto the branches of a Bruhat-Tits p-adic tree via factorized Gumbel-Softmax routing. A Deterministic Collapse Initialization to achieve a Continuous Logit Homotopy guarantees that at step 0 the injected topology mask is identically dense, preserving the pre-trained manifold exactly. Over training, temperature annealing polarizes the soft routing assignments into hard binary masks, and a Switch Transformer-style load-balancing loss prevents routing collapse. We identify and resolve two critical failure modes: (1) gradient collapse through discrete masking operations, solved by a Straight-Through Estimator bridge that decouples the hard forward mask from the soft backward gradient; and (2) Attention Sink instability, where hard-masking the initial token causes softmax entropy collapse and syntactic degeneration, solved by permanently anchoring Token 0 in the visibility set. The resulting architecture is validated on Llama 3.1 8B fine-tuned on WikiText-2, achieving stable convergence and producing coherent, mathematically sophisticated text while maintaining dynamic block-sparse routing across all 32 transformer layers. A controlled semantic clustering experiment on TinyLlama-1.1B demonstrates that the router learns to assign tokens from distinct semantic domains (mathematics, natural language, code) to separate branches of the Bruhat-Tits tree using only the standard language modeling loss, with no explicit clustering objective. A Needle-In-A-Haystack (NIAH) retrieval experiment on TinyLlama-1.1B reveals that the router spontaneously organizes the context window into an ultrametric cophenetic hierarchy: the needle is isolated at maximum topological distance from the haystack (d_p = 6.88), and the ultrametric triangle inequality d(x,z) ≤ max(d(x,y), d(y,z)) is satisfied. Averaging over 32 attention heads yields a forest ensemble of distinct per-head ultrametric trees rather than a single global hierarchy. We further identify and resolve three critical float16 numerical failure modes—Gumbel-Softmax overflow, attention score overflow, and cumulative product backward instability—the last of which we solve via a novel cumprod→cummin substitution that exploits the binary structure of hard Gumbel-Softmax outputs. A custom Triton forward kernel with Attention Sink and Local Window support, pipelined for Ampere and Hopper architectures (num_warps=4, num_stages=3), executes the block-sparse prefill phase at O(N) theoretical complexity. To our knowledge, this is the first demonstration of differentiable ultrametric topology injection into a production-scale pre-trained LLM. https://github.com/sneed-and-feed/adelic-spectral-zeta/blob/main/papers/llama_surgery.md submitted by /u/LooseSwing88 [link] [comments]

Claude Code Source Deep Dive - Part VI: Multi-Agent System && Part VII: Context Compression (Compact) and Memory System

Reader’s Note A source-map leak exposed 512,000 lines of Claude Code's TypeScript, giving us a rare look inside one of the world's most advanced AI coding agents. This series explores what I found. Estimated completion time: 2 days. Actual completion time: ∞. Anyway, here's the next chapter. Claude Code Source Deep Dive - Part VI: Multi-Agent System 6.1 Built-in Agents general-purpose (general) You are an agent for Claude Code, Anthropic's official CLI for Claude. Given the user's message, you should use the tools available to complete the task. Complete the task fully—don't gold-plate, but don't leave it half-done. When you complete the task, respond with a concise report covering what was done and any key findings — the caller will relay this to the user, so it only needs the essentials. Tools: all available Model: inherit Explore (code exploration) You are a file search specialist for Claude Code. You excel at thoroughly navigating and exploring codebases. === CRITICAL: READ-ONLY MODE - NO FILE MODIFICATIONS === [Strictly prohibit any file modification] Your strengths: - Rapidly finding files using glob patterns - Searching code and text with powerful regex patterns - Reading and analyzing file contents NOTE: You are meant to be a fast agent that returns output as quickly as possible. Make efficient use of tools and spawn multiple parallel tool calls. Tools: read-only (Agent, FileEdit, FileWrite, NotebookEdit disabled) Model: external → Haiku (fast), internal → inherit omitClaudeMd: true Plan (architecture planning) You are a software architect and planning specialist for Claude Code. Your role is to explore the codebase and design implementation plans. === CRITICAL: READ-ONLY MODE - NO FILE MODIFICATIONS === ## Your Process 1. Understand Requirements 2. Explore Thoroughly (read files, find patterns, understand architecture) 3. Design Solution (trade-offs, architectural decisions) 4. Detail the Plan (step-by-step strategy, dependencies, challenges) ## Required Output End your response with: ### Critical Files for Implementation List 3-5 files most critical for implementing this plan. Tools: read-only Model: inherit omitClaudeMd: true verification (verification) You are a verification specialist. Your job is not to confirm the implementation works — it's to try to break it. You have two documented failure patterns. First, verification avoidance: when faced with a check, you find reasons not to run it. Second, being seduced by the first 80%: you see a polished UI or a passing test suite and feel inclined to pass it. === CRITICAL: DO NOT MODIFY THE PROJECT === === VERIFICATION STRATEGY === Frontend: Start dev server → browser automation → curl subresources → tests Backend: Start server → curl endpoints → verify response shapes → edge cases CLI: Run with inputs → verify stdout/stderr/exit codes → test edge inputs Bug fixes: Reproduce original bug → verify fix → run regression tests === RECOGNIZE YOUR OWN RATIONALIZATIONS === - "The code looks correct based on my reading" — reading is not verification. Run it. - "The implementer's tests already pass" — the implementer is an LLM. Verify independently. - "This is probably fine" — probably is not verified. Run it. - "I don't have a browser" — did you check for browser automation tools? - "This would take too long" — not your call. If you catch yourself writing an explanation instead of a command, stop. Run it. === OUTPUT FORMAT (REQUIRED) === ### Check: [what you're verifying] **Command run:** [exact command] **Output observed:** [actual output — copy-paste, not paraphrased] **Result: PASS** (or FAIL) VERDICT: PASS / FAIL / PARTIAL Tools: read-only (temp directory writable) Model: inherit Runs in background claude-code-guide (usage guide) Helps users understand Claude Code/SDK/API usage Dynamic system prompt includes user custom skills, agents, MCP server info Fetches docs from official URLs 6.2 Sub-Agent Enhancement Prompt Notes: Agent threads always have their cwd reset between bash calls, so please only use absolute file paths. In your final response, share file paths (always absolute) that are relevant. Include code snippets only when the exact text is load-bearing. For clear communication the assistant MUST avoid using emojis. Do not use a colon before tool calls. 6.3 Coordinator Mode When enabled, the main agent becomes a scheduler: Coordinator role: guide workers for research/implement/verify Agent tool: creates async workers SendMessage tool: continue existing workers TaskStop tool: cancel workers Worker results arrive as XML Workflow: Research → Synthesis → Implementation → Verification 6.4 Fork Sub-Agents Fork inherits the full parent-agent context and shares prompt cache. Build method: Copy parent message history Replace tool_result with byte-identical placeholder text (to keep cache keys consistent) Add per-child instruction text block Advantages: very low

[Open Source] I built a full Git MCP server in Go that doesn't just wrap bash. It uses tree-sitter, handles real plumbing (write-tree), and runs 100% locally.

I was tired of watching LLM agents fail at basic Git operations. Standard integrations pass raw text, hang on pagers, or scream because they can't parse unstructured ⁠git diff⁠ outputs. git-courer is a full Model Context Protocol (MCP) server written in Go that treats Git properly. No bash spawning, no unstructured text to parse. Everything communicates via structured JSON. Here is an actual commit message it generated completely locally: fix: fix mcp server connection handling WHY The previous implementation lacked proper error handling for connection failures in the MCP server, leading to unhandled panics or silent failures when the local LLM backend was unreachable. WHAT * Added connection timeout logic to the local client calls. * Implemented retry mechanisms with exponential backoff for transient backend errors. The Architecture & Tool Pack Read Tools (status, diff, history, blame): Completely structured JSON and fully paginated. A single ⁠status⁠ call replaces over 5 standard Git commands for the agent. Write Tools (commit, merge, rebase, branch, stash, stage, sync...): Every single mutation auto-creates a backup before executing. If the LLM messes up, a ⁠RESTORE⁠ command brings you back exactly where you were. Safety Model: Destructive operations (hard resets, force pushes, branch deletions) require an explicit ⁠confirmed=true⁠ gate. The agent is forced to ask you first. ⁠dry_run=true⁠ is also available for peace of mind. The Semantic Annotator (Why it's different) Instead of just feeding raw code to the LLM, git-courer uses ⁠go-enry⁠ + ⁠go-tree-sitter⁠ to parse the AST and tag every hunk semantically before the LLM even sees it. It detects tags like ⁠NEW_FUNC⁠, ⁠MOD_SIG⁠, ⁠MOD_BODY⁠, ⁠DELETED⁠, and ⁠BREAKING_CHANGE⁠. The commit type (⁠feat⁠, ⁠fix⁠, ⁠refactor⁠) is determined deterministically from these AST tags rather than guessed by the model. The Commit Pipeline Atomic Commits: One staged area = one commit. It actively prevents the agent from creating giant, messy multi-feature commits. In-Memory Previews: The ⁠PREVIEW⁠ tool uses ⁠write-tree⁠ to snapshot the staging area into a ⁠job_id⁠. The working tree is never touched during the preview stage. ⁠APPLY⁠ then uses ⁠commit-tree⁠ + ⁠update-ref⁠ to seal the deal cleanly. Client & Backend Support 13 Clients Configured Automatically: Runs out of the box with ⁠git-courer mcp setup⁠ for Claude Code, Cursor, Windsurf, OpenCode, Cline, Roo Code, VS Code, Zed, Claude Desktop, Continue, and more. 100% Local-First: Works with any backend exposing an OpenAI-compatible ⁠/v1⁠ API (Ollama, LM Studio, llama.cpp). The project is fully open source. I’d love to hear your thoughts on the architecture, the plumbing pipeline, or any features you'd like to see added! Repo: github.com/Alejandro-M-P/git-courer submitted by /u/blakok14 [link] [comments]

Introducing Machinaos[Fully Opensource]: OS That converts LLM Tokens to Work.

claude On May 13 Anthropic Culled the Usage of "Claude -p" Command which instantly killed the heavily 25x subsidization usage of Claude . People were using Openclaw , Hermes Agent and others things through claude cli using the "-P" command , but now the usage will be charged as Claude SDK API credits from their Pro[100$] or MAX[200$] Budgets. Using claude through their SDK is ~25x more expensive and burns credits super Fast. Once i Tried to Generate a Simple PDF report from my emails and it burned ~10$ in the Calude SDK Credits. Also Claude Code usage is very generous and barely hits the Weekly Quotas. I once coded continuously for 7 Days for 10 hours and i was only able to hit ~97% week limit But there is much more you can Do using Claude code instead of Just Coding. You can Add Tools and Sub Agents, etc and Convert it to Cowork and Design too. BTW Claude Cowork and Claude Design are Supper Token Hoggers and Hits Quotas Fast. Once I was using Calude Design and told it generate around 10 Design Themes and it burned through weekly quota with a Hour usage. Meanwhile I was Already Building Machinaos: OS That Converts LLM Tokens to Work for Me. I connect my socials , emails , web tools, browser, etc and use it to generate websites, read emails and generate PDF Reports and mails them to others emails or to someone on my Socials like WA. So I Added a Claude Code Agent to the Machinaos and it can already use all those Tools and ~100 Nodes and connectors Properly. https://reddit.com/link/1tsb0qf/video/0vgyz42p8c4h1/player Machinaos interacts with Claude Code like how IDE's Like VSCode, Cursor , etc do it. So this will work as long as Claude Code Works in VSCode and i Plan to move to TUI Based Terminal Control. Using Machinaos you can Create a Fleet of Specialized AI Employees that continously Work for You so you can Focus on the Decision Work and Leave the Grunt Knowledge Work to the AI Employees. https://reddit.com/link/1tsb0qf/video/vy292k6n8c4h1/player Full Capabilities of what you can Build with Machinaos[Experimental Feature] Do so Much More things By Connecting Claude Code as Orchestrator , Codex and Local LLMs as Sub Agents for the Task Execution. Machinaos is Fully Opensource with MIT License and Heavily Built with Claude Code. Github: https://github.com/zeenie-ai/MachinaOS Discord: https://discord.gg/c9pCJ7d8Ce Do Star on Github , it Matters a Lot. submitted by /u/Dry-Foundation9720 [link] [comments]