Does anyone know of a plugin or solution to monitor pi sessions from your phone?

They should add the new 27B qwen on opencode-go. It is really good, but runs so slow on my mac. They could offer it super cheap and save go from dying.

They should add the new 27B qwen on opencode-go. It is really good, but runs so slow on my mac. They could offer it super cheap and save go from dying.

What local embedding model would you recommend?

Sometimes the local model starts going in circles with thinking. How do you handle that? I just abort and switch to a stronger model to complete the task.

I promoted one of my posts, and when I saw it on my other account the post was just grey, no image. The post itself looks fine. What could cause this?

I was working with a model in Opencode Go, and it did not support vision, so I tested all. Here are the results:

glm-5.2: No

qwen3.7-max: No

kimi-k2.7-code: Yes

minimax-m3: Yes

mimo-v2.5-pro: No

deepseek-v4-pro: No

qwen3.7-plus: Yes

mimo-v2.5: Yes

deepseek-v4-flash: No

I’m not sure if it is pi or the model, but for some reason when I paste screenshots the model cannot read/see them. How can I show images to the model?

What are your go-to models in Go? I just started my sub, and was curious what models work best.

Previously I could do a lot of coding with Sonnet 4.6, but in later weeks I feel that is's fail-rate is getting higher. I have to go to Opus to get any real work done. Does any one else have this experience? Perhaps it is sad that its big brother got banned?

Is it easy to go from pi to oh-my-pi?

I have been testing both Pi and Opencode, and I like both. I like Pi for its light weight and endless expandability options. I like Opencode for providing most of what I need out of the box, but not a big fan of huge system prompts.

What are your biggest pros and cons of these two coding agents? Do you use both, or have you "landed" on one of them?

We have a step in our retrieval pipeline that calls a cheap/small LLM to analyze the provided question for keywords and filters. I was thinking about whether to test fine tuning a model for the purpose. My questions:

1. How much training data would I need?
2. What could be good models to use for this purpose?
3. Has anyone tested fine tuning models for this type of task?

When testing our retrieval pipeline, we use a utilitarian approach: the settings that ranks the desired documents highest wins.

