I built runNburn, a Rust-based, memory-aware GGUF inference runtime designed to run models that do not fit entirely in fast memory.
On an Apple M5 Pro with 64 GiB unified memory, runNburn ran the 84.682 GiB DeepSeek-V4-Flash-0731 UD-IQ2_M. On the same 1,119-prompt-token/100-completion workload, generation took a median 83.536 seconds versus 249.325 seconds for llama.cpp's viable partial-Metal path: 2.98x as fast, with prefill 3.62x as fast. llama.cpp retained a 9.38% decode-throughput lead, and its default auto-fit path OOMed, so this is not a blanket engine-speed claim.
On a Galaxy Z Flip4, runNburn ran Qwen3.6 35B-A3B Q4_K_M with MTP off using 4 threads. Against official MNN 3.6.0's 4-bit low+mmap path using 4 threads, with 407 versus 402 prompt tokens, median total execution was 75.495 versus 198.782 seconds (2.63x as fast), while 15-token decode was 13.47 versus 63.86 seconds (4.74x as fast).
The goal is not to claim the highest raw throughput. It is to make large GGUF models usable under bounded memory, from mobile devices to models larger than available unified memory.
https://t.co/RB0uPjf5If
I built and released an 8-core unlock ROM for BC-250 boards running BIOS P3.00.
On cold power-on, it applies the unlock, resets once, and boots with 8 cores / 16 threads. It also validates the core mask and factory fuse before making any changes.
https://t.co/o10up8zp1e
Hi!
Recapping some changes we have rolled out over the last couple of weeks that have further reduced the risk associated to potentially destructive actions being performed by Codex during its work.
A few weeks ago, we started investigating a small number of reports where GPT-5.6 in Codex took destructive actions outside what the user asked for. The most serious pattern we found was a command meant to clean up temporary work that could instead delete the user files. This should obviously not happen.
Here’s what we found:
- Codex sometimes creates temporary folders while working and cleans them up afterward. In rare cases, GPT-5.6 got that cleanup wrong. One pattern involved reusing a system environment variable like $HOME for temporary work. A malformed cleanup command could then point at the actual home directory instead of the temporary folder.
- There were cases where the model tried to delete or overwrite a temporary path without checking what was already there.
We’ve added protections at several layers:
- Codex is now explicitly instructed to check deletion targets before acting, create fresh temporary directories, avoid repurposing system environment variables, prefer recoverable actions, and stop when the scope is unclear.
- We strengthened the execution checks that identify high-risk deletion commands and escalate them for review. If a command is rejected, the model is directed to take a safer approach.
- We made Full access harder to enable accidentally, added clearer warnings, and further restricted especially risky permission combinations.
- We updated Auto-review to better identify destructive actions.
- We built targeted evaluations that replay the failures we observed. We’re also adding reinforcement-learning tasks and graders focused on these risks, and filtering destructive actions from training data.
In those replay evaluations, the changes substantially reduced the behavior while preserving Codex’s ability to complete normal coding work.
Two things to do on your end:
- Keep the Codex app up to date. We are always improving safety, performance and many other things.
- Use one of the sandbox modes: "Ask for approval" or "Approve for me". Only use Full access for environments you trust and can recover.
Thanks and happy Codexing out there!
runNburn is now open source 🔥
A Rust-based GGUF inference runtime built for memory-constrained devices, with CPU, CUDA, Metal, Android support, and an OpenAI-compatible server.
https://t.co/pIg39vrZPe
#RustLang#LocalAI#OpenSource
TachiSnap turns messy AI-generated “pixel art” into something actually usable.
Free, open-source, Rust → WASM.
Runs in browser or locally by CLI.
It can:
snap fake pixels back to a real grid
reduce palette drift
remove backgrounds
split sprite sheets
export animated GIFs
bulk process folders
plug into Codex / Claude workflows
https://t.co/Rs41bl6F1s
https://t.co/OWb1qH1piz
예전에는 클로드코드를 정말 열심히 쓰던 편이었습니다. 거의 팬에 가까웠다고 해도 될 정도였고, 실제 개발 작업에서도 꽤 많이 의존했습니다.
그런데 요즘은 사용하면서 아쉬움이 너무 큽니다. 특히 사용량 제한이 줄어드는 체감이 심합니다. 코덱스 사용량이 점점 늘어나면서 클로드코드 플랜을 100달러짜리로 낮춰두었는데, 요즘은 아예 해지 예약까지 해두지 않은 게 조금 후회됩니다.
100달러 플랜은 제 기준에서는 정말 사용할 만한 수준이 아니었습니다. 실제로 2���간 정도 작업했는데, 5시간 사용량이 100%까지 차버렸습니다. 이 정도면 “조금 아껴 써야지”가 아니라, 작업 흐름 자체가 끊기는 수준입니다.
오퍼스 4.7도 기대에 비해 아쉬운 순간이 많았습니다. 예전에는 같이 코드를 파고드는 든든한 동료 같은 느낌이었는데, 최근에는 판단력이 떨어진 듯한 순간이 자주 보였습니다.
반대로 코덱스도 GPT 5.5 이전까지는 솔직히 많이 아쉬웠습니다. 코드 한두 번 수정하다가 “원하시면 이것도 해드릴까요?” 식으로 자꾸 멈춰서, 개발 중간에 흐름이 끊기는 일이 많았습니다. 꽤 답답했습니다.
그런데 GPT 5.5로 올라오면서 확실히 달라졌습니다. 특유의 “원하시면…” 식으로 멈추는 흐름이 거의 사라졌고, 한 번의 요청에서 처리하는 작업량이 5.4 때와 비교가 안 됩니다.
이제는 코드 한두 번 수정하고 멈추는 게 아니라, 알아��� 분석하고, 코드 작성하고, 테스트까지 이어서 ���행하는 경우가 많습니다. 40분 가까이 혼자 작업을 이어가는 경우도 흔합니다.
앞으로 이 판이 또 어떻게 바뀔지는 모르겠습니다. AI 코딩 도구 쪽은 한 달만 지나도 지형이 바뀌는 곳이라, 단정하기는 어렵습니다.
그래도 이번 달 제 선택은 코덱스 프로입니다. 지금 제 개발 워크플로우 기준으로는 이쪽이 훨씬 안정적입니다.
Built proroot, a ptrace-free alternative to proot for Android arm64.
I started this while trying to run a full Ubuntu userspace on Android for OpenClaw. proot worked, but the ptrace overhead became a real bottleneck, especially with heavier workloads like Node.js and Chromium.
So I began experimenting with a different approach based on LD_PRELOAD, binary patching, and Android-specific exec / loader / seccomp bridging.
The goal is simple: keep the proot-style rootless userspace model, but avoid the huge cost of ptrace-based syscall interception.
It is still early, but Node.js, Python, Git, curl, jq, OpenSSL, and Chromium headless_shell are already working on arm64.
GitHub: https://t.co/dgPxZkIRFF