I haven't seen any new app store analytics data since May 1. I updated screenshots and added new features. However, the data hasn't been updated for 3/4 days now.
Is anyone else facing similar issues?
https://apps.apple.com/us/app/dictawiz-voice-to-text/id6759256382
DeepSeek V4.1 Flash at Q2 is 341 GB on disk: 152 GB of weights plus 189 GB of Engram tables. My Mac is an M5 Max with 128 GB. It runs anyway, because ds4 streams the experts from SSD, and stock ds4 gave me around 12 tok/s on the CLI. Usable. But I had the feeling the SSD wasn't the only thing holding it back, so I started poking at it with a coding agent, and that turned into something bigger than I planned.
The first thing I noticed is that every session began the same way: the agent re-reading huge chunks of ds4.c (85k lines, three model families, three GPU backends) to figure out which 2% of it my model actually goes through. Most of what it read was about hardware I don't own and models I don't run. So I deleted all of it. Not #ifdef, deleted. ds4.c is 34k lines now, the whole tree 150k instead of 278k. Only DeepSeek V4.1 Flash, only Metal.
That changed the economics of trying things. An optimization attempt that used to cost me an afternoon of the agent wandering around now costs maybe an hour, so I tried a lot more of them and measured every single one instead of picking the three I believed in.
One rule the whole time: output doesn't change. Every change has to produce the same tokens as upstream ds4 on the same GGUF (greedy, ten prompts), and pass an A/B/B/A bench against the previous build with the logits compared bit for bit. No KV quant, no approximate kernels. If it's faster but a logit moved, it doesn't go in.
This is where it landed, internal SSD only, same GGUF, same flags, upstream's own bench (ds4 → fork):
- generation, ctx 2048 (128 tokens, first one included): 12.1 → 24.4 tok/s
- steady decode, ctx 2048: 15.7 → 25.7 tok/s
- steady decode, ctx 32768: 15.7 → 22.0 tok/s
- prefill, 16k → 32k context: 404 → 636 tok/s
- first token after a prefill: 2.1–3.0 s → 0.3–1.1 s
None of it is clever. Decode layers get committed to the GPU without waiting for each other. Expert reads are split across a thread pool and the cache slabs sit in a Metal residency set. A handful of kernel fusions per decode token. Prefill reads the next layer's experts while the current layer computes. Individually each one is a small diff you can read in a few minutes. Together they double the speed, and you get all of this with the Mac as it is, nothing to buy.
Then I got curious about the SSD part. Streaming is bound by read bandwidth and a Mac has exactly one internal drive, so I put a byte-identical copy of the GGUF on an external Thunderbolt 5 SSD and made prefill read part of every layer from each drive at the same time. The engine checks the copy against the model at every start (about 7 s) and refuses to run if anything differs, because I don't trust myself to keep two 341 GB files in sync by hand.
Internal SSD only → with the external copy:
- 3.5K-token prompt, time to first token: 13.2 s → 11.2 s
- 10K-token prompt: 29.0 s → 25.0 s
- +1.5K tokens appended to a 5.3K chat: 8.6 s → 7.0 s
- first token after an 8K context: 1.38 s → 0.18 s
Decode doesn't change, it never reads the copy. My enclosure also runs the drive at PCIe 4.0 x4, about half of the internal SSD, so a better enclosure should do better than this. Nice side effect: the KV cache can write to the external drive, so the soldered internal SSD takes zero writes while the model runs. Again: this part is optional, the table above it is the one that matters for most people.
About staying in sync with ds4, because that was my main worry: the fork never renames the ds4_* files, every cut is marked in the source at the exact spot, and git merge upstream/main with rerere replays the conflict resolutions. After each merge the parity check tells me if the tokens still match. So far antirez's fixes have kept flowing in without drama.
Not everything worked. I tried to bring the two-SSD trick back into upstream ds4 through its mmap path: bit-exact, but prefill got 13–38% slower and I still don't know why, so no PR for now. Twenty-odd other ideas were measured and dropped. I keep all of them in a "rejected ideas" table in the repo with the numbers, mostly so the agent (and I) stop re-proposing the same thing every other week.
There's a growing trend of single-model inference engines, and ds4 itself started that way. This is just that idea pushed a bit further, one model and one backend, and at least here it holds up: faster, still correct, still merging upstream. I've done four of these forks, one per model; the procedure is in a separate repo (StarForge) and has nothing DeepSeek- or Metal-specific in it.
Repo: github.com/Chida82/sf-ds4-1flash. The README and speed-bench/perf-record.md have the conditions behind every number.
A few things I'd like to hear opinions on:
I wanted ChatGPT to work with my real local projects without constantly copying files back and forth. RepoTunnel lets ChatGPT read/edit files, run commands, inspect code, debug problems, use Git, and work directly with approved projects on your computer. It works through your own HTTPS endpoint, and RepoTunnel itself adds no monthly connection/request quota. You can keep using your existing ChatGPT conversation without buying a separate OpenAI API key. GitHub: https://github.com/Yashwanth034/RepoTunnel Would love feedback from developers — especially what you’d add or improve.
Since May I've been building a desktop agent that works in a folder you pick: it reads the files, writes new ones and asks before it changes anything. It started as a way to understand how Claude Code works, and about half of the commits were then written with Claude Code.
People keep asking how it compares to Cowork, so here's the honest version.
**Cowork is better at:** frontier models, finished Office documents, scheduled tasks while your laptop is off, isolation on every platform, and a big ecosystem (connectors, sub-agents, computer use). If you need that, use Cowork.
**Where mine differs:**
* Open source (Apache 2.0), no account, no telemetry.
* Any model per conversation: Claude with your own API key, OpenAI, Google, or local via Ollama, LM Studio or MLX. With a local model, your files never leave the disk.
* Asks before every change; shell commands are off until you switch them on.
**What it can't do yet:** no sandbox on Windows, unsigned builds, text files only, nothing runs while the app is closed.
If you use Cowork: what would you miss first without it?
[https://github.com/kkrafft1999/snotra\](https://github.com/kkrafft1999/snotra)
Something I keep running into: token pricing is a clean, understandable unit, and it works well for chat. It maps badly to agents.
For a chat product the model is basically linear:
You can forecast that. You know your DAU, your average prompt/completion size, and you get a number that holds within a reasonable band.
An agent task is a different shape:
The number of model calls per task isn't fixed. It's a distribution with a long tail, and the tail is where the money goes. A handful of pathological tasks (tool loops, retries, a sub-agent that keeps re-planning) can cost more than thousands of cheap ones. "Cost per token" tells you the unit price; it doesn't tell you what a task costs, and tasks are the thing you're actually selling and budgeting for.
Is per-task cost predictability actually solvable, or is the tail just inherent to autonomous agents and you plan around it?
Interested in how people running agents continuously think about this — especially anyone who's had to explain agent spend to a finance person.
Frontman is for a specific problem: AI coding agents often edit frontend files without seeing the running app, built for technical people.
Why try it:
- select/click UI before asking for edits
- agent gets DOM, screenshot, logs, routes, source mappings
- works with Astro, Next.js, Vite, WordPress
- open source
Latest release added Astro content collections support.
And it's fully OSS, self hostable etc
Hey everyone,
I got pretty tired of cloud-based AI automation tools that meter every single action and charge crazy per-token fees, so I built an alternative called Arrow.
The idea is simple: instead of renting an agent in the cloud, you own it entirely on your machine.
How it works:
Record: Capture a desktop sequence or browser flow once.
Compose: Connect nodes into a visual workflow graph (you can branch, loop, and drop in local LLMs, vision, OCR, or code nodes).
Run: Execute deterministically using element-first grounding with small local models.
It runs completely locally with no cloud dependencies and zero telemetry.
If you want to check it out, you can see the project overview here: https://rodrigobenitez343.github.io/Arrow-online/index.html
Hello, i'm currently developing CrowdGPT and i need people who enjoy opensource AI and LLMs to test the project :)
The goal of CrowdGPT is to create the first, datacenterless, 1 Billion parameters LLM, relying on people contributing with their own computer to train the AI model. My goal is to show you don't need insane infrastructure to train a working almost commercial grade LLM. Everything is open and 100% opensource.
You can learn more at https://crowdgpt.net
Or check the github: https://github.com/Vxtzq/CrowdGPT
Any kind of feedback is appreciated!
Here is my current project status, it has become quite extensive in the meantime.
https://github.com/unikum-sol/brainstem/blob/main/Project\_Status\_2026-09-28.md
I look forward to feedback and discussions.
Here is a small excerpt:
„BrainStem is a self-learning language-understanding system designed to acquire sentence-, word-, and relation-level structure from an unsegmented text corpus purely through statistical observation, without word lists, grammars, or filters. The system’s stated design principle is that every unit of knowledge, a sentence-level hypothesis, a word boundary, a relation between two entities, a category, or a question, begins as a low-confidence, fully correctable hypothesis, and only becomes a durable fact, relation, category, or question after surviving a multi-cycle, neuromodulator-gated consolidation process modeled on biological sleep-dependent memory consolidation.”
We are designing an evaluation for a structural code-access layer used by coding agents.
The three configurations are:
We believe the benchmark needs to measure more than task completion:
- Pass rate.
- End-to-end wall-clock time.
- Input and output tokens.
- Tool-call count.
- Bytes returned to the model.
- Repository exploration before the first edit.
- Repeated retrieval of the same context.
- Unexpected files and entities changed.
- Validation and retry count.
- Cold versus warm index performance.
- Unsupported-language fallback correctness.
One lesson so far is that measuring index-query latency alone is misleading. A 7 ms query does not guarantee a faster session if the model performs additional calls or ignores the result.
Our implementation is Sem:
https://github.com/Ataraxy-Labs/sem
What controls or failure cases would you require before accepting claims of token or session-speed improvement?
From one of our Mods the one and only u/soundDR
Description from the video:
In this walkthrough, we use Antigravity 2.0 to build two complete custom automations across the Chrome and local OS.
Prompt: Act as an expert Chrome Extension developer and build a Manifest V3 extension that automatically organizes unpinned tabs into native Tab Groups based on their last-accessed time. The time buckets must be exactly: Today, Yesterday, This Week, Last Week, This Month, Last 90 Days, and Archived, calculated strictly using the user's local timezone. When a tab becomes active, its timestamp should update via TTL logic and it should immediately move to the 'Today' bucket. This organization logic must be isolated per window (no cross-window tab moving) and must maintain a stable, fixed left-to-right visual sorting of the tab groups. Persist all tab timestamps using 'chrome.storage.local' to survive browser restarts and Service Worker suspension. Ensure you ignore pinned tabs entirely, and heavily debounce the 'chrome.tabs.onActivated' and 'onUpdated' listeners to prevent Ul flickering and Chrome API rate limits. Please output the complete 'manifest.json' and the 'background.js' service worker code.
Subscribe to Google Antigravity → / @googleantigravity
Google Antigravity is an agentic development platform, evolving the IDE into the agent-first era. Antigravity enables developers to operate at a higher, task-oriented level by managing agents across workspaces, while retaining a familiar AI IDE experience at its core. Agents operate across the editor, terminal, and browser, enabling them to autonomously plan and execute complex, end-to-end tasks elevating all aspects of software development.
To learn more: Website: https://antigravity.go... X: https://x.com/antigravity LinkedIn: / google-antigravity
Sharing what we released today, everything is open.
What it is
Credit first: Kyojin is built on turboderp's ExLlamaV3, and the AMD side starts from vcruz305's and sdougbrown's ROCm ports. We added the decode and prefill kernels for this chip and the serving for these two models.
Numbers, one 128 GB machine
Reproduce it: the repo has a quickstart and one benchmark script. If you own a Strix Halo box, run it and post your numbers, good or bad. That's the feedback we need most.
Engine: https://github.com/Yamz-Labs/kyojin
Weights: https://huggingface.co/yamz-labs
Next: Qwen 3.8 Flash on the same engine.
TL;DR: built an agent runtime that stores state as a belief graph with dependencies (Jon Doyle's TMS) instead of chat logs. correct one fact and everything downstream auto-updates without context rot or full re-runs. (repo link in the comments below)
Hey guys,
Every agent framework ive used so far handles state pretty much the same way, just appending messages to a long chat log. The problem is long running agents rot super fast. If a tool returns bad data at step 3, that error just sits in context forever. And if a key fact changes mid run, you either have to wipe the whole context or re run everything from step 1.
I’ve been hacking on an open source project called Corollary to try a different approach. Instead of a message transcript, it stores state as a belief base backed by a truth maintenance system (basically an old concept from jon doyle back in 1979).
how it works under the hood:
its still super pre-alpha so I'd love to get some feedback, pushback or edge cases you think this pattern will hit.
(repo link in the comments below)
how are you guys handling context rot in long running agents currently?
