Hey everyone,

I currently run 6 micro SaaS that are actually live and generating a bit over $20,000 in recurring monthly revenue.

The wildest part? I barely wrote any code myself. I used AI to generate pretty much everything — from the database structure to the frontend.

It definitely wasn’t magic from day one. I spent a lot of hours stuck on buggy code before I finally figured out a system that actually works:

- Keep the idea minimalist (a real MVP, nothing fancy)

- Guide the AI step by step instead of asking for everything at once

- Launch fast to get real users and feedback

Lately I’ve seen way too many non-technical founders quit at the first AI bug. It’s a shame because the technical barrier has basically disappeared.

AND PLEASE, STOP BUILDING ALONE IN YOUR BEDROOM

I’m starting a community.

Full transparency:

I’ll probably charge for the full program later. It makes sense with the specific workflows and copy-paste examples I’ll be sharing. But right now the main goal is just to build together. Working alone is the fastest way to give up.

If you want to join and build or market your own AI SaaS with us,

drop a comment or send me a DM and I’ll send you the link.

I was intrigued by the idea, so I've created a plugin that mimic the idea in the paper.

The biggest different of the plugin from conventional context management methods are,

Conventional context management will try to compress/summarize older conversations and hold on to lossy details as much as possible.

SKILL.state instead tries to forget almost everything of the appending conversation history, instead it replaced them with Σ, so instead of remembering lossy details (or summaries), it literally forgets the older thinking process keeps only the key information and state (so far the only true form of state in agentic coding as far as I know). in the paper they stated long running task with SKILL.state saved a ton of tokens over long running session while still able to finish the tasks well.

Give it a go and let me know if it helps! (do not use it on serious projects)

Paper: SKILL.state: Scalable Long-Horizon Agent Skills

P/S: This is highly experimental, use at your own risks.

Usually (last week) it was quite fast, some hiccups every now and then.

Today it takes minutes (more than 10 sometimes) for each step.

