Firassa AI

Most "AI video" products still feel like toys for people who don't edit. @FirassaAI feels different. Big congrats to my friends @marouane53 and @rachidhakmi on a seriously impressive build. If you use Premiere Pro, this one is worth your attention.

I went through Claude Code's codebase with the help of AI to analyze the architecture quickly and compare it against Codex which is already open source. I'm very interested in this space because agentic coding is essentially what we're building at Firassa AI but for video editing. Not the "move this clip" or "add a transition" kind of agentic, but a full autonomous agent that takes raw footage and delivers a rough cut that could be production ready. So understanding how these agentic loops are designed matters a lot to me. The biggest misconception in the Claude Code vs Codex debate is that Claude wins because the model is smarter. Through my own use cases and looking through people's feedback, Codex is actually the stronger coder on harder tasks. Claude wins because it built a better control plane. Claude Code is built around a centralized turn loop that behaves like a state machine. You can look at src/query.ts and see it acting as the center of orchestration, with src/bootstrap/state.ts as a giant centralized session-state layer around it. Every phase of the agent loop (preparing context, sampling the model, executing tools, waiting on the user, compacting) flows through that center. That's why it feels smoother. You always know what it's doing. Codex spreads that same logic across submission_loop, user_input_or_turn, RegularTask::run, and run_turn in different files. RegularTask::run literally just loops run_turn until has_pending_input() goes false. It works but the states are emergent not declared. One of my biggest issues with Codex has been not knowing when it's actually waiting on me versus still thinking, and looking at the architecture now I understand exactly why. Tool scheduling is where Claude quietly destroys Codex on speed in the main agent loop. Claude clearly separates read-only, edit, execution, and MCP tool classes at the product level, and you can see toolOrchestration.ts and StreamingToolExecutor.ts handling batching and ordered result streaming. Codex has a solid per-tool orchestrator in tools/orchestrator.rs with approvals and sandbox retries, arguably better low-level rigor. But in the main turn-level orchestration path it processes tools through a per-call approval, sandbox, attempt, retry pipeline without a first-class batch scheduler or concurrency graph. Worth noting though that Codex already has parallel nested tool execution inside code mode through exec/wait, where JavaScript runs in a V8 isolate and can compose and parallelize nested tool calls. So the gap is specifically in the main agent loop, not across the board. Context management is Claude's most underrated advantage. From the codebase you can see exactly what loads when. CLAUDE.md at session start, skill descriptions lazily, MCP schemas deferred, subagent context isolated, hooks at zero cost unless they emit. There's a real context economy with visible budgets and you can trace it through the /context and compact modules. Now to be fair Codex is not missing context plumbing. It already has repo-aware startup context in realtime_context.rs, explicit AGENTS.md discovery in project_doc.rs, and compaction logic in compact.rs that handles reinjection of initial context. But that's exactly what makes the critique sharper. The real gap is not missing components. It's that there's no single governor deciding what stays what gets summarized what gets retrieved. A lot of people on GitHub are asking for semantic indexing which basically means they want that governor layer even if they don't call it that. File editing is where the architectures diverge most interestingly. Claude uses optimistic-concurrency editing through FileEditTool. Read a file, record the revision, propose a localized edit with old_string/new_string, detect staleness, show a diff for approval. The IDE side has real diff editing flow through FileEditPermissionRequest.tsx and ideDiffConfig.ts. It's a trust primitive not just an edit primitive. Codex is patch-first and honestly its patch engine is better. TurnDiffTracker in turn_diff_tracker.rs maintains baselines, handles renames, generates unified diffs. It also already has diff approval primitives, the TUI has an approval_overlay that handles ApplyPatch requests and the app-server protocol has explicit file-change approval request/response types. So the gap is not that Codex has no review surface. It's that it doesn't have the same revision-aware localized edit contract or a first-class editor-side diff editing loop. The fix isn't to throw away the patch engine. It's to wrap it in that narrower revision-aware contract on top. Permissions are where Codex has real bugs not just missing features. Both have tiered permission systems and sandbox enforcement. Codex even has a guardian reviewer and it's more sophisticated than it sounds. It reconstructs a compact transcript, runs a dedicated review session, requires strict JSON output, fails closed on malformed output or timeout, and only auto-approves lower-risk actions. That is genuinely strong low-level rigor. But from looking at the issue tracker and community feedback, the layers leak in practice. MCP edit tools can bypass read-only mode. Approval state reverts after thread switches. Network retries after approval still inherit restricted policy. Child workers don't pick up parent permissions correctly. The result is inconsistent behavior where the same approval means different things depending on which execution path the agent takes, and that's a trust killer. Planning is Claude's highest-leverage UX win and Codex's biggest missed opportunity. Claude has first-class plan mode, plan approval surfaces, and built-in planAgent and verificationAgent sitting right there in the source. That's not just prompting, that's architecture. Codex has multi-agent primitives, mailboxes, agent registries, even the guardian reviewer. All the pieces for a planner-verifier pipeline exist. They just haven't been assembled into a workflow users can rely on. Now here's where it gets interesting because I think Codex has at least 5 ways to actually get ahead of Claude architecturally. Open retrieval backends. Claude's context economy is well designed but the retrieval architecture is still proprietary internally. Codex can expose a RetrievalIndex trait and let the community build BM25, embeddings, tree-sitter, hybrid backends. I think that's the kind of advantage you can only get by being open source. Deterministic replay. Codex's persistence story is even stronger than just a SQLite DB. The state runtime opens and migrates dedicated SQLite state and logs databases separately to reduce lock contention, and the migration history tracks threads, logs, memories, dynamic tools, spawn edges and more. That's a better foundation than Claude's in-memory singleton for testing and CI. Turn that into a flagship feature. Guardian plus Verifier stack. Combine the existing safety reviewer with adversarial post-change verification. Policy review plus correctness verification is stronger than either alone. Structured plan artifacts. Plans, approvals, verification reports all want schemas not prose. OpenAI's structured outputs are a natural fit here and Codex could have this working before anyone else does. Community policy packs. Codex can let the community publish not just tools but safety and verification behavior. I think that's a way more interesting competitive advantage than keeping everything internal. Codex code mode is also a real sleeper in this whole conversation. exec/wait gives you a programmable orchestration layer where JavaScript runs in a V8 isolate, composes nested tool calls, can persist values across calls, and parallelize work. I think that's a real path for Codex to get ahead of Claude instead of just copying its control plane design. If I wanted to get Codex to actually compete on the orchestration level I'd start with three things. A TurnStateMachine. An EffectivePermissionContext. A ToolExecutionGraph. Those fix the control plane. Everything else becomes dramatically easier to build after that. I think Claude Code wins on orchestration, context policy, permission UX, and the extension story. Codex wins on low-level rigor. Rust core, real OS sandboxing, better patch engine, stronger persistence substrate, and code mode as a programmable orchestration primitive. Codex's problem is that its backend primitives are ahead of its orchestration layer. It's a product with P0 infrastructure and P2 choreography. The winning move for OpenAI is to put a first-class control plane on top of the Rust core they already have.

Introducing Firassa AI Every video holds endless insights. Firassa transforms your entire video library, even if it contains hundreds of thousands of hours and countless videos, into an instant multilingual knowledge base. Ask naturally, get answers immediately. Understand visuals, speech, emotion, and cultural nuance across 40+ languages. This is video intelligence redefined. #VideoAI #ArtificialIntelligence #MultimodalAI #ContentInnovation #FirassaAI

See Firassa AI in action. Discover how our advanced video intelligence platform helps you extract meaningful insights effortlessly. Identify faces, emotions, actions, and context seamlessly across multilingual, long-form content with unmatched accuracy and speed. Watch this quick 3-minute demo to understand how Firassa AI can transform your video analysis capabilities. To explore how @FirassaAI can specifically enhance your business, book a demo or reach out via direct message.

Firassa AI just set the bar on the Video‑MME long‑video benchmark: 93.33 % accuracy versus GPT 4.1’s 72 %. Multi‑hour footage, no subtitles, minimal hallucination. When it comes to deep context understanding, there’s a clear new leader. Stay tuned for launch next week.