Codex 사용량 초기화, Marker v2 문서 파싱, LLMOps 운영 기준과 에이전트 조직 격차

Update on rate limits in Codex. We’ve found (a) some inefficiencies when using images in long sessions with multiple compactions (b) high p95+ usage for Computer History (c) a feature that was meant to generate conversation titles that was draining a bit more usage than intended. And we have a tiger team combing through everything and shipping fixes tomorrow. We also found a novel approach to drive efficiency up significantly that is completely unrelated and we will be working on next week. As part of some of the fixes tomorrow, we will also do a full reset of the usage for all paid subscriptions. See you then.

Reset will land around 14pm PST tomorrow.

Turn any PDF, image, DOCX, and PPTX into clean markdown. Parsing one PDF is easy. Parsing millions of them is where it gets tricky. Datalab just shipped Marker v2, a parsing pipeline that runs up to 23.7 pages/s on a single B200 GPU. Supports 90+ languages. 100% open-source.

GitHub repo: https:// github.com/datalab-to/mar ker … (don't forget to star )

DevOps vs. MLOps vs. LLMOps, clearly explained: Many teams are trying to apply DevOps practices to LLM apps. But DevOps, MLOps, and LLMOps solve fundamentally different problems. DevOps is software-centric. You write code, test it, and deploy it. The feedback loop is straightforward, i.e., does the code work or not? MLOps is model-centric. Here, you're dealing with data drift, model decay, and continuous retraining. The code might be fine, but the model's performance can degrade over time because the world changes. LLMOps is foundation-model-centric. Here, you're typically not training models from scratch. Instead, you're selecting foundation models and then optimizing through three common paths: - Prompt engineering - Context/RAG setup - Fine-tuning But here's what really separates LLMOps: The monitoring is completely different. In MLOps, you track data drift, model decay, and accuracy. In LLMOps, you're watching for: - Hallucination detection - Bias and toxicity - Token usage and cost - Human feedback loops This is because you can't just check if the output is "correct." You need to ensure it's safe, grounded, and cost-effective. The evaluation loop in LLMOps also feeds back into all three optimization paths simultaneously. Failed evals might mean you need better prompts, richer context, OR fine-tuning. So it's not a linear pipeline anymore. One more thing: prompt versioning and RAG pipelines are now first-class citizens in LLMOps, just like data versioning became essential in MLOps. And the ops layer you choose should match the system you're building. If you want to go deeper into LLMOps, I wrote a full LLM engineering roadmap a while back. It walks through the eight pillars of building LLM systems, starting at prompt engineering and ending at observability and safety, with free and open-source resources attached to each one. You can read it below.

Jerry Liu

@jerryjliu0

12일 전

the difference in productivity between 0-1 mode vs. working within a big team at a large co seems universally true even pre-chatgpt. it's really easy to be "productive" when (a) you're the only person driving decision making and implementation, and (b) you're still <20% effort in the 80-20 rule. it becomes a lot harder to contribute at the same pace, almost by design, when you share decision making within a larger team and have to optimize for quality AI in the hands of smart people probably makes this contrast even more apparent. it might also explain why the fastest moving products at large companies start with extremely small pockets of people (e.g. boris with claude code)

The agentic experience varies widely among companies. When my friends at other FAANG companies were surprised that it’s normal to have agents running overnight jobs and triage, I realized frontier experiences are not equally distributed.