To do this, we have a curated set of (often tricky) queries, with expected text that should appear in documents that are relevant to responding to the given query. We use Mean Reciprocal Rank (MRR): 1/rank of first matching doc (rank 1 → 1.00, rank 2 → 0.50, not found → 0 etc. We store a baseline that we compare against when we adjust code, or tune parameters in the pipeline.

When we run the regression test, we have stored all data that requires API calls (embeddings, and LLM calls that classify the query, etc) so the dataset is "locked" and deterministic.

When the test is completed, we get a final score, showing if there has been any regressions with the current changes vs the stored baseline and what questions were improved or regressed.

Example result:

MRR: 0.813 (107 queries)

  exact_identifier MRR=0.850 (n=5)

  product          MRR=0.860 (n=27)

  person           MRR=0.495 (n=5)

  general          MRR=0.814 (n=70)

  Rank changes vs baseline

  general

↑  Example query A?            rank:6 → rank:2

↑  Example query B?                    rank:25 → rank:4

↓  Example query C?                                           rank:1 → rank:6

↓  Example query D?                                     rank:1 → rank:8

↓  Example query E?     rank:1 → rank:3

MRR regression: 0.830 → 0.813 (Δ-0.017)

How do you test the different parts of your pipelines?

After getting a lot of out-of-memory errors when running Qwen (Qwen3.6-35B-A3B-oQ4-mtp) in the Pi coding agent with a 64k context, I dug into tuning oMLX settings and configuration for that model. Before, the agent could hardly read past 1-2 files before it stopped due to memory constraints. Here are the settings I used to optimize for a Mac with limited RAM to comfortably stretch into a 128k context window using oMLX:

The oMLX & System Tweaks

• Wired Memory Allocation: Used sudo sysctl iogpu.wired_limit_mb=32768 to max out the VRAM available to the GPU.
• oMLX Limits: Memory guard: aggressive, Hot Cache Limit: ~10%, Cold Cache Limit: 10%, Max Concurrent Requests: 1, Chunked Prefill: On
• Model KV Cache Tuning: TurboQuant KV Cache: On (4-bit).
• Agent Compaction: Used the Pi agent's built-in session compaction cycle active to aggressively clear dead space.

The Result: A Heavy Multi-File Refactor Session

I put this setup through a mid-sized architectural refactor: consolidation of base services/descriptors, tracking type-hint deprecations for PHP 8.5, and completely re-wiring an abstract inheritance tree.

• Runway: At peak utilization, the 128k headroom expansion worked flawlessly. I hit 47k+ active tokens while using only ~35% of the total context window without a single OOM error.
• The Best Part: The total API bill for an entire afternoon of endless code generation, test regressions, and deep-context refactoring was exactly $0.00.

The Victory Lap: A 7/10 Frontier Review

Once my local 35B model successfully passed all 408 local unit tests, I handed the clean git diff over to Claude 3.6 Sonnet for an unbiased senior code review. It scored the local refactor a 7/10:

• What it praised: The structural architectural judgment was flawless. The code style, PSR compliance, and OOP patterns were spot-on.
• Where it knocked points: The local model fell into the classic "Green Trap"—it optimized perfectly to make the 408 tests pass, but missed an untested edge case regarding property defaults and public API method visibility in its first pass (which we ironed out in later local agent loops).

Disclaimer & My Hybrid Workflow

To be totally transparent: I had reviews done in separate sessions using both Qwen and Sonnet. The local Qwen model did not surface all the execution edge cases on its own, but Sonnet caught them instantly. For me, a local 35B model isn't quite ready to work fully autonomously on complex, multi-file refactors. However, if you want a workflow that saves an immense amount of money while maintaining elite code quality, this is the workflow I use:

1. The Blueprint: Create a detailed execution plan in a separate session, using either a frontier model or your local model.
2. The Heavy Lifting: Have the local model execute the bulk of the manual code changes (for $0.00).
3. The First Pass: Review the changes first with your local model to catch obvious syntax or basic logical issues.
4. The Gatekeeper: Run a final review pass with a frontier model (like Sonnet) to catch sneaky architectural breaks or regression edge cases.
5. The Clean-Up: Have the local model implement the final fixes in a loop until all issues are resolved. This approach keeps your cloud API bills down to pennies while letting you iterate relentlessly on your local machine.

What settings or backends are you guys using to keep your local coding agents stable past 32k context?

How well does Qwen 3.6 35B handle contexts above 64k? I have only gotten to test 4bit with ~64k since my mac only has 36gb unified mem. Up to that context it handles it well in my experience. But is it good enough for coding tasks when context grows?

Any experiences with it?

Any tips for dashboard or stats for ollama, so I can inspect all the details?

Any tips for dashboard or stats for ollama, so I can inspect all the details?

Small tip if you are using pi with local models and need to maximize the available context.

I set up two aliases: pii (pi-ignorant) and pio (pi-omnipotent)

pii after first question use only 2.5%/66k context that I have for my local model, while the omnipotent versjon starts with 21.5%/66k (almost 10x bigger, even if my "omnipotent" setup is quite modest).

Here are the aliases I use:

alias pii="pi --no-context-files --no-extensions --no-skills --no-prompt-templates --no-themes"

alias pio="pi --append-system-prompt /path/to/my/APPEND_SYSTEM.md"

The second alias is redundant, unless you need to append to the system prompt, you could just use the regular pi. It is possible to tune pi very much by just using options. Check pi --help for a lot of great tuning opportunities, like read-only, specific model etc.

It is also great if you want a stripped versjon just to chat/ask questions without having to pay for extra tokens on a larger model.

This might be obvious, but easy to forget how much can be done this way!