naamo

[naamo @othomo]

@andre_blu I agree with you, but... U don’t need it anymore. Use Claude or Codex.

[naamo @othomo]

@laytoun @marouane53 I strongly recommend fact-checking all information. Check ur dms

[naamo @othomo]

@marouane53 It’s working.

[naamo @othomo]

@mahamiou @bryan_johnson !

[naamo @othomo]

@marouane53 khdma n9iya

[naamo @othomo]

@marouane53 @hamzaydia Hhh

[naamo @othomo]

Excellent travail !
Tu mets en lumière un domaine encore très opaque de la finance marocaine, dans lequel la concurrence reste extrêmement limitée.
Ta plateforme permet enfin de rendre lisibles et comparables des informations souvent dispersées dans des fichiers Excel et PDF difficiles à exploiter, une complexité qui semble presque entretenue à dessein, notamment ceux publiés sur https://t.co/e03GIY9Tvz : performances, niveau de risque, frais de gestion, droits d'entrée et commissions de sortie.

Et c'est justement grâce à ce genre d'outil qu'on réalise à quel point le niveau des frais pratiqués dans le secteur est préoccupant. Chez certaines sociétés de gestion, on trouve parfois jusqu'à 3 % de frais à l'entrée, 3 % à la sortie et 2 % de frais de gestion annuels.
Prenons un exemple concret : pour un placement de 10 000 DH, avec une performance brute nulle pendant un an : après 3 % de frais d'entrée, seuls 9 700 DH sont réellement investis ;
après 2 % de frais de gestion annuels, il reste environ 9 506 DH ;
après 3 % de frais de sortie, l'investisseur ne récupère qu'environ 9 221 DH.
Il perd donc près de 779 DH, soit 7,8 % de son capital, alors même que le portefeuille n'a enregistré aucune baisse. Le fonds devrait générer environ 8,45 % de performance brute en une seule année uniquement pour permettre à l'investisseur de récupérer ses 10 000 DH. Cela montre à quel point la transparence et la comparaison sont indispensables.

C'est un marché sur lequel le Conseil de la concurrence devrait sérieusement se pencher. Il n'existe toujours pas de véritable plateforme ouverte permettant de comparer, souscrire et gérer facilement les OPCVM de l'ensemble des sociétés de gestion. Dans la pratique, les clients restent souvent limités aux produits proposés par leur propre banque.
Bravo pour cette initiative, et bon courage pour la suite...

[naamo @othomo]

68% de l'IPO = sortie du fonds Helios. Sur les 1,1 Md DH levés, 750 MDH vont à l'actionnaire vendeur. Seuls 350 MDH d'argent frais entrent réellement dans l'entreprise. C'est d'abord une sortie de PE, pas une levée pour financer la croissance.

Augmentation réservée au dirigeant juste après l'IPO, à -20% (178,40 vs 223 DH que paie le public). Présenté comme un "intéressement", mais ça transfère ~35 MDH de valeur des nouveaux actionnaires vers le fondateur.

[naamo @othomo]

@_onlyscott Ángel Di María

[naamo @othomo]

@m_blm_tw @grok ?

[naamo @othomo]

@SalahBaina @Souta_knave Just an other fancy wrapper.

[Marouane Lamharzi Alaoui @marouane53]

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 https://t.co/CltCur9qMy 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.

[naamo @othomo]

@mahamiou @grok, what are those chemical materials?

[Ryan Grim @ryangrim]

This is extremely bad news for MRI machines.

(That’s something I learned in Cuba, where it’s hard for them to get helium for their machines.)

[Boris Cherny @bcherny]

Really great writeup

[naamo @othomo]

@alilakrakbi @grok double Check ?

[naamo @othomo]

@netdur @marouane53 You can mix them: use CC (Sonnet for speed) primarily, and use Codex for planning and review.

[naamo @othomo]

@cyclebrkr @amaan8429 same

[naamo @othomo]

@alilakrakbi Good luck

[naamo @othomo]

@MarkOU1 @WeTheBrandon @grok ?