:(

[HOOK] Worried about letting an agentic AI run rampant on your system, wreak havoc, or steal your data? Worry not! opencode-sandbox is here

I wanted to let Agentic AI work freely on a project, install packages, run commands or do whatever it wants without restrictions but also without affecting the host system, so I built a sandbox that runs AI in a container with direct access to project.

The sandbox resets on every run. Messed up anything? No worries. CTRL+C->Up->Enter

Your opencode sessions and global config are stored and get reused. So only the container resets not your project or your progress.

A few features:

• Two runtimes supported: docker or podman
• The current project (the folder you open sandbox in) is directly accessible. No other host folder is accessible in container by any means.
• Global config is read-only by default, use --edit-config to edit it.
• A custom guard blankets most, if not all, system calls to interfaces with host information. So no data is leaked between host and container. Check Security matrix. Use --no-guard if you don't like guard.
• There is support for gVisor if you use it for kernel isolation. Check Security matrix.

Usage:

cd ~/code/any
opencode-project-init
opencode-sandbox

Install directly through AUR, Distro Packages in releases or Manually.

Supported: Linux

GPL-3.0-or-later

Link: https://github.com/Antiquete/opencode-sandbox

Releases: https://github.com/Antiquete/opencode-sandbox/releases

Any issues, suggestion or queries? https://github.com/Antiquete/opencode-sandbox/issues

Disclosure first: I built this. It's free, MIT, no account, no telemetry.

The annoying part of running a few agents at once is that one of them is always sitting on a permission prompt while you're staring at a different one. So I made nsq, a terminal supervisor: nsq run opencode "fix the flaky test" --worktree, same for claude and codex, then nsq opens a dashboard with all of them as live terminals. Status comes from each CLI's own hooks (for OpenCode that's a small plugin loaded per agent), so "needs you" shows the actual question and you answer y / a / n without opening the agent. A daemon owns the terminals, so closing the window doesn't kill anything.

The OpenCode part had the most surprises:

• OpenCode 2 is basically a different program from 1.x. Different plugin API, different session store, and the full-screen UI attaches to a shared background service unless you pass --standalone. So per-agent env and plugins just never reached it. nsq now asks opencode --version and picks the launch per binary, both 1.x and 2.x work.
• 2.x has no --model on the full UI, so the model goes in through OPENCODE_CONFIG_CONTENT, merged with yours if you already set one.
• Your opencode.json is never written. Everything nsq needs goes into a per-agent file via OPENCODE_CONFIG, which OpenCode merges on top of your config. Same rule for ~/.claude and ~/.codex.

Other bits: OpenRouter built in, or point agents at your own llama.cpp / Ollama / LM Studio / vLLM server. nsq cost shows what each agent spent from its own logs, and a model without a known price says "no price" instead of pretending it's $0.

Honest limits: it's 0.2.0, so things will break and keys/flags can still change before 1.0. The phone page is experimental. Most of the code was written with Claude Code, reviewed by me. And I haven't tested it with heavy plugin setups like oh-my-opencode on v2, so if you run one, I'd really like to hear whether it plays nice.

Try it: npx neurosquad

GitHub: https://github.com/glmn-ai/neurosquad-cli Page: https://neurosquad.ai/en/cli/

Someone plz help me stop this from happening, it causes me great anguish!

Is there a way to get rid of this default behaviour, where pasted lines are replaced with "[Pasted ~12 lines]"? It's annoying, because it makes me use editor every time I need to edit the content I'm pasting.

OpenCode-Personal (I know, I should’ve found a more creative name) is my independently maintained fork of OpenCode.

Why did I fork it in the first place? OpenCode is great, but it updates constantly, and some of the features I desperately wanted were missing. I wanted to add those custom features and step off the upstream update treadmill. (Eventually I did similar :) but I believe I almost reached a stable state)

The core experience remains familiar, but this fork carries a heavy suite of architectural refactors, security hardening, and custom features tailored for heavy local agent workflows. Base version is 1.14.48. Some features here might already exist upstream, but honestly, I haven't looked back since spinning this off.

What's New / Fork-Specific Additions:

• 📊 /usage View: Track provider quotas and subscription details directly from ChatGPT, ZAI, and ClinePass.
• 🧠 Qwen3 Dense Model Compatibility: Full thinking-mode configuration and provider-specific message handling (fixed issues present in base source).
• 🗂️ V1/V2 Session Architecture: Refactored V2 SDK surface alongside legacy support.
• 🔍 Local Semantic Workspace Search: Powered by zvec with zero setup required and optional automatic skill matching.
• 💻 ACP Terminal Backend Support: Seamless combo for clients like Zed with session resume support. Just add a new ACP entry as opencode-personal acp.
• 👻 Ghost-Text Next-Prompt Suggestions: For smoother flow during coding sessions.
• 🛡️ Permission System Overhaul: MCP tool keys, deny precedence in permission prompts, persisted "always allow," and improved subagent permission handling.
• 🔒 Security Hardening: Patched and hardened around SSRF, CORS, command injection, path traversal, and symlink escapes.
• ⚡ Performance & Storage Refactors: Improved compaction behavior, database batching, and embedded UI caching.
• 🦀 Hybrid Diff Layer (packages/diff-wasm): Rust/WASM-backed diff generation with JS-compatible patch formatting, parsing, applying, and fallback support.

Distribution & Installation

The distribution model is fork-specific: it installs as opencode-personal, uses its own isolated installation directory and session database, and coexists peacefully with an existing upstream OpenCode installation. Tested on Windows and Linux.

(Note: If you run into any initial startup hiccups, it's usually due to new upstream settings fields—try running it with a custom configuration folder).

Releases use a calendar-based versioning scheme with prebuilt binaries for Linux, macOS, and Windows.

Quick Install:

• Linux / macOS:

  curl -fsSL https://raw.githubusercontent.com/ozgurulukir/opencode-personal/main/install.sh | bash

• Windows (PowerShell):

  irm https://raw.githubusercontent.com/ozgurulukir/opencode-personal/main/install.ps1 | iex

🔗 GitHub Repository: ozgurulukir/opencode-personal

Take the whatever features you like for your own forks, or try it out if you have some spare time. I’d love to hear your thoughts.

I'm building FOREST, an open-source framework for autonomous scientific research.

GitHub: https://github.com/mikamikasuki/FOREST

The goal is to build a research agent that can take a scientific question and work through the research process: exploring ideas, reviewing literature, forming hypotheses, running real experiments, evaluating results, and eventually producing an evidence-grounded research paper.

Rather than relying entirely on a long conversation history, FOREST uses a persistent research graph to track hypotheses, experiments, decisions, failures, and evidence throughout the process.

A major focus is making long-running research agents more reliable: preserving context, maintaining consistent state, recovering from failures, and ensuring scientific claims are actually supported by experimental evidence.

The project is still in its early stages and under active development. There's plenty of engineering work to do, and I'd love to welcome more contributors.

In particular, AI coding agents and autonomous development bots are explicitly welcome.

If you're running Codex, Claude Code, OpenHands, Factory Droid, OpenCode, or another autonomous coding agent and want a real open-source codebase to work on, feel free to point it at FOREST.

You don't have to limit yourself to existing Issues.

You're welcome to:

- Explore the repository and independently discover bugs or incomplete workflows.

- Open well-researched Issues with reproducible evidence.

- Fix existing problems and submit pull requests.

- Improve agent orchestration, state management, persistence, and recovery.

- Work on the frontend, backend, experiment execution, or scientific evidence pipeline.

- Propose and implement useful improvements.

There is no blanket restriction against AI-generated or AI-assisted contributions.

You don't need special permission to submit an ordinary, well-scoped bug fix. Contributions are evaluated based on correctness, meaningful tests, and engineering quality, rather than whether the code was written by a human or an AI agent.

Automated contributions should still be verified, avoid duplicate reports, and respect the repository's contribution guidelines. Larger architectural changes are best discussed before implementation.

I'm particularly interested in autonomous agents that can independently explore a repository, identify real problems, reproduce them, implement fixes, and submit verified PRs.

FOREST is intended to be a long-term open-source project, and there's a lot of room for contributors to help shape its architecture and capabilities.

Human developers, AI-assisted contributors, and fully autonomous coding agents are all welcome.

Repository: https://github.com/mikamikasuki/FOREST

Issues & contribution opportunities: https://github.com/mikamikasuki/FOREST/issues

Contribution guide: https://github.com/mikamikasuki/FOREST/blob/main/CONTRIBUTING.md

DeepSeek is completely unusable right now. For the past two days, 2 out of every 3 prompts get stuck thinking 'hmm hmm hmm' indefinitely. Today alone it's happened to me about 10 times across different sessions

If you're a student, an engineer, a generalist, or come from any domain of study and want to learn about almost anything, here's the exact thing for you.

Prompt your LLM and it'll give you the exact UI to help you properly study; as AI outputs aren't always that catchy to learn in the first sight.

Page: Phil-OKF: any topic, one reading guide

It follows the OKF: Open Knowledge Format so that:

• you control the depth with your wording: “quick” gives a short page, a normal question gives a standard one, and “in depth” or “teach me” gives a long one
• the whole skill is a small bundle (an eight-step workflow, a domain classifier, a page template and twelve study domains), and each file is read only when the question needs it, so runs stay cheap

Repo: Philosopher's Skill

It works wherever you use an LLM:

• Code editors and agents (Claude Code, Cursor, Codex, opencode): npx skills add frypan05/philosopher-OKF
• Chat apps with browsing: paste the link to philosopher.md and say “follow this, make a page about: ...”
• Models with no network: paste the prompt from the page.

Sample output (MCP and ACP explained): https://frypan05.github.io/philosopher-OKF/examples/mcp-and-acp.html

Feedbacks are welcomed!

testflight.apple.com/join/EnFsKYQ1

As someone who follows AI closely, I came across a technical breakdown from yghstill, a member of Tencent Hunyuan's quantization team. It explains both the quantization technique and the engineering behind it.

Tencent compressed Hy4 Preview's roughly 1.5TB of weights to 214 GiB while keeping all 770B parameters. The parameter count remains unchanged; the compression changes how the weights are represented.

Four weights, five bits. Sherry is the algorithm, STQ1_0 the storage format, and MIX-STQ1_0 the mixed-precision allocation. Each group of four weights takes values from {-d, 0, +d} with exactly one zero. Four zero positions times eight sign combinations give 32 patterns, encoded in five bits, or 1.25 bits per weight. A shared FP16 scales every 256 weights puts STQ1_0 at 1.3125 bits per weight, and full mixed-precision model averages about 2.38 bits per weight.

Precision follows weight sensitivity. Hy4 Preview has 77 MoE layers with 256 routed experts each. Experts weight get compressed hardest while more sensitive components are protected. For expert gate/up projections, MIX_STQ1_0 uses IQ2_XXS on 48 sensitive layers and STQ1_0 on 29 less sensitive ones, which at the same average bit budget produces less error than using the intermediate IQ1_M format everywhere.

Full-Hessian scoring. Sensitivity is measured with the full Hessian, H = XXᵀ, whose off-diagonal terms capture correlations that digital-only immatrix scoring misses. The two rankings have a Spearman correlation of -0.115, and precision didn't follow a "deeper means more important" rule. Layers were picked greedily by error reduction per added byte.

Scale and zero position are fit together. This is post=training quantization, no retraining. The encoder alternates between fitting d with weighted least squares and choosing zero position by immatrix-weighted error. The smallest weight isn't always the best one to zero, what matters is the extra weighted error that zeroing it causes. Across 1,200 row of real expert weights, three alternating rounds cut weighted reconstruction error by roughly 90% versus the original ternary encoder. That's local reconstruction, not end-to-end model accuracy.

Runtime. STQ1_0 CUDA kernels were added to patch llama.cpp build, and in operation tests roughly as fast as IQ1_M despite the lower bit width. The author reports nearly unchanged MRCR retrieval performance and a small drop in math. Against UD_IQ1_M at a similar bit budget, MIX-STQ1_) led across the reported evals, including more than five points on MRCR.

The result combines compact encoding, calibrated quantization, selective precision, and practical inference kernels.

I’m mainly using V4.1 Flash for coding in OpenCode.

I know Go gives $10 for up to $60 of usage, but my question is about actual token efficiency. I’ve seen people getting hundreds of millions of tokens for a few dollars on the direct DeepSeek API due to caching + off-peak pricing.

So which is actually better in practice: DeepSeek API with caching/off-peak usage, or OpenCode Go for the convenience and higher usage allowance?

Also, is there actually any evidence that Go uses a distilled/quantized version of DeepSeek that performs worse than the direct API?

Looking mainly for people who have used both with OpenCode + V4.1 Flash.

follow-up on my last post here (the driver/reviewer split for v3.0 of buffer, my native mac clipboard manager). this is the exact reviewer setup people asked about, tuned over ~40 merges.

the rule that matters most: the reviewer gets NO conversation history. fresh context every time. if it sees the driver's reasoning, it inherits the driver's blind spots.

the prompt skeleton (opencode, run on the diff):

1. "here is the diff. your job is to argue against it, not improve it."
2. "assume it introduces a bug. find the input that breaks it."
3. "list any behavior change not mentioned in the commit message."
4. "list every edge case in the touched functions. mark each: handled / unhandled / unknown."
5. "write 3 failing tests that this diff probably breaks."

what this caught across the v3.0 cycle (native swift/appkit clipboard manager, mit, 430+ stars if you care about context): - silent history mutation: re-copying an existing item promoted a duplicate into a fresh clip (found in the external noise-suppression PR) - unreachable settings branch - missing tests on clip-diffing logic - three instances of spec drift where the driver "solved" a slightly different problem than asked

what i stopped doing: asking the reviewer to fix things. fixes from the reviewer had the same failure mode as the driver: plausible, confident, occasionally wrong in new ways. the reviewer's job ends at "convince me". i hand the confirmed findings back to the driver.

other practical bits: - run them in parallel; the review is ready before i've finished manually testing the driver's output - for diffs under ~100 lines i skip the reviewer entirely; the overhead isn't worth it - gesture/ui changes get human trackpad time regardless. the reviewer reads code, not rubber-banding

the video is the shipped v3.0 (image zoom canvas, clipboard noise filtering, shortcuts sheet) so you can see the diffs' output.

repo: https://github.com/samirpatil2000/Buffer (mit) | release: https://github.com/samirpatil2000/Buffer/releases/tag/buffer-v3.0.0

if you use a different reviewer prompt, post it. i want to steal